The plan is to integrate this with subscription-manager so new RHEL
instance can be easily added and configured using only one single
command (with rhsm plugin). Now, since rhsm plugins are currently not
able to extend rhsm command line options, some interactivity is needed.
At least for the first phase.
The community puppet.conf template need one small change as well -
operatingsystem is not set during puppet conf deployment.
Question for Foreman folks - is this approach feasible? While puppet
report upload creates host record, this cannot be used for template
rendering. Marek mentioned we could use our puppet-puppet module and
kafo for that, but we'd need to extend both kafo and the module (to
reach out foreman instance to download the template). Opinions? Other
ways to do this?
Question for Katello folks - since subscription-manager creates system
record during registration, we might also orchestrate host creation. But
for that we need some input from the user (puppet environment, master
and ca proxy names), optionally host group. The question is if this is
worth doing via Katello plugin or not.
Puppet Facts upload will create a Host, which is entirely usable
here, since you have access to Facter. While not use that instead of
creating the Host over the API? That will create an unmanaged host,
but that's generally what you want with legacy hosts anyway.
Greg
···
On 27 February 2014 15:49, Lukas Zapletal wrote:
> Hello,
> Question for Foreman folks - is this approach feasible? While puppet
> report upload creates host record, this cannot be used for template
> rendering.
> Puppet Facts upload will create a Host, which is entirely usable
> here, since you have access to Facter. While not use that instead of
> creating the Host over the API? That will create an unmanaged host,
> but that's generally what you want with legacy hosts anyway.
Greg, the goal here is to have subscription-manager to configure puppet
in one command. Something like this:
subscription-manager --serverurl=https://satellite6.xyz.com --org=XYZ
–puppet-environment production --puppet-master alfa --puppet-ca alfa
The API call renders the puppet.conf template, that's why I pre-register
the host. I have to admit that the tool (or rhsm) could just deploy the
puppet configuration file directly (taking puppet master and ca
hostnames instead of proxy names), then it could live without
preregistration, but Katello will most likely register the host anyway
prior the fact upload, so it's no saver.
The tool is not much expected to be used with standalone Foreman. It
makes more sense with Katello plugin.
That works fine. Take a look at the ENC node.rb - it uploads the
facts, and then asks for the ENC yaml, which wouldn't work if the host
wasn't created. It doesn't need to precreate the host, Foreman handles
that for us. The only tricky bit here is setting up access so we can
get at the template, but that could be accomplished in a number of
ways (I can think of 3 off the top of my head), and saves you having
to use full host-edit/create rights API access just to link up Puppet.
To give you some idea in psuedocode
#!/bin/fake
POST /api/facts {fact json}
(host is created in foreman)
<something to enable access to templates>
GET /unattended/puppet #end
That seems much shorter, more maintainable, and applicable to more
scenarios, to me.
Greg
···
On 3 March 2014 09:48, Lukas Zapletal wrote:
>> Puppet *Facts* upload will create a Host, which is entirely usable
>> here, since you have access to Facter. While not use that instead of
>> creating the Host over the API? That will create an unmanaged host,
>> but that's generally what you want with legacy hosts anyway.
>
> Greg, the goal here is to have subscription-manager to configure puppet
> in one command. Something like this:
>
> subscription-manager --serverurl=https://satellite6.xyz.com --org=XYZ \
> --puppet-environment production --puppet-master alfa --puppet-ca alfa
> #!/bin/fake
> POST /api/facts {fact json}
> (host is created in foreman)
> <something to enable access to templates>
> GET /unattended/puppet
> #end
Thanks, now how does this bit handles multiple smart proxies? I have a
server in labX and I want it to be created with proxy proxy-labX.
> That seems much shorter, more maintainable, and applicable to more
> scenarios, to me.
I understand that having foreman_api on each managed host is just
another dependency, but using the API gives us other possibilities.
I expect the tool to be extended with things like host group. We
currently do not support host group assignment from facts, do we?
