-
Notifications
You must be signed in to change notification settings - Fork 48
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
allow overriding the name of the metapackage #481
Conversation
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.
Just some random thoughts. I'd like to make the meta package optional. We're not there yet, but perhaps something to consider while doing this. Should we at some point accept String[0]
to disable this?
manifests/params.pp
Outdated
@@ -26,4 +26,5 @@ | |||
Stdlib::HTTPSUrl $candlepin_url = "https://${candlepin_host}:${candlepin_port}/candlepin", | |||
String[1] $candlepin_client_keypair_group = 'foreman', | |||
String[1] $postgresql_evr_package = $katello::globals::postgresql_evr_package, | |||
String[1] $meta_package = $katello::globals::meta_package, |
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.
Do we need to expose this? If we limit it to globals then the installer can set this via Hiera parameters. I don't see a use case (at least in the short term) where the user would want to override this.
It may not be clear today, but it used to have a parameter (until 188a71f) that was controlled by the installer.
The long term idea was that you have:
globals.pp
is set by the installerparams.pp
gets exposed to the user via installer parametersapplication.pp
andcandlepin.pp
are exposed instead ofinit.pp
to allow installation of only Candlepin or Foreman.
Then we would expose foreman_proxy_content
as --content-*
instead.
An intermediate step was #209 which introduced manage flags for each component.
Or we can take the easy solution here and inline it. We should do the same with postgresql_evr_package
which used to have EL7/EL8 logic. When we dropped EL7 support, there's little benefit to keeping it in globals anymore.
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.
Yeah, I don't particularly care where it's defined as long as it can be overridden via installer/hiera. I'll play around how to minify this.
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.
do you have a preference? both ways "work", but I find inlining into params.pp
nicer as in init.pp
we never touch katello::globals
directly, so package { $katello::globals::meta_package … }
reads odd to me (but works as it's loaded by katello::params
)
@ekohl the tests fail and I briefly recall this is because of the security fix in candlepin that makes something non idempotent? |
Correct. 3a2be23 is the fix for that. |
this is useful for downstream branding
this is useful for downstream branding