testing
/
wiki
generated from sig_core/wiki-template
10
0
Fork 3
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

Add SOP for openQA system upgrades #5

Merged
raktajino merged 5 commits from openqa_sop_system_upgrade into main 2023-06-30 00:30:25 +00:00
Conversation 4 Commits 5 Files Changed 2 +76
raktajino commented 2023-06-28 20:46:52 +00:00
Member
Copy Link

This PR includes an SOP outlining the process for running system upgrades on an openQA host.

This PR includes an SOP outlining the process for running system upgrades on an openQA host.
raktajino added 2 commits 2023-06-28 20:46:53 +00:00
raktajino requested review from alangm 2023-06-28 20:47:06 +00:00
raktajino requested review from lumarel 2023-06-28 20:47:06 +00:00
raktajino requested review from stack 2023-06-28 20:47:06 +00:00
raktajino requested review from tcooper 2023-06-28 20:47:07 +00:00
alangm commented 2023-06-29 13:57:10 +00:00
Member
Copy Link

I haven't tested this yet but the procedure looks very much as I remember it down to the branding bit. I'll test it when I upgrade my T630 server and if the branding is needed I will test that too.
For now though LGTM

I haven't tested this yet but the procedure looks very much as I remember it down to the branding bit. I'll test it when I upgrade my T630 server and if the branding is needed I will test that too. For now though LGTM
alangm approved these changes 2023-06-29 14:36:30 +00:00
alangm left a comment
Member
Copy Link

As I said LGTM

As I said LGTM
❤️ 1
tcooper approved these changes 2023-06-29 15:30:35 +00:00
tcooper left a comment
Member
Copy Link

This sequence appears to be what I have done to upgrade Fedora on other hosts, aside from the additional step(s) for postgresql upgrade... 👍

What I think we will also need is a SOP for the system update that is covered in step 1 of this SOP. That I think could be a separate SOP that is referenced here. It should cover differences in SECURITY, BUGFIX and/or FEATURE updates and how we might choose different paths for each.

It should also address loss of worker and/or frontend availability during the update process, notifications required in advance of update and/or upgrade and should include considerations on when not to update / upgrade.

All of this could be in a separate branch/MR and need not block this one.

This sequence appears to be what I have done to upgrade Fedora on other hosts, aside from the additional step(s) for postgresql upgrade... 👍 What I think we will also need is a SOP for the system update that is covered in step 1 of this SOP. That I think could be a separate SOP that is referenced here. It should cover differences in SECURITY, BUGFIX and/or FEATURE updates and how we might choose different paths for each. It should also address loss of worker and/or frontend availability during the update process, notifications required in advance of update and/or upgrade and should include considerations on when **not** to update / upgrade. All of this could be in a separate branch/MR and need not block this one.
tcooper commented 2023-06-29 16:32:12 +00:00
Member
Copy Link

@raktajino I popped this into my wiki devbox setup and have some formatting suggestions (not content changes) that may be better to add here than into main after this is merged. I think you should be able to see the diff at this link.

@raktajino I popped this into my wiki devbox setup and have some formatting suggestions (not content changes) that may be better to add here than into main after this is merged. I think you should be able to see the diff at [this link](https://git.resf.org/testing/wiki/compare/openqa_sop_system_upgrade...tcooper/testing-wiki:openqa_sop_system_upgrade_tweaks).
raktajino commented 2023-06-29 17:47:33 +00:00
Author
Member
Copy Link

@raktajino I popped this into my wiki devbox setup and have some formatting suggestions (not content changes) that may be better to add here than into main after this is merged. I think you should be able to see the diff at this link.

Those changes make sense to me, if you want to push them up as a new commit I say go for it. One question - is there any particular reason you used shell in that first code block change and bash in all subsequent changes to code blocks?

> @raktajino I popped this into my wiki devbox setup and have some formatting suggestions (not content changes) that may be better to add here than into main after this is merged. I think you should be able to see the diff at [this link](https://git.resf.org/testing/wiki/compare/openqa_sop_system_upgrade...tcooper/testing-wiki:openqa_sop_system_upgrade_tweaks). Those changes make sense to me, if you want to push them up as a new commit I say go for it. One question - is there any particular reason you used `shell` in that first code block change and `bash` in all subsequent changes to code blocks?
tcooper commented 2023-06-29 21:51:17 +00:00
Member
Copy Link

@raktajino I popped this into my wiki devbox setup and have some formatting suggestions (not content changes) that may be better to add here than into main after this is merged. I think you should be able to see the diff at this link.

Those changes make sense to me, if you want to push them up as a new commit I say go for it. One question - is there any particular reason you used shell in that first code block change and bash in all subsequent changes to code blocks?

Nope... just testing to see if changing made a difference.

Following the mkdocs documenttion link trail it seems like this is the section of the upstream that describes which shells the Lex'er(s) support.

I'll make them uniformly use bash before pushing a new commit to the branch.

> > @raktajino I popped this into my wiki devbox setup and have some formatting suggestions (not content changes) that may be better to add here than into main after this is merged. I think you should be able to see the diff at [this link](https://git.resf.org/testing/wiki/compare/openqa_sop_system_upgrade...tcooper/testing-wiki:openqa_sop_system_upgrade_tweaks). > > Those changes make sense to me, if you want to push them up as a new commit I say go for it. One question - is there any particular reason you used `shell` in that first code block change and `bash` in all subsequent changes to code blocks? Nope... just testing to see if changing made a difference. Following the mkdocs documenttion link trail it seems like [this is the section](https://pygments.org/docs/lexers/#lexers-for-various-shells) of the upstream that describes which shells the Lex'er(s) support. I'll make them uniformly use `bash` before pushing a new commit to the branch.
👍 1
tcooper added 3 commits 2023-06-29 21:58:09 +00:00
raktajino merged commit ad741da5ab into main 2023-06-30 00:30:25 +00:00
raktajino deleted branch openqa_sop_system_upgrade 2023-06-30 00:30:34 +00:00
Sign in to join this conversation.
Reviewers
No reviewers
stack
lumarel
alangm
tcooper
Labels
Clear labels
No items
No Label
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: testing/wiki#5
No description provided.
Delete Branch "openqa_sop_system_upgrade"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?