runmode

[R.I.Pienaar]

hello,

I need to get Puppet to read its config file and specifically use the
settings like an agent would.

I need this for 2.7 and 3.0

In trying to figure this out for 3.0 I have the following:

require 'puppet'
require 'puppet/util/run_mode'
Puppet.settings.preferred_run_mode = :agent
run_mode = Puppet::Util::RunMode[ Puppet.settings.preferred_run_mode ]
Puppet.settings.initialize_app_defaults(Puppet::Settings.app_defaults_for_run_mode(run_mode))

At this point Puppet[:pidfile] is /var/lib/puppet/run/agent.pid but when I do:

# puppet agent --configprint pidfile

I get /var/run/puppet/agent.pid

What is the correct way for both 2.7 and 3.0 to initialize the settings
and to be sure I am seeing agent settings?

It's OK if the way is completely different between versions, I have a way to
handle that.

---
R.I.Pienaar

[Brice Figureau]

On 22/10/12 19:25, R.I.Pienaar wrote:
> hello,
>
> I need to get Puppet to read its config file and specifically use the
> settings like an agent would.
>
> I need this for 2.7 and 3.0
>
> In trying to figure this out for 3.0 I have the following:
>
> require 'puppet'
> require 'puppet/util/run_mode'
> Puppet.settings.preferred_run_mode = :agent

I think you might need a:
Puppet.settings.use :main, :agent

so that your code loads the correct sections from the settings file.

> run_mode = Puppet::Util::RunMode[ Puppet.settings.preferred_run_mode ]
> Puppet.settings.initialize_app_defaults(Puppet::Settings.app_defaults_for_run_mode(run_mode))
>
> At this point Puppet[:pidfile] is /var/lib/puppet/run/agent.pid but when I do:

It might be the default, which for $agent_pid is $statedir/agent.pid.
But the default $statedir is $vardir/state, so that's not quite yet that...

> # puppet agent --configprint pidfile
>
> I get /var/run/puppet/agent.pid

What is configured in your puppet.conf?

> What is the correct way for both 2.7 and 3.0 to initialize the settings
> and to be sure I am seeing agent settings?
>
> It's OK if the way is completely different between versions, I have a way to
> handle that.

I don't think there are such differences between 2.7/3.0, so it's
possible the same code could work for both versions.
--
Brice Figureau
My Blog: http://www.masterzen.fr/

[Andy Parker]

On Mon, Oct 22, 2012 at 11:03 AM, Brice Figureau
<brice-...@daysofwonder.com> wrote:
> On 22/10/12 19:25, R.I.Pienaar wrote:
>> hello,
>>
>> I need to get Puppet to read its config file and specifically use the
>> settings like an agent would.
>>
>> I need this for 2.7 and 3.0
>>
>> In trying to figure this out for 3.0 I have the following:
>>
>> require 'puppet'
>> require 'puppet/util/run_mode'
>> Puppet.settings.preferred_run_mode = :agent
>
> I think you might need a:
> Puppet.settings.use :main, :agent
>
> so that your code loads the correct sections from the settings file.
>
>> run_mode = Puppet::Util::RunMode[ Puppet.settings.preferred_run_mode ]

I believe this is the same as Puppet.run_mode

>> Puppet.settings.initialize_app_defaults(Puppet::Settings.app_defaults_for_run_mode(run_mode))

I think that before this you need to call
Puppet.settings.initialize_global_defaults

>>
>> At this point Puppet[:pidfile] is /var/lib/puppet/run/agent.pid but when I do:
>
> It might be the default, which for $agent_pid is $statedir/agent.pid.
> But the default $statedir is $vardir/state, so that's not quite yet that...
>
>> # puppet agent --configprint pidfile
>>
>> I get /var/run/puppet/agent.pid
>
> What is configured in your puppet.conf?
>
>> What is the correct way for both 2.7 and 3.0 to initialize the settings
>> and to be sure I am seeing agent settings?
>>
>> It's OK if the way is completely different between versions, I have a way to
>> handle that.
>
> I don't think there are such differences between 2.7/3.0, so it's
> possible the same code could work for both versions.

Because of the work that has gone into code loading (pluginsync and
modules) there has been a fair amount of churn in how to initialize
the settings. Since that is still not a published API, there might
still be a few more changes as we work on #7316.

I think the only way to understand how to initialize them correctly in
2.7 is going to be reading through Puppet::Application and seeing what
it does as the first few steps.

> --
> Brice Figureau
> My Blog: http://www.masterzen.fr/
>

> --
> You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
> To post to this group, send email to puppe...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
>

[Chris Price]

My intention when I was last working on this stuff was that you could simply call "Puppet.initialize_settings" (perhaps after calling Puppet.run_mode=), and that the rest

of the ugly internal stuff (initialize_application_defaults, etc.) would be abstracted away.

However, I'm not entirely sure whether this is still accurate given the recent churn that Andy mentioned.

[Andy Parker]

On Mon, Oct 22, 2012 at 12:05 PM, Chris Price <ch...@puppetlabs.com> wrote:
> My intention when I was last working on this stuff was that you could simply
> call "Puppet.initialize_settings" (perhaps after calling Puppet.run_mode=),
> and that the rest
> of the ugly internal stuff (initialize_application_defaults, etc.) would be
> abstracted away.

Out of curiosity, why wasn't run_mode a parameter that was passed to
initialize_settings?

>
> However, I'm not entirely sure whether this is still accurate given the
> recent churn that Andy mentioned.

If it isn't accurate I think that might be the API that we want to
drive towards (at least for now). It looks like it is a small enough
surface area that we can support it for a while.

[Chris Price]

On Mon, Oct 22, 2012 at 12:27 PM, Andy Parker <an...@puppetlabs.com> wrote:

On Mon, Oct 22, 2012 at 12:05 PM, Chris Price <ch...@puppetlabs.com> wrote:

Out of curiosity, why wasn't run_mode a parameter that was passed to
initialize_settings?

At the time, I think I was assuming that anyone who was trying to use puppet as library code would always be working in ":user" mode, and the omission of a run_mode parameter was in some sense a way of enforcing that assumption.

It appears that that assumption was wrong, though.  :)  So I think the parameter would be a good idea (much better than telling people to call run_mode prior to initialize_settings).

[R.I.Pienaar]

So for 3 I have this down to:

require 'puppet/util/run_mode'
Puppet.settings.preferred_run_mode = :agent

Puppet.settings.initialize_global_settings
Puppet.settings.initialize_app_defaults(Puppet::Settings.app_defaults_for_run_mode(Puppet.run_mode))

will have a play with 2.7 and see, thanks

[R.I.Pienaar]

for 2.7 it seems this is the magic:

require 'puppet'
$puppet_application_mode = Puppet::Util::RunMode[:agent]
Puppet.settings.use :main, :agent
Puppet.parse_config

have to say I am surprised about the global variable there, surely this is
not how it works?

[Jeff McCune]

On Mon, Oct 22, 2012 at 2:55 PM, R.I.Pienaar <r...@devco.net> wrote:

for 2.7 it seems this is the magic:

   require 'puppet'
   $puppet_application_mode = Puppet::Util::RunMode[:agent]
   Puppet.settings.use :main, :agent
   Puppet.parse_config

have to say I am surprised about the global variable there, surely this is
not how it works?

Sadly, yes, that's how it works.  I'm guessing it was easier to implement this as a global variable since we don't really have a service locator or what have you to cleanly get a handle on the runmode instance.

Also, please note that unless there's a documented, public method, if you implement these behaviors yourself and we change the internal behaviors in a bugfix or minor release, we make no guarantees about preserving compatibility with the external world.

The best way forward on this is to submit a pull request that defines the public API method you're looking for in Puppet 2.7.x _and_ 3.x.  If there's a documented, public method that you're depending on, then we'll maintain compatibility.  If there's not, and you're digging into the internal behaviors, then all bets are off.

I mention this because I'd hate to see another broken integration when we release a future version of Puppet.

-Jeff

[R.I.Pienaar]

----- Original Message -----
> From: "Jeff McCune" <je...@puppetlabs.com>
> To: puppe...@googlegroups.com
> Sent: Monday, October 22, 2012 11:12:19 PM
> Subject: Re: [Puppet-dev] runmode
>

> On Mon, Oct 22, 2012 at 2:55 PM, R.I.Pienaar < r...@devco.net > wrote:
>
>
>
>
> for 2.7 it seems this is the magic:
>
> require 'puppet'
> $puppet_application_mode = Puppet::Util::RunMode[:agent]
> Puppet.settings.use :main, :agent
> Puppet.parse_config
>
> have to say I am surprised about the global variable there, surely
> this is
> not how it works?
>
> Sadly, yes, that's how it works. I'm guessing it was easier to
> implement this as a global variable since we don't really have a
> service locator or what have you to cleanly get a handle on the
> runmode instance.
>
> Also, please note that unless there's a documented, public method, if
> you implement these behaviors yourself and we change the internal
> behaviors in a bugfix or minor release, we make no guarantees about
> preserving compatibility with the external world.

yes, what I am trying to do is write a wrapper that provides a unified
single API around both 2.7 and 3 behaviours so that tools like MCollective
can have some hope of managing Puppet in the face of ever changing behaviour

>
> The best way forward on this is to submit a pull request that defines
> the public API method you're looking for in Puppet 2.7.x _and_ 3.x.
> If there's a documented, public method that you're depending on,
> then we'll maintain compatibility. If there's not, and you're
> digging into the internal behaviors, then all bets are off.
>
> I mention this because I'd hate to see another broken integration
> when we release a future version of Puppet.

yeah I am writing a versioned API that I can capture the changes in, we
should at least be good for the duration of 3.0.x though and hopefully
by then Puppet will have stabilised this API but until the team consider
that a priority unfortunately even getting our own tools to use puppet
is going to be hacktacular.

[R.I.Pienaar]

no seems I am still missing something:

$puppet_application_mode = Puppet::Util::RunMode[:agent]

$puppet_application_name = :agent

Puppet.settings.use :main, :agent
Puppet.parse_config

p Puppet[:classfile]
p Puppet[:pidfile]

with classfile set in [agent] it's reading the right classfile, however
with this code :pidfile would be /var/run/puppet/apply.pid rather than
/var/run/puppet/agent.pid. pidfile is not specifically set in the config
so it should come from defaults

[R.I.Pienaar]

----- Original Message -----
>
> no seems I am still missing something:
>
> $puppet_application_mode = Puppet::Util::RunMode[:agent]
> $puppet_application_name = :agent
>
> Puppet.settings.use :main, :agent
> Puppet.parse_config
>
> p Puppet[:classfile]
> p Puppet[:pidfile]
>
> with classfile set in [agent] it's reading the right classfile,
> however with this code :pidfile would be /var/run/puppet/apply.pid rather
> than /var/run/puppet/agent.pid. pidfile is not specifically set in the
> config so it should come from defaults

following up here it seems the order of requires matter, if you just
require puppet before setting $puppet_application_name it assumes apply

so:

$puppet_application_name = :agent

require 'puppet'
$puppet_application_mode = Puppet::Util::RunMode[:agent]

Puppet.settings.use :main, :agent
Puppet.parse_config

works, but if I set the application name after the require puppet its
stuck in apply.

As it turns out this is almost impossible to control in my use case, is there
a way to properly reparse the settings if $puppet_application_name changes?

[Andy Parker]

On Tue, Oct 23, 2012 at 3:04 PM, R.I.Pienaar <r...@devco.net> wrote:
>
> $puppet_application_name = :agent
> require 'puppet'
> $puppet_application_mode = Puppet::Util::RunMode[:agent]
>
> Puppet.settings.use :main, :agent
> Puppet.parse_config
>
> works, but if I set the application name after the require puppet its
> stuck in apply.
>

Oh god, this makes my eyes bleed. Thankfully this shouldn't be
changing any more in 2.7.

On issues in 3.x, I think that the interface that you've found for
loading settings will most likely get turned into the public API for
doing that. If we end up breaking any of that, the we'll need to work
together to figure out how to fix it. Beyond that the interface that
you came up with for querying the puppet status seems like a good
direction. At some point we will need to get an API for doing all of
that stuff inside puppet itself and we should work together on that.
If we cause anything to break your support for the puppet 3 code,
though, call it out and we'll work on solving any issues.

> As it turns out this is almost impossible to control in my use case, is there
> a way to properly reparse the settings if $puppet_application_name changes?
>

There is #reuse and #reparse, but I don't know if those will do what
you want. I can't even see where $puppet_application_name is used,
everything just seems to set it.

[R.I.Pienaar]

----- Original Message -----
> From: "Andy Parker" <an...@puppetlabs.com>
> To: puppe...@googlegroups.com
> Sent: Wednesday, October 24, 2012 5:53:42 PM
> Subject: Re: [Puppet-dev] runmode
>

I'll try those and feedback thanks

The $puppet_application_name is only read by Puppet#application_name and
defaults to 'apply' if unset, used in defaults.rb then.

[R.I.Pienaar]

nah, no permutations of those let it properly re-parse its config with a
new name :(