-
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 10 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 : True | ||
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/ | ||
enabled_target_repositories: | ||
- rhel-9-appstream-rhui-rpms | ||
- rhel-9-baseos-rhui-rpms |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,64 @@ | ||
""" | ||
Configuration keys for dnf transactions. | ||
""" | ||
|
||
from leapp.actors.config import Config | ||
from leapp.models import fields | ||
|
||
|
||
# * Nested containers? | ||
# * Duplication of default value in type_ and Config. If we eliminate that, we need to extract | ||
# default from the type_ for the documentation. | ||
# * We probably want to allow dicts in Config. But IIRC, dicts were | ||
# specifically excluded for model fields. Do we need something that restricts | ||
# where fields are valid? | ||
# * Test that type validation is strict. For instance, giving an integer like 644 to | ||
# a field.String() is an error. | ||
class Transaction_ToInstall(Config): | ||
section = "transaction" | ||
name = "to_install" | ||
type_ = fields.List(fields.String(), default=[]) | ||
default = [] | ||
description = """ | ||
List of packages to be added to the upgrade transaction. | ||
Signed packages which are already installed will be skipped. | ||
""" | ||
|
||
|
||
class Transaction_ToKeep(Config): | ||
section = "transaction" | ||
name = "to_keep" | ||
type_ = fields.List(fields.String(), default=[ | ||
"leapp", | ||
"python2-leapp", | ||
"python3-leapp", | ||
"leapp-repository", | ||
"snactor", | ||
]) | ||
default = [ | ||
"leapp", | ||
"python2-leapp", | ||
"python3-leapp", | ||
"leapp-repository", | ||
"snactor", | ||
] | ||
description = """ | ||
List of packages to be kept in the upgrade transaction. The default is | ||
leapp, python2-leapp, python3-leapp, leapp-repository, snactor. If you | ||
override this, remember to include the default values if applicable. | ||
""" | ||
|
||
|
||
class Transaction_ToRemove(Config): | ||
section = "transaction" | ||
name = "to_remove" | ||
type_ = fields.List(fields.String(), default=[ | ||
"initial-setup", | ||
]) | ||
default = ["initial-setup"] | ||
description = """ | ||
List of packages to be removed from the upgrade transaction. The default | ||
is initial-setup which should be removed to avoid it asking for EULA | ||
acceptance during upgrade. If you override this, remember to include the | ||
default values if applicable. | ||
""" |
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).