-
Notifications
You must be signed in to change notification settings - Fork 146
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add RHUI and RPM Transaction configuration #1142
base: main
Are you sure you want to change the base?
Changes from all commits
a473fe9
cece1e3
9f02c14
f9258af
52e32de
cfee78b
5499427
ac879af
a8f1372
13508f6
f8cbdc9
e437148
bea0d31
70f7d5b
07a24f7
7486ce0
0d044b2
35dd900
7eaa78a
418f023
55bdb5c
61ae067
f82750e
50879db
aea50bd
892c35e
ddd773a
356a5b3
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
rhui: | ||
use_config : False | ||
source_clients: [ rh-amazon-rhui-client ] | ||
target_clients: [ rh-amazon-rhui-client ] | ||
cloud_provider: aws | ||
upgrade_files: | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This example is looking good! I also know of some use cases that need to specify the CA certificate used for the dnf calls to the RHUI repo, but perhaps that configuration is encapsulated in the leapp-aws.repo file...? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Do you mean the
Then you need tell leapp that it should grab the The configuration would then look like: rhui:
use_config : True
source_clients: [ rhel8-client ] # what client to remove from the source system
target_clients: [ rhel9-client ] # what client should be installed during the upgrade
cloud_provider: aws # for leapp to use internally
upgrade_files:
/root/my-upgrade-repos.repo : /etc/yum.repos.d # during upgrade, place this repofile into /etc/yum.repos.d
/root/content-rhel8.crt : /etc/pki/rhui/product/ # during the upgrade, place this key here. Same path as in sslclientcert in the repo
# .... other keys/certs mentioned in the repofile, or otherwise important for leapp to access target OS content This should enable basically anyone running a RHUI system to upgrade, assuming that provider's rhui clients do not use some eccentric python dependencies (although that should be fine too, I just haven't tested these setups). You get all the necessary Also note that if you rename the repositories in the repofile for some reason, and then use these new names in |
||
/usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/leapp-rhui-aws/rhui-client-config-server-9.crt : /etc/pki/rhui/product/ | ||
/usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/leapp-rhui-aws/rhui-client-config-server-9.key : /etc/pki/rhui/private/ | ||
/usr/share/leapp-repository/repositories/system_upgrade/common/files/rhui/leapp-rhui-aws/leapp-aws.repo : /etc/yum.repos.d/ | ||
rhui_target_repositories_to_use: | ||
- rhel-9-appstream-rhui-rpms | ||
- rhel-9-baseos-rhui-rpms |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand that we are doing it this way because we want to load the configs before anything else is done. However, this leads to the problem that whether config is loaded is not within the power of the framework. Instead of having it here in the command, wouldn't it be better to have
load()
in some early stage ofworkflow.run()
? That way we can be sure that configs are loaded from the point of view of the frameworkThere was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't remember if Petr and I discussed
workflow.run()
as a possible place for this. A quick look seems to show that workflows don't have access to theRepositoryManager
. Does this mean we cannot lookup information about all of the availableActors
from within a workflow? Or just that we would have to access them in another way?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Workflow should collect all discovered actors during its initialization (https://github.com/oamg/leapp/blob/7565b5c8cd5a098522565ff0ed5278eb2b04b7a8/leapp/workflows/__init__.py#L167). I have used this before and thought it might be helpful again here.
To me, loading the configuration just after workflow starts and before any actor is processed is a place where I would put it personally. However, there might be reasons not to do this if it has not come up in a discussion. Have you thought about this? @pirat89 Or am I missing something
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure - I mean, we looked for a place where we could put it and that seemed good - especially in case we would like to have in future repository-shared configs (configs dir defined in the repository level); which we decided last time that is not way we want to go (at least now). We already have such a handling in case of answerfiles, but you are right that having the possibility to keep it implemented just inside the framework side (without the need to know additional magic that should be specified in CLI commands on the repositoriy side) sounds much better to me. Also, remember on snactor! We need a way how to execute an actor itself with snactor without the need to run the workflow. (it can be done later, but it should be done still for the upcoming version)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dkubek The code you're pointing to looks like it just looks at the actors available in all the phases that the workflow runs rather than all of the actors in the repositories?
Although I'm not sure if we need all of them or not.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Also, I agree with you that if we can put this into framework code, it is the better place).