I fiddled a bit with the puppet-foreman module to put the
configuration into a YAML file /etc/puppet/foreman.yaml on the
puppetmaster nodes:
https://github.com/frimik/puppet-foreman/compare/parameters_and_yaml
And then taking advantage of those params in the puppet-puppet module:
https://github.com/frimik/puppet-puppet/commit/68e1e0c9dcbf453984093a9221f7de842aabc0fb
Would be nice if someone could take a cursory look to see if I'm
thinking straight here…
I also considered putting the config inside puppet.conf as custom
parameters, maybe in a [foreman] section but that's for later and only
if you think it makes any sense.
For the report.rb plugin, foreman() and smartvar() functions it could
be quite nifty but the external node script would not benefit much
since it's an 'exec' terminus script.
Mikael.
I like the general idea of removing the baked in values from the
external_nodes script. However, why can't all of these values be merged
into the existing /etc/foreman/settings.yaml config file? The puppet
server name and conf dir already have to be set there.
-Josh
···
--
On 09/09/2012 02:26 PM, Mikael Fridh wrote:
> I fiddled a bit with the puppet-foreman module to put the
> configuration into a YAML file /etc/puppet/foreman.yaml on the
> puppetmaster nodes:
> https://github.com/frimik/puppet-foreman/compare/parameters_and_yaml
>
> And then taking advantage of those params in the puppet-puppet module:
> https://github.com/frimik/puppet-puppet/commit/68e1e0c9dcbf453984093a9221f7de842aabc0fb
>
> Would be nice if someone could take a cursory look to see if I'm
> thinking straight here...
>
> I also considered putting the config inside puppet.conf as custom
> parameters, maybe in a [foreman] section but that's for later and only
> if you think it makes any sense.
> For the report.rb plugin, foreman() and smartvar() functions it could
> be quite nifty but the external node script would not benefit much
> since it's an 'exec' terminus script.
>
> Mikael.
>
The reason we can't do that is the classifier script runs on the
puppetmaster and foreman may not run on the same host. It's more viable
to use the proxy settings, but you can use Foreman as an ENC without the
proxy so that doesn't work well either right now.
-Sam
···
On 09/13/2012 03:37 PM, Joshua hoblitt wrote:
> I like the general idea of removing the baked in values from the
> external_nodes script. However, why can't all of these values be merged
> into the existing /etc/foreman/settings.yaml config file? The puppet
> server name and conf dir already have to be set there.
>
> -Josh
>
> --
> On 09/09/2012 02:26 PM, Mikael Fridh wrote:
>> I fiddled a bit with the puppet-foreman module to put the
>> configuration into a YAML file /etc/puppet/foreman.yaml on the
>> puppetmaster nodes:
>> https://github.com/frimik/puppet-foreman/compare/parameters_and_yaml
>>
>> And then taking advantage of those params in the puppet-puppet module:
>> https://github.com/frimik/puppet-puppet/commit/68e1e0c9dcbf453984093a9221f7de842aabc0fb
>>
>> Would be nice if someone could take a cursory look to see if I'm
>> thinking straight here...
>>
>> I also considered putting the config inside puppet.conf as custom
>> parameters, maybe in a [foreman] section but that's for later and only
>> if you think it makes any sense.
>> For the report.rb plugin, foreman() and smartvar() functions it could
>> be quite nifty but the external node script would not benefit much
>> since it's an 'exec' terminus script.
>>
>> Mikael.
>>
>
>
That's a good point but since foreman-proxy must be running on the same
node as the puppetmaster, isn't that a reasonable place to combine
configuration files?
-Josh
···
On 09/13/2012 12:43 PM, Sam Kottler wrote:
> The reason we can't do that is the classifier script runs on the
> puppetmaster and foreman may not run on the same host. It's more viable
> to use the proxy settings, but you can use Foreman as an ENC without the
> proxy so that doesn't work well either right now.
–
Not to complicate this any further but is there any possible scenario
where a single foreman-proxy might have more then one foreman instance
pointed at it?
-Josh
···
On 09/13/2012 01:30 PM, Joshua hoblitt wrote:
> On 09/13/2012 12:43 PM, Sam Kottler wrote:
>> The reason we can't do that is the classifier script runs on the
>> puppetmaster and foreman may not run on the same host. It's more viable
>> to use the proxy settings, but you can use Foreman as an ENC without the
>> proxy so that doesn't work well either right now.
>
> That's a good point but since foreman-proxy must be running on the same
> node as the puppetmaster, isn't that a reasonable place to combine
> configuration files?
–
I could see puppet.conf, except it treats unknown blocks as
environment definitions. Perhaps formally split it into a
foremanenc.conf file? (To do that we really have to acknowledge this
ENC script as the official supported script, as we have been a bit
wish-washy about it.
Thanks,
Brian
···
On Thu, Sep 13, 2012 at 3:43 PM, Sam Kottler wrote:
> On 09/13/2012 03:37 PM, Joshua hoblitt wrote:
>>
>> I like the general idea of removing the baked in values from the
>> external_nodes script. However, why can't all of these values be merged
>> into the existing /etc/foreman/settings.yaml config file? The puppet
>> server name and conf dir already have to be set there.
>>
>> -Josh
>>
>> --
>> On 09/09/2012 02:26 PM, Mikael Fridh wrote:
>>>
>>> I fiddled a bit with the puppet-foreman module to put the
>>> configuration into a YAML file /etc/puppet/foreman.yaml on the
>>> puppetmaster nodes:
>>> https://github.com/frimik/puppet-foreman/compare/parameters_and_yaml
>>>
>>> And then taking advantage of those params in the puppet-puppet module:
>>>
>>> https://github.com/frimik/puppet-puppet/commit/68e1e0c9dcbf453984093a9221f7de842aabc0fb
>>>
>>> Would be nice if someone could take a cursory look to see if I'm
>>> thinking straight here...
>>>
>>> I also considered putting the config inside puppet.conf as custom
>>> parameters, maybe in a [foreman] section but that's for later and only
>>> if you think it makes any sense.
>>> For the report.rb plugin, foreman() and smartvar() functions it could
>>> be quite nifty but the external node script would not benefit much
>>> since it's an 'exec' terminus script.
>>>
>>> Mikael.
>>>
>>
>>
> The reason we can't do that is the classifier script runs on the
> puppetmaster and foreman may not run on the same host. It's more viable to
> use the proxy settings, but you can use Foreman as an ENC without the proxy
> so that doesn't work well either right now.
>
> -Sam
Well you don't have to use the proxy to just use Foreman as an ENC…
···
On 09/13/2012 04:30 PM, Joshua hoblitt wrote:
> On 09/13/2012 12:43 PM, Sam Kottler wrote:
>> The reason we can't do that is the classifier script runs on the
>> puppetmaster and foreman may not run on the same host. It's more viable
>> to use the proxy settings, but you can use Foreman as an ENC without the
>> proxy so that doesn't work well either right now.
>
> That's a good point but since foreman-proxy must be running on the same
> node as the puppetmaster, isn't that a reasonable place to combine
> configuration files?
>
> -Josh
>
> --
>
I don't believe it's a supported configuration. -Brian
···
On Thu, Sep 13, 2012 at 4:35 PM, Joshua hoblitt wrote:
> On 09/13/2012 01:30 PM, Joshua hoblitt wrote:
>> On 09/13/2012 12:43 PM, Sam Kottler wrote:
>>> The reason we can't do that is the classifier script runs on the
>>> puppetmaster and foreman may not run on the same host. It's more viable
>>> to use the proxy settings, but you can use Foreman as an ENC without the
>>> proxy so that doesn't work well either right now.
>>
>> That's a good point but since foreman-proxy must be running on the same
>> node as the puppetmaster, isn't that a reasonable place to combine
>> configuration files?
>
> Not to complicate this any further but is there any possible scenario
> where a single foreman-proxy might have more then one foreman instance
> pointed at it?
>
> -Josh
>
> --
That feature is actually somewhat of a problem for supporting multiple
puppermasters. It requires that you very carefully have to ensure that
your foreman host and all puppermasters have the exact same set of
puppet modules visible (or at least class names used in those modules).
If that's really a desired configuration, it seems like foreman should
discover puppet classes via the proxy anyways, and maintain a list of
puppetclasses per puppermaster/proxy. You could also turn it around and
have foreman push puppet modules out to the proxies but independent
puppet class names spaces per proxy seems more flexible.
-Josh
···
On 09/13/2012 01:33 PM, Sam Kottler wrote:
> Well you don't have to use the proxy to just use Foreman as an ENC...
–
If we create another config file that just means there is another file
for users to have to configure and manage; it doesn't really leave us in
a better state than the settings at the top of the ENC script IMHO.
···
On 09/13/2012 03:53 PM, Brian Gupta wrote:
> I could see puppet.conf, except it treats unknown blocks as
> environment definitions. Perhaps formally split it into a
> foremanenc.conf file? (To do that we really have to acknowledge this
> ENC script as the official supported script, as we have been a bit
> wish-washy about it.
>
> Thanks,
> Brian
>
> On Thu, Sep 13, 2012 at 3:43 PM, Sam Kottler wrote:
>> On 09/13/2012 03:37 PM, Joshua hoblitt wrote:
>>>
>>> I like the general idea of removing the baked in values from the
>>> external_nodes script. However, why can't all of these values be merged
>>> into the existing /etc/foreman/settings.yaml config file? The puppet
>>> server name and conf dir already have to be set there.
>>>
>>> -Josh
>>>
>>> --
>>> On 09/09/2012 02:26 PM, Mikael Fridh wrote:
>>>>
>>>> I fiddled a bit with the puppet-foreman module to put the
>>>> configuration into a YAML file /etc/puppet/foreman.yaml on the
>>>> puppetmaster nodes:
>>>> https://github.com/frimik/puppet-foreman/compare/parameters_and_yaml
>>>>
>>>> And then taking advantage of those params in the puppet-puppet module:
>>>>
>>>> https://github.com/frimik/puppet-puppet/commit/68e1e0c9dcbf453984093a9221f7de842aabc0fb
>>>>
>>>> Would be nice if someone could take a cursory look to see if I'm
>>>> thinking straight here...
>>>>
>>>> I also considered putting the config inside puppet.conf as custom
>>>> parameters, maybe in a [foreman] section but that's for later and only
>>>> if you think it makes any sense.
>>>> For the report.rb plugin, foreman() and smartvar() functions it could
>>>> be quite nifty but the external node script would not benefit much
>>>> since it's an 'exec' terminus script.
>>>>
>>>> Mikael.
>>>>
>>>
>>>
>> The reason we can't do that is the classifier script runs on the
>> puppetmaster and foreman may not run on the same host. It's more viable to
>> use the proxy settings, but you can use Foreman as an ENC without the proxy
>> so that doesn't work well either right now.
>>
>> -Sam
Josh,
I'm not saying that it's the best configuration, but it's certainly
something that exists out in the wild right now and we should continue
to support that configuration.
···
On 09/13/2012 04:44 PM, Joshua hoblitt wrote:
> On 09/13/2012 01:33 PM, Sam Kottler wrote:
>> Well you don't have to use the proxy to just use Foreman as an ENC...
>
> That feature is actually somewhat of a problem for supporting multiple
> puppermasters. It requires that you very carefully have to ensure that
> your foreman host and all puppermasters have the exact same set of
> puppet modules visible (or at least class names used in those modules).
> If that's really a desired configuration, it seems like foreman should
> discover puppet classes via the proxy anyways, and maintain a list of
> puppetclasses per puppermaster/proxy. You could also turn it around and
> have foreman push puppet modules out to the proxies but independent
> puppet class names spaces per proxy seems more flexible.
>
> -Josh
>
> --
>
I honestly think it's "non-obvious" to have configuration values baked
into .rb files. Mostly users will look for .conf/.cfg/.ini/.yaml files
first.
-Josh
···
On 09/13/2012 01:00 PM, Sam Kottler wrote:
> If we create another config file that just means there is another file
> for users to have to configure and manage; it doesn't really leave us in
> a better state than the settings at the top of the ENC script IMHO.
–
Wouldn't requiring the proxy only for puppet class discovery continue to
support the "pure ENC" setup?
-Josh
···
On 09/13/2012 01:46 PM, Sam Kottler wrote:
> On 09/13/2012 04:44 PM, Joshua hoblitt wrote:
>> On 09/13/2012 01:33 PM, Sam Kottler wrote:
>>> Well you don't have to use the proxy to just use Foreman as an ENC...
>>
>> That feature is actually somewhat of a problem for supporting multiple
>> puppermasters. It requires that you very carefully have to ensure that
>> your foreman host and all puppermasters have the exact same set of
>> puppet modules visible (or at least class names used in those modules).
>> If that's really a desired configuration, it seems like foreman should
>> discover puppet classes via the proxy anyways, and maintain a list of
>> puppetclasses per puppermaster/proxy. You could also turn it around and
>> have foreman push puppet modules out to the proxies but independent
>> puppet class names spaces per proxy seems more flexible.
>>
>> -Josh
>>
>> --
>>
> Josh,
>
> I'm not saying that it's the best configuration, but it's certainly
> something that exists out in the wild right now and we should continue
> to support that configuration.
–
> I honestly think it's "non-obvious" to have configuration values baked
> into .rb files. Mostly users will look for .conf/.cfg/.ini/.yaml files
> first.
Coming in a bit late here, lot's of good points already…
In general I would agree with this, however, I think we're going to
annoy people either way. The current system will annoy people who
don't expect config values to be in a .rb file, but if we split it off
to a separate .conf, then we'll annoy people who think 2 files just
for one script is overkill.
If the values were re-used in some other place, then I'd be in favour
of splitting to a separate conf file. However, they're purely for the
ENC script, so I don't think a separate file is warranted. I think we
need to improve the documentation instead, so people know where to
look.
···
On 13 September 2012 21:28, Joshua hoblitt wrote:
On 13 September 2012 20:53, Brian Gupta brian.gupta@brandorr.com wrote:
(To do that we really have to acknowledge this
ENC script as the official supported script, as we have been a bit
wish-washy about it.
+1 on this. We should be properly supporting our ENC script. As
mentioned above, the documentation needs updating, so I’ve added a
task to at least try and improve the wiki regarding it.
Greg
Wow, thread is popping, didn't notice until now.
>> I honestly think it's "non-obvious" to have configuration values baked
>> into .rb files. Mostly users will look for .conf/.cfg/.ini/.yaml files
>> first.
>
> Coming in a bit late here, lot's of good points already…
>
> In general I would agree with this, however, I think we're going to
> annoy people either way. The current system will annoy people who
> don't expect config values to be in a .rb file, but if we split it off
> to a separate .conf, then we'll annoy people who think 2 files just
> for one script is overkill.
Remember there are between 0 and 4 scripts to configure on any given
puppet master… 0 if you just installed Foreman for the lulz. 4 if
you're being serious:
- /usr/lib/ruby/1.8/puppet/reports/foreman.rb
- /etc/puppet/node.rb
- lib/puppet/parser/functions/foreman.rb
- lib/puppet/parser/functions/smartvar.rb
… then there's push_facts.rb …
Is there anyone here who really prefers to have
Foreman-and-Puppet-integration specific config in
/usr/lib/ruby/1.8…/somefile.rb over /etc/puppet/foreman.yaml? If you
ignore for a few seconds the fact that you stopped feeling awkward
about it by now :-).
One minor issue I see with my config file is that it (currently)
assumes one and the same credential used for all 3 functions (in case
someone want to have each function use a separate Foreman credential.
> If the values were re-used in some other place, then I'd be in favour
> of splitting to a separate conf file. However, they're purely for the
> ENC script, so I don't think a separate file is warranted. I think we
> need to improve the documentation instead, so people know where to
> look.
Better docs never hurt!
···
On Fri, Sep 14, 2012 at 11:30 AM, Greg Sutcliffe wrote:
> On 13 September 2012 21:28, Joshua hoblitt wrote:
On 13 September 2012 20:53, Brian Gupta brian.gupta@brandorr.com wrote:
(To do that we really have to acknowledge this
ENC script as the official supported script, as we have been a bit
wish-washy about it.
+1 on this. We should be properly supporting our ENC script. As
mentioned above, the documentation needs updating, so I’ve added a
task to at least try and improve the wiki regarding it.
You could even create another node terminus. Maybe one based on the
existing rest terminus in Puppet. Maybe the exec one already wins in
how simple an interface it is though.
–
Mikael
And now I'm wondering why smartvars work at all for me since I never set
the foreman_url in smartvar.rb… hmmm… 
All 4 of those scripts need to know the url to foreman, information
that's already in foreman/settings.yml. node.rb needs to know path
information for puppet that's in the proxy configuration. If the
consensus is that the ENC configuration shouldn't be bundled with either
foreman or foreman-proxy, I think the case can be made that there should
be a separate [ly installable] foreman-enc package with it's own
/etc/foreman-enc/settings.yaml. I'm not voting in favor of that, I'm
just throwing it out there.
-Josh
···
On 09/16/2012 02:08 PM, Mikael Fridh wrote:
> Remember there are between 0 and 4 scripts to configure on any given
> puppet master... 0 if you just installed Foreman for the lulz. 4 if
> you're being serious:
> * /usr/lib/ruby/1.8/puppet/reports/foreman.rb
> * /etc/puppet/node.rb
> * lib/puppet/parser/functions/foreman.rb
> * lib/puppet/parser/functions/smartvar.rb
–
>> Remember there are between 0 and 4 scripts to configure on any given
>> puppet master… 0 if you just installed Foreman for the lulz. 4 if
>> you're being serious:
>> * /usr/lib/ruby/1.8/puppet/reports/foreman.rb
>> * /etc/puppet/node.rb
>> * lib/puppet/parser/functions/foreman.rb
>> * lib/puppet/parser/functions/smartvar.rb
>
> And now I'm wondering why smartvars work at all for me since I never set
> the foreman_url in smartvar.rb… hmmm…
I assume you know ( )but for the sake of this discussion and any
reader that doesn't - because it defaults to http://foreman.
> All 4 of those scripts need to know the url to foreman, information
> that's already in foreman/settings.yml. node.rb needs to know path
> information for puppet that's in the proxy configuration. If the
> consensus is that the ENC configuration shouldn't be bundled with either
> foreman or foreman-proxy, I think the case can be made that there should
> be a separate [ly installable] foreman-enc package with it's own
> /etc/foreman-enc/settings.yaml. I'm not voting in favor of that, I'm
> just throwing it out there.
As I mention, the deficit with my plain yaml is that it allows only to
configure one set of settings for all of the mentioned scripts. So
yes, to take it to the extreme - each script would have a separate
config but if you see the entire thing as:
-
You've got a Puppet Master
-
You install the Foreman "Puppet component"
-
You configure the Foreman "Puppet component" as a whole.
-
=> which means you've just enabled one or all of the following
functionalities:
4a. Puppet=>Foreman report processor
4b. Puppet=>Foreman ENC script
4c. Puppet=>Foreman search function
4d. Puppet=>Foreman smartvar function
-
You can install the Foreman "Puppet component" on as many servers
as you want and enable zero or all of the functionalities above.
Joshua, I'm not saying I'm right, just that I'm not convinced yet :).
···
On Mon, Sep 17, 2012 at 10:10 PM, Joshua hoblitt wrote:
> On 09/16/2012 02:08 PM, Mikael Fridh wrote:
–
Mikael
