Subscription-manager system registration in Foreman

Development
1

Hello all,

I need to make some design decisions and I want to hear your opinions.

Subscription-manager is a tool from RHEL6 that provides system
registration and subscription services. It works against Red Hat Portal
and against Katello instance (now Foreman with Katello plugin).

Katello has it's own systems table which is separate from Foreman hosts
on the database level. The plan is to merge those entities in long-term.

Subscription-manager (aka rhsm) sends out registration message together
with username/password, organization and environment currently. It is
extensible with simple plugins that can add hooks like post-registration
or post-subscribe.

Now, the task is to register Foreman host entry during the rhsm
registration process and setup Puppet which effectively mean providing
the following info as bare minimum:

  • puppet environment (note this is different from Katello environment)
  • puppetmaster proxy name
  • puppetca proxy name

Once this is done, newly created rhsm plugin can make a simple
unattended call to Foreman, download and deploy puppet.conf and
optionally call puppet to upload it's first report.

The biggest question right now is how to do the registration
integration. I created a simple Ruby script that interactively asks for
required info and does few API calls in order to create Foreman host. It
also deploys puppet.conf:

The rhsm plugin could call that but there are some drawbacks:

  • two new RPMs need to be installed on the client (foreman_api and the
    script)
  • during registration the script asks for Foreman credentials (so
    basically rhsm would ask twice)

Possible solutions:

a) Extend rhsm tool with new options (puppet environment, master, ca)
and create an orchestration that would create Foreman host.

b) Leave it as is, but at least re-use rhsm client certificate to do the
calls so no username/password is required for the Foreman host creation.

c) Other options?

Thanks for help

··· -- Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman

2

That's kind of the way I feel about it as well, I'd love to see
subscription-manager's registration process stay as streamlined as
possible. This seems like information that should be implied from the
process of registering to a particular environment/content view already,
and if any of those values need adjusting afterwards they can be done so in
the web UI.

We already require the user to specify credentials, and an org/content view

  • potentially activation keys, throwing in puppet env, puppetmaster proxy
    and puppetca proxy feels like more than a user is going to know or want to
    input during that process.

IMO it would be great if this was driven server side by config per the org
or content view and handled transparently to the user. The subscription
manager plugin gets a lot simpler (just fetch puppet config and run it),
and the registration process does not get any more complicated.

Cheers,

Devan

··· On Wednesday, March 26, 2014 7:03:26 AM UTC-3, Tom McKay wrote: > > Hosts must register to a "lifecycle environment and content view" (aka > katello environment and content view) through subscription-manager. Would > it make sense to just associate the puppet environment with the lifecycle > environment (and/or content view)? Then when the host registered with > sub-mgr it would get the proper info. > >
3

Hosts must register to a "lifecycle environment and content view" (aka katello environment and content view) through subscription-manager. Would it make sense to just associate the puppet environment with the lifecycle environment (and/or content view)? Then when the host registered with sub-mgr it would get the proper info.

··· ----- Original Message ----- > Hello all, > > I need to make some design decisions and I want to hear your opinions. > > Subscription-manager is a tool from RHEL6 that provides system > registration and subscription services. It works against Red Hat Portal > and against Katello instance (now Foreman with Katello plugin). > > Katello has it's own systems table which is separate from Foreman hosts > on the database level. The plan is to merge those entities in long-term. > > Subscription-manager (aka rhsm) sends out registration message together > with username/password, organization and environment currently. It is > extensible with simple plugins that can add hooks like post-registration > or post-subscribe. > > Now, the task is to register Foreman host entry during the rhsm > registration process and setup Puppet which effectively mean providing > the following info as bare minimum: > > - puppet environment (note this is different from Katello environment) > - puppetmaster proxy name > - puppetca proxy name > > Once this is done, newly created rhsm plugin can make a simple > unattended call to Foreman, download and deploy puppet.conf and > optionally call puppet to upload it's first report. > > The biggest question right now is how to do the registration > integration. I created a simple Ruby script that interactively asks for > required info and does few API calls in order to create Foreman host. It > also deploys puppet.conf: > > https://github.com/lzap/foreman-client-tools/blob/master/bin/puppet-foreman > > The rhsm plugin could call that but there are some drawbacks: > > - two new RPMs need to be installed on the client (foreman_api and the > script) > - during registration the script asks for Foreman credentials (so > basically rhsm would ask twice) > > Possible solutions: > > a) Extend rhsm tool with new options (puppet environment, master, ca) > and create an orchestration that would create Foreman host. > > b) Leave it as is, but at least re-use rhsm client certificate to do the > calls so no username/password is required for the Foreman host creation. > > c) Other options? > > Thanks for help > > -- > Later, > > Lukas "lzap" Zapletal > irc: lzap #theforeman > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >
4

I tend to agree. For creating a foreman host and associating it to a
puppet environment, katello should be able to do this as part of the
system create process (i.e. subscription-manager register) rather than
require a separate request to the server. In other words, it could/can
create the foreman host and associate it with the proper puppet
environment, based upon the katello lifecycle environment and content
view that the user provided during registration. This will make it very
simple to support the linkage between 'katello system' and 'foreman
host' in the near-term.

As for handling the puppetmaster and puppetca proxy names, I'm not sure
the best avenue for handling those. We could make those additional
extensions to subscription-manager that the user provides. Another
alternative (or additional mechanism we could support) might be to
extend the katello activation keys to include those parameters. If we
did that, we could make it extremely easy to associate a system to
lifecycle environment, content view, subscriptions, system groups,
puppetmaster proxy, puppetmaster proxy…etc.

cheers,
Brad

··· On 03/26/2014 07:27 AM, Devan Goodwin wrote: > > > On Wednesday, March 26, 2014 7:03:26 AM UTC-3, Tom McKay wrote: > > Hosts must register to a "lifecycle environment and content view" > (aka katello environment and content view) through > subscription-manager. Would it make sense to just associate the > puppet environment with the lifecycle environment (and/or content > view)? Then when the host registered with sub-mgr it would get the > proper info. > > > That's kind of the way I feel about it as well, I'd love to see > subscription-manager's registration process stay as streamlined as > possible. This seems like information that should be implied from the > process of registering to a particular environment/content view > already, and if any of those values need adjusting afterwards they can > be done so in the web UI. > > We already require the user to specify credentials, and an org/content > view + potentially activation keys, throwing in puppet env, > puppetmaster proxy and puppetca proxy feels like more than a user is > going to know or want to input during that process. > > IMO it would be great if this was driven server side by config per the > org or content view and handled transparently to the user. The > subscription manager plugin gets a lot simpler (just fetch puppet > config and run it), and the registration process does not get any more > complicated. > > Cheers, > > Devan > -- > You received this message because you are subscribed to the Google > Groups "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to foreman-dev+unsubscribe@googlegroups.com > . > For more options, visit https://groups.google.com/d/optout.
5

> Hello all,
>
> I need to make some design decisions and I want to hear your opinions.
>
> Subscription-manager is a tool from RHEL6 that provides system
> registration and subscription services. It works against Red Hat Portal
> and against Katello instance (now Foreman with Katello plugin).
>
> Katello has it's own systems table which is separate from Foreman hosts
> on the database level. The plan is to merge those entities in long-term.
>
> Subscription-manager (aka rhsm) sends out registration message together
> with username/password, organization and environment currently. It is
> extensible with simple plugins that can add hooks like post-registration
> or post-subscribe.
>
> Now, the task is to register Foreman host entry during the rhsm
> registration process and setup Puppet which effectively mean providing
> the following info as bare minimum:
>
> - puppet environment (note this is different from Katello environment)
This is not entirely true. For every content view environment
combination (i.e. Dev/MyView), there is a puppet environment created.
This would mean that Library needs to be handled somehow as a system can
register straight to that, and that we need to discuss the ability for
users to use a puppet environment created outside the Content View
Workflow (as right now I'm not sure they can assign a hostgroup to such
an environment).

> - puppetmaster proxy name
> - puppetca proxy name
>
> Once this is done, newly created rhsm plugin can make a simple
> unattended call to Foreman, download and deploy puppet.conf and
> optionally call puppet to upload it's first report.
>
> The biggest question right now is how to do the registration
> integration. I created a simple Ruby script that interactively asks for
> required info and does few API calls in order to create Foreman host. It
> also deploys puppet.conf:
>
> https://github.com/lzap/foreman-client-tools/blob/master/bin/puppet-foreman
>
> The rhsm plugin could call that but there are some drawbacks:
>
> - two new RPMs need to be installed on the client (foreman_api and the
> script)
> - during registration the script asks for Foreman credentials (so
> basically rhsm would ask twice)
>
> Possible solutions:
>
> a) Extend rhsm tool with new options (puppet environment, master, ca)
> and create an orchestration that would create Foreman host.
>
> b) Leave it as is, but at least re-use rhsm client certificate to do the
> calls so no username/password is required for the Foreman host creation.
>
> c) Other options?
>
> Thanks for help
>

We've been having discussions from the start of enginification of
katello on how to unify the host and system model. Since the naming
aspect is mostly settled now all that is left is design on how to the
different interactions behave as they become a single object. I think
we've all agreed that they need to be a single object from the users
perspective.

To that end it doesn't' make sense in my mind to have an RHSM plugin
call the host creation api in foreman if it is already making a
registration call to katello.

I think it would make sense for the system to pass up all its
registration information as part of its rhsm registration (and a host
would be created as part of this). Then afterwards the information for
its puppet master is fetched from the api (coming from its host group?)
and the plugin configures puppet to point to that puppet master. There
are some details that would need to be worked out, but I think that
should be our goal.

To accomplish this a good deal of the host/system unification needs to
be done, but I think that is the right way to do it.

-Justin

··· On 03/26/2014 04:40 AM, Lukas Zapletal wrote:
6

Hello Guys,

+1 to extend subscription manager

  1. when i run subscription-manager register --org <Test> --environment
    development …

it should register server in katello as well as foreman if doesnt exist
already …

now, above i have not provided Puppet master and Puppet CA and Puppet ENV
as well … in below mail trail i have seen puppet takes ENV as
development/MyView … but i really dont understand why puppet will take
that ENV ? can't we enforce to use Same ENV created in katello
Organization to available to puppet + Additional ??

that way in above command it should pick up development puppet environment
… also it should automatically pick up puppet master and CA if
we dont provide it

  1. subscription-manager register --org <test> --environment development
    –puppet-master <master1> --CA <ca1>

this should be able to generate puppet.conf on client machine … now the
question is how it will apply puppet classes to that node ?? ( may needs to
manually add to host group to apply classes ? )

also it will be good if Katello SystemGroup and Foreman HostGroups are same
entity and if we add system in SystemGroup in katello it should be added to
that HostGroup as well and start applying classes available to that host
group …

I have just started playing with Puppet … so above may not make sense to
you guys …but just thought of sharing it … if it doesnt help, may be it
will improves my thinking … :slight_smile:

Regards,
DJ

··· On Wednesday, 26 March 2014 14:25:26 UTC+5:45, Lukas Zapletal wrote: > > Hello all, > > I need to make some design decisions and I want to hear your opinions. > > Subscription-manager is a tool from RHEL6 that provides system > registration and subscription services. It works against Red Hat Portal > and against Katello instance (now Foreman with Katello plugin). > > Katello has it's own systems table which is separate from Foreman hosts > on the database level. The plan is to merge those entities in long-term. > > Subscription-manager (aka rhsm) sends out registration message together > with username/password, organization and environment currently. It is > extensible with simple plugins that can add hooks like post-registration > or post-subscribe. > > Now, the task is to register Foreman host entry during the rhsm > registration process and setup Puppet which effectively mean providing > the following info as bare minimum: > > - puppet environment (note this is different from Katello environment) > - puppetmaster proxy name > - puppetca proxy name > > Once this is done, newly created rhsm plugin can make a simple > unattended call to Foreman, download and deploy puppet.conf and > optionally call puppet to upload it's first report. > > The biggest question right now is how to do the registration > integration. I created a simple Ruby script that interactively asks for > required info and does few API calls in order to create Foreman host. It > also deploys puppet.conf: > > https://github.com/lzap/foreman-client-tools/blob/master/bin/puppet-foreman > > The rhsm plugin could call that but there are some drawbacks: > > - two new RPMs need to be installed on the client (foreman_api and the > script) > - during registration the script asks for Foreman credentials (so > basically rhsm would ask twice) > > Possible solutions: > > a) Extend rhsm tool with new options (puppet environment, master, ca) > and create an orchestration that would create Foreman host. > > b) Leave it as is, but at least re-use rhsm client certificate to do the > calls so no username/password is required for the Foreman host creation. > > c) Other options? > > Thanks for help > > -- > Later, > > Lukas "lzap" Zapletal > irc: lzap #theforeman >
7

Activation keys seems like a fair solution for setting those values. Should
there be default behaviour without specifying any? What would most
Satellite deployments look like in terms of puppetmaster proxy and puppetca
proxy? Would there likely just be one?

Cheers,

Devan

··· On Wed, Mar 26, 2014 at 11:17 AM, Brad Buckingham wrote:

I tend to agree. For creating a foreman host and associating it to a
puppet environment, katello should be able to do this as part of the system
create process (i.e. subscription-manager register) rather than require a
separate request to the server. In other words, it could/can create the
foreman host and associate it with the proper puppet environment, based
upon the katello lifecycle environment and content view that the user
provided during registration. This will make it very simple to support the
linkage between ‘katello system’ and ‘foreman host’ in the near-term.

As for handling the puppetmaster and puppetca proxy names, I’m not sure
the best avenue for handling those. We could make those additional
extensions to subscription-manager that the user provides. Another
alternative (or additional mechanism we could support) might be to extend
the katello activation keys to include those parameters. If we did that,
we could make it extremely easy to associate a system to lifecycle
environment, content view, subscriptions, system groups, puppetmaster
proxy, puppetmaster proxy…etc.

8

That approach sounds good to me.

Do you envision any additional information needing to be sent by the client
during registration?

Lukas you mentioned your script would need a patched foreman, is there an
API call today where the client could fetch it's puppet config from
Satellite?

Once config is fetched, does anyone have a handle on exactly what steps
need to be done for initial puppet run?

Trying to determine what a design for this plugin would look like and
whether or not we could start work on it already.

Thanks,

Devan

··· On Wed, Mar 26, 2014 at 11:22 AM, Justin Sherrill wrote:

On 03/26/2014 04:40 AM, Lukas Zapletal wrote:

Hello all,

I need to make some design decisions and I want to hear your opinions.

Subscription-manager is a tool from RHEL6 that provides system
registration and subscription services. It works against Red Hat Portal
and against Katello instance (now Foreman with Katello plugin).

Katello has it’s own systems table which is separate from Foreman hosts
on the database level. The plan is to merge those entities in long-term.

Subscription-manager (aka rhsm) sends out registration message together
with username/password, organization and environment currently. It is
extensible with simple plugins that can add hooks like post-registration
or post-subscribe.

Now, the task is to register Foreman host entry during the rhsm
registration process and setup Puppet which effectively mean providing
the following info as bare minimum:

  • puppet environment (note this is different from Katello environment)

This is not entirely true. For every content view environment combination
(i.e. Dev/MyView), there is a puppet environment created. This would mean
that Library needs to be handled somehow as a system can register straight
to that, and that we need to discuss the ability for users to use a puppet
environment created outside the Content View Workflow (as right now I’m not
sure they can assign a hostgroup to such an environment).

  • puppetmaster proxy name
  • puppetca proxy name

Once this is done, newly created rhsm plugin can make a simple
unattended call to Foreman, download and deploy puppet.conf and
optionally call puppet to upload it’s first report.

The biggest question right now is how to do the registration
integration. I created a simple Ruby script that interactively asks for
required info and does few API calls in order to create Foreman host. It
also deploys puppet.conf:

https://github.com/lzap/foreman-client-tools/blob/
master/bin/puppet-foreman

The rhsm plugin could call that but there are some drawbacks:

  • two new RPMs need to be installed on the client (foreman_api and the
    script)
  • during registration the script asks for Foreman credentials (so
    basically rhsm would ask twice)

Possible solutions:

a) Extend rhsm tool with new options (puppet environment, master, ca)
and create an orchestration that would create Foreman host.

b) Leave it as is, but at least re-use rhsm client certificate to do the
calls so no username/password is required for the Foreman host creation.

c) Other options?

Thanks for help

We’ve been having discussions from the start of enginification of katello
on how to unify the host and system model. Since the naming aspect is
mostly settled now all that is left is design on how to the different
interactions behave as they become a single object. I think we’ve all
agreed that they need to be a single object from the users perspective.

To that end it doesn’t’ make sense in my mind to have an RHSM plugin call
the host creation api in foreman if it is already making a registration
call to katello.

I think it would make sense for the system to pass up all its registration
information as part of its rhsm registration (and a host would be created
as part of this). Then afterwards the information for its puppet master is
fetched from the api (coming from its host group?) and the plugin
configures puppet to point to that puppet master. There are some details
that would need to be worked out, but I think that should be our goal.

To accomplish this a good deal of the host/system unification needs to be
done, but I think that is the right way to do it.

9

> As for handling the puppetmaster and puppetca proxy names, I'm not
> sure the best avenue for handling those. We could make those
> additional extensions to subscription-manager that the user
> provides. Another alternative (or additional mechanism we could
> support) might be to extend the katello activation keys to include
> those parameters. If we did that, we could make it extremely easy
> to associate a system to lifecycle environment, content view,
> subscriptions, system groups, puppetmaster proxy, puppetmaster
> proxy…etc.

I get better picture now.

Puppet environment is tied to Env/CV, I guess this guy is solved.

In regard to puppet master/ca, we can either:

a) associate a host group to Content Environment (or/and Content View).

b) infer those from Organization/Location.

c) associate Content Env / CV with individual master/ca proxies.

Other or combination?

Re (a) is the most logical way to me, host group already has the proxy
association. The question is if we would like to see creating host
groups automatically for each CV (like we do with puppet environments).
That does not make much sense, therefore the manual only method seems to
be more appropriate. With some sane "default" value per Location or
Organization.

Re (b) is also a solution if we notice that proxies are totally
independent of puppet environments. All puppet environments are deployed
across all proxies by default and it is logical to tie proxies to
Locations. Once a system is being registered in a Location, that would
logically mean it should be auto-assigned to particular proxy. This
is essentially the "default" fallback method mentioned in (a), but it
could be also a standalone solution.

Re © is a solution if we do not want to use host groups for that. We'd
need to associate proxies with individual Envs/CVs. Actually it would
work the same way as (a) or (a) + (b) but there would be no host group
involved. This feels more straightforward for end users, you just need
to select proxies without additional entity for particular CVs. But it
is not as flexible as with host groups.

Does it make sense to tie proxies to Content Environments or to Content
Views? IMHO I see Content View as something that change way too often
and Environment would be better match.

Since activation keys define Org/Loc/Env/CV, there should be no change
in this area required. Once CV is determined, host group or individual
smart proxies are assigned and puppet can be configured.

To me it looks like (a) + (b) is the right solution.

··· -- Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman

10

Be wary of relying solely on activation keys since they do not require (and in fact prevent) specifying a password. I would certainly wish to see foreman concepts added to activation keys, but not as the sole path for linking to puppet context.

··· ----- Original Message ----- > On Wed, Mar 26, 2014 at 11:17 AM, Brad Buckingham > wrote: > > > > > I tend to agree. For creating a foreman host and associating it to a > > puppet environment, katello should be able to do this as part of the system > > create process (i.e. subscription-manager register) rather than require a > > separate request to the server. In other words, it could/can create the > > foreman host and associate it with the proper puppet environment, based > > upon the katello lifecycle environment and content view that the user > > provided during registration. This will make it very simple to support the > > linkage between 'katello system' and 'foreman host' in the near-term. > > > > As for handling the puppetmaster and puppetca proxy names, I'm not sure > > the best avenue for handling those. We could make those additional > > extensions to subscription-manager that the user provides. Another > > alternative (or additional mechanism we could support) might be to extend > > the katello activation keys to include those parameters. If we did that, > > we could make it extremely easy to associate a system to lifecycle > > environment, content view, subscriptions, system groups, puppetmaster > > proxy, puppetmaster proxy....etc. > > > > Activation keys seems like a fair solution for setting those values. Should > there be default behaviour without specifying any? What would most > Satellite deployments look like in terms of puppetmaster proxy and puppetca > proxy? Would there likely just be one? > > Cheers, > > Devan > > -- > You received this message because you are subscribed to the Google Groups > "foreman-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to foreman-dev+unsubscribe@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. >
11

>
>
>
>
>
> Hello all,
>
> I need to make some design decisions and I want to hear your
> opinions.
>
> Subscription-manager is a tool from RHEL6 that provides system
> registration and subscription services. It works against Red
> Hat Portal
> and against Katello instance (now Foreman with Katello plugin).
>
> Katello has it's own systems table which is separate from
> Foreman hosts
> on the database level. The plan is to merge those entities in
> long-term.
>
> Subscription-manager (aka rhsm) sends out registration message
> together
> with username/password, organization and environment
> currently. It is
> extensible with simple plugins that can add hooks like
> post-registration
> or post-subscribe.
>
> Now, the task is to register Foreman host entry during the rhsm
> registration process and setup Puppet which effectively mean
> providing
> the following info as bare minimum:
>
> - puppet environment (note this is different from Katello
> environment)
>
> This is not entirely true. For every content view environment
> combination (i.e. Dev/MyView), there is a puppet environment
> created. This would mean that Library needs to be handled somehow
> as a system can register straight to that, and that we need to
> discuss the ability for users to use a puppet environment created
> outside the Content View Workflow (as right now I'm not sure they
> can assign a hostgroup to such an environment).
>
>
> - puppetmaster proxy name
> - puppetca proxy name
>
> Once this is done, newly created rhsm plugin can make a simple
> unattended call to Foreman, download and deploy puppet.conf and
> optionally call puppet to upload it's first report.
>
> The biggest question right now is how to do the registration
> integration. I created a simple Ruby script that interactively
> asks for
> required info and does few API calls in order to create
> Foreman host. It
> also deploys puppet.conf:
>
> https://github.com/lzap/foreman-client-tools/blob/master/bin/puppet-foreman
>
> The rhsm plugin could call that but there are some drawbacks:
>
> - two new RPMs need to be installed on the client (foreman_api
> and the
> script)
> - during registration the script asks for Foreman credentials (so
> basically rhsm would ask twice)
>
> Possible solutions:
>
> a) Extend rhsm tool with new options (puppet environment,
> master, ca)
> and create an orchestration that would create Foreman host.
>
> b) Leave it as is, but at least re-use rhsm client certificate
> to do the
> calls so no username/password is required for the Foreman host
> creation.
>
> c) Other options?
>
> Thanks for help
>
>
> We've been having discussions from the start of enginification of
> katello on how to unify the host and system model. Since the
> naming aspect is mostly settled now all that is left is design on
> how to the different interactions behave as they become a single
> object. I think we've all agreed that they need to be a single
> object from the users perspective.
>
> To that end it doesn't' make sense in my mind to have an RHSM
> plugin call the host creation api in foreman if it is already
> making a registration call to katello.
>
> I think it would make sense for the system to pass up all its
> registration information as part of its rhsm registration (and a
> host would be created as part of this). Then afterwards the
> information for its puppet master is fetched from the api (coming
> from its host group?) and the plugin configures puppet to point to
> that puppet master. There are some details that would need to be
> worked out, but I think that should be our goal.
>
> To accomplish this a good deal of the host/system unification
> needs to be done, but I think that is the right way to do it.
>
>
> That approach sounds good to me.
>
> Do you envision any additional information needing to be sent by the
> client during registration?

Ideally this would be answered by the design for host/system
unification. Currently the only thing i can foresee is a host group
(assuming an activation key was not supplied). We would likely need
some sort of 'default' host group for each org potentially (but I'm
getting ahead of myself). I could see the plugin verifying the
hostgroup exists prior to the registration and then assigning it to the
host group after registration.

In Satellite 6 since there is already a puppet master installed on the
satellite it seems safe to 'default' to that if the host doesn't somehow
get assigned to a different puppet master via a host group.

>
> Lukas you mentioned your script would need a patched foreman, is there
> an API call today where the client could fetch it's puppet config from
> Satellite?

Katello has been moving to isolate all RHSM actions to its own
controller and route (/rhsm). This route enables cert-based
authentication and is meant for rhsm communication. Unless there is
some reason not to, I'd prefer to add a new API call there. It helps
isolate potential conflicts with the RHSM client.

-Justin

··· On 03/26/2014 11:26 AM, Devan Goodwin wrote: > On Wed, Mar 26, 2014 at 11:22 AM, Justin Sherrill > wrote: > On 03/26/2014 04:40 AM, Lukas Zapletal wrote:

Once config is fetched, does anyone have a handle on exactly what
steps need to be done for initial puppet run?

Trying to determine what a design for this plugin would look like and
whether or not we could start work on it already.

Thanks,

Devan

You received this message because you are subscribed to the Google
Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send
an email to foreman-dev+unsubscribe@googlegroups.com
mailto:foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

12

I would like to see a way to work without activation keys.

– bk

··· On 03/26/2014 11:23 AM, Devan Goodwin wrote: > > > > On Wed, Mar 26, 2014 at 11:17 AM, Brad Buckingham > <bbuckingham@redhat.com > wrote: > > > I tend to agree. For creating a foreman host and associating it to > a puppet environment, katello should be able to do this as part of > the system create process (i.e. subscription-manager register) > rather than require a separate request to the server. In other > words, it could/can create the foreman host and associate it with > the proper puppet environment, based upon the katello lifecycle > environment and content view that the user provided during > registration. This will make it very simple to support the linkage > between 'katello system' and 'foreman host' in the near-term. > > As for handling the puppetmaster and puppetca proxy names, I'm not > sure the best avenue for handling those. We could make those > additional extensions to subscription-manager that the user > provides. Another alternative (or additional mechanism we could > support) might be to extend the katello activation keys to include > those parameters. If we did that, we could make it extremely easy > to associate a system to lifecycle environment, content view, > subscriptions, system groups, puppetmaster proxy, puppetmaster > proxy....etc. > > > Activation keys seems like a fair solution for setting those values. > Should there be default behaviour without specifying any? What would > most Satellite deployments look like in terms of puppetmaster proxy and > puppetca proxy? Would there likely just be one?
13

> Lukas you mentioned your script would need a patched foreman, is there an
> API call today where the client could fetch it's puppet config from
> Satellite?

Yeah, that bit is only necessary for puppet.conf deployment.

> Once config is fetched, does anyone have a handle on exactly what steps
> need to be done for initial puppet run?

All you need to do is really:

  • drop puppet.conf
  • puppet agent -t

Or start puppet agent daemon and wait 30 minutes (default value for
check-in).

> Trying to determine what a design for this plugin would look like and
> whether or not we could start work on it already.

That's all we need. We can implement the plugin right away if we agree
this is all the plugin should do. Then it is just a one simple call to a
REST API service.

I can get the above patch merged for you, but until we solve the
puppetmaster/puppetca flags, it will likely render wrong configuration
(enough for testing the plugin tho).

I will send a short recap of what we have soon.

··· -- Later,

Lukas “lzap” Zapletal
irc: lzap #theforeman