-
Notifications
You must be signed in to change notification settings - Fork 130
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
Fixes #31642 - Add container gateway support #643
Fixes #31642 - Add container gateway support #643
Conversation
Related PR: theforeman/puppet-foreman_proxy_content#319 |
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.
It would be nice to have at least a minimal test. in spec/classes
there are plenty of examples.
Stdlib::Absolutepath $pulp_client_ssl_key = $foreman_proxy::plugin::container_gateway::params::pulp_ssl_client_key, | ||
Stdlib::Absolutepath $sqlite_db_path = $foreman_proxy::plugin::container_gateway::params::sqlite_db_path, | ||
) inherits foreman_proxy::plugin::container_gateway::params { | ||
|
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.
Nit: this empty line is not needed and a lint plugin I intend to add will complain about it
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.
Okay, it's removed.
class foreman_proxy::plugin::container_gateway ( | ||
Optional[String] $version = $foreman_proxy::plugin::container_gateway::params::version, | ||
Boolean $enabled = $foreman_proxy::plugin::container_gateway::params::enabled, | ||
Foreman_proxy::ListenOn $listen_on = $foreman_proxy::plugin::container_gateway::params::listen_on, | ||
Stdlib::HTTPUrl $pulp_endpoint = $foreman_proxy::plugin::container_gateway::params::pulp_endpoint, | ||
Stdlib::Absolutepath $pulp_client_ssl_cert = $foreman_proxy::plugin::container_gateway::params::pulp_ssl_client_cert, | ||
Stdlib::Absolutepath $pulp_client_ssl_key = $foreman_proxy::plugin::container_gateway::params::pulp_ssl_client_key, | ||
Stdlib::Absolutepath $sqlite_db_path = $foreman_proxy::plugin::container_gateway::params::sqlite_db_path, |
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.
We try to add static values inline nowadays because it's easier to follow. Ideally we would do everything but Kafo has some issues parsing some defaults. So all but $pulp_endpoint
can be declared here.
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'm a bit confused, so if $pulp_endpoint
isn't declared here, where would it go? It looks like I'm doing pretty much the same thing as$pulp_url
in the Pulp plugin for example.
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.
So a bit more insight from my point. Now that I've seen the various PRs I changed my opinion a bit. If we're not going to expose it via Kafo, there really isn't any point in keeping params.pp
.
There are 2 reasons to have params.pp
:
- You need logic (if/else/...) to determine the value, like OS-dependent defaults
- You want to expose the class via Kafo and need something Kafo can't parse
Let's start with the last part. We expose the defaults via puppet-strings. This gives the raw Puppet code as a default. Then kafo_parsers has some very naive "parsing". This naive parsing can't deal with a lot of things, like "https://${facts['networking']['fqdn']}"
but it can deal with $variable
. Putting the default value in a params.pp
is thus a workaround, but it works.
For the second part, you can also use data in modules which utilizes hiera, but we haven't really used that and Kafo doesn't understand it either so let's leave that out of scope now.
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.
Alright, thanks for the explanation. I assumed at first that Kafo was something that was being used in the background rather than something I to purposefully use. I'll remove params.pp
and move the defaults into container_gateway.pp
.
$pulp_ssl_client_cert = '/etc/foreman-proxy/foreman_ssl_cert.pem' | ||
$pulp_ssl_client_key = '/etc/foreman-proxy/foreman_ssl_key.pem' |
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.
Isn't this the same as $foreman_proxy::foreman_ssl_cert
and key? That also makes me think you should have a CA. It's a katelloism to rely on the system store to trust certificates while Foreman is more explicit.
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.
Isn't this the same as $foreman_proxy::foreman_ssl_cert and key?
It is, I'll use $foreman_proxy::foreman_ssl_cert & key
then.
We're using that cert and key to avoid handing out the Pulp 3 certs to every smart proxy.
That also makes me think you should have a CA.
I'll have to take a look at see what that entails installer-wise.
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.
Is /etc/foreman-proxy/foreman_ssl_ca.pem
the CA that you were talking about?
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'll make an issue on the container gateway to take a CA as a configurable parameter (https://projects.theforeman.org/issues/31759)
@ekohl is this something you'd consider crucial to get in for Katello 4.0?
|
||
foreman_proxy::plugin::module { 'container_gateway': | ||
version => $version, | ||
template_path => 'foreman_proxy/plugin/container_gateway.yml.erb', |
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.
Isn't this the same as the default?
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.
Yep, I removed it.
Will do, it's on my TODO list for this and the other related PR. Figured I'd get these in first to see if I'm on the right track standards-wise (it does work at least :) ) |
41e8d02
to
fb30601
Compare
43f611f
to
35bff0c
Compare
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.
Another thing to consider is to modify the plugin to support not passing SSL certs at all. For reference, you can read the core settings in code:
https://github.com/theforeman/smart-proxy/blob/758f197d4b452424d59149abb11429fd6ab50465/lib/proxy/request.rb#L71-L73
That means if the value changes, you don't need configuration management to keep them in sync. Less code is better.
81bc48b
to
b436677
Compare
'---', | ||
':enabled: https', | ||
":pulp_endpoint: https://#{facts[:fqdn]}", | ||
':pulp_client_ssl_cert: /etc/foreman-proxy/foreman_ssl_cert.pem', |
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.
@ekohl is there a way to "mock" a variable from another class? It seems like $foreman_proxy::foreman_ssl_cert
and key is undef
for the spec tests.
I'm hitting:
Puppet::PreformattedError:
Evaluation Error: Error while evaluating a Function Call, Class[Foreman_proxy::Plugin::Container_gateway]:
parameter 'pulp_client_ssl_cert' expects a Stdlib::Absolutepath = Variant[Stdlib::Windowspath = Pattern[/\A(([a-zA-Z]:[\\\/])|([\\\/][\\\/][^\\\/]+[\\\/][^\\\/]+)|([\\\/][\\\/]\?[\\\/][^\\\/]+)).*\z/], Stdlib::Unixpath = Pattern[/\A\/([^\n\/\0]+\/*)*\z/]] value, got Undef
parameter 'pulp_client_ssl_key' expects a Stdlib::Absolutepath = Variant[Stdlib::Windowspath = Pattern[/\A(([a-zA-Z]:[\\\/])|([\\\/][\\\/][^\\\/]+[\\\/][^\\\/]+)|([\\\/][\\\/]\?[\\\/][^\\\/]+)).*\z/], Stdlib::Unixpath = Pattern[/\A\/([^\n\/\0]+\/*)*\z/]] value, got Undef (line: 3, column: 1) on node cannolo.usersys.redhat.com
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.
There is
let(:pre_condition) { 'include foreman_proxy' }
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 do have that. I think it's reporting undef
because of this:
puppet-foreman_proxy/manifests/params.pp
Line 172 in e4b7763
$foreman_ssl_cert = undef |
Perhaps I can override the parameter itself?
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.
Okay, looks like I figured it out. I updated the test in my latest push.
57a62d2
to
7fb9b30
Compare
This sounds like a good idea, I didn't think to use the @ekohl I'm curious where you'd rank this new cert strategy on your priority list. Do we need this for the initial 4.0 release? Just want to make sure it's essential before I bump fixing the Container Gateway to the top of my priority list. I'm assuming the Container Gateway installer support should get in quite soon due to Katello 4.0 branching soon. |
I realized the installer is failing with my PRs because |
That's packaging's responsibility. |
I'm starting to fix the container gateway to enable default certs & ca cert configuration. It's a quick change, should be merged very soon. Just need to update these PRs after and make a quick packaging one. |
7fb9b30
to
f36cb6a
Compare
@ekohl I think I've addressed all of your concerns. The plugin has shrunk quite nicely. |
foreman_proxy::plugin::module { 'container_gateway': | ||
version => $version, | ||
enabled => $enabled, | ||
feature => 'Container_Gateway', |
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 to verify: the Katello plugin does recognize this feature? Setting it here means the installer checks if Foreman recognized the feature after installation and otherwise fails.
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.
Katello does, yeah. We've already introduced the functionality of sending over the unauthenticated repo list at proxy sync time if the feature exists.
I don't have merge access, so feel free to merge whenever. |
@ekohl is this all good to merge? |
Yes, I approved and then went to check something else but it looks like we don't really have acceptance tests for plugins in this module so I'll just merge it now. |
Adds support for the Container Gateway smart proxy plugin.
I'm pretty new to the foreman-installer so let me know any places where I'm breaking standards.
TODO:
Addforeman-proxy-content
answers file migration (Fixes #31642 - Add container gateway support foreman-installer#643)