Puppet

I should probably note that the long term thinking here would be that this would render much of the duplicate code in agent redundant, given that this would be equivalent of puppet enhanced-apply --catalog $catalog_from_the_master in behaviour. So, the implementation should reflect that change.

I’m not quite convinced that this rests on true premises Daniel

The Puppet apply application supports local scripts, doesn’t write classes.txt, doesn’t report by default, and generally behaves as if the content was intended to be a one-shot > little script that runs with no lasting effects. Generally speaking, it acts as though it is not the central configuration management tool, and nothing that it does reflects the desired “machine” state.

How does this jive with someone who has a full set of modules locally, and is essentially applying the site.pp, but locally?

I don’t believe it’s a valid conclusion that “nothing that it does reflects the desired machine state”.

Why is it problematic for someone to pick and choose the bits of central functionality they want with puppet apply?

• They can use an ENC
• They can use centralized reporting
• They can use storeconfigs

I agree we have inconsistencies with some features like classes.txt, but does that seriously drive us towards a new application?

Think of the other way around. Are we enforcing reports/storeconfigs/ENC for agent runs?

I have just such a need, to make a first class citizen of masterless operation we need among others:

• someway to schedule it, not cron, but something like a apply daemon that works local only
• classes.txt, reports, last_run_summary etc
• possibility to submit reports remotely
• pluginsync perhaps

I’ve had to essentially hack apply.rb to get some of this features, would be nice to get a better masterless mode that could still operate for example with dashboard to allow ENC and reporting features.

Nigel Kersten wrote:

I’m not quite convinced that this rests on true premises Daniel

The Puppet apply application supports local scripts, doesn’t write classes.txt, doesn’t report by default, and generally behaves as if the content was intended to be a one-shot little script that runs with no lasting effects. Generally speaking, it acts as though it is not the central configuration management tool, and nothing that it does reflects the desired “machine” state.

How does this jive with someone who has a full set of modules locally, and is essentially applying the site.pp, but locally?

Someone who is using puppet apply as if it is actually puppet enhanced-apply? That distinction is absolutely, exactly what this ticket is all about.

I don’t believe it’s a valid conclusion that “nothing that it does reflects the desired machine state”.

Absolutely correct. Which is why I am proposing that we capture that intent, because some but not all users expect apply to behave like you describe, and some but not all users expect that it will not.

Why is it problematic for someone to pick and choose the bits of central functionality they want with puppet apply?

For the user? Because once you have a switch for all the…

• They can use an ENC
• They can use centralized reporting
• They can use storeconfigs

• they write classes.txt

…different options, you have a huge amount of complexity in the system, and we are asking the user to express that they want “mostly like the agent” as puppet apply --use_an_enc --use_central_reports --use_storeconfigs --write_classes_txt ....

I agree we have inconsistencies with some features like classes.txt, but does that seriously drive us towards a new application?

My working theory, based on observation, is that there are three classes of behaviour: * puppet apply for a one-shot script * puppet apply for entire system “configuration management” without a central catalog authority * puppet agent for entire system “configuration management” with a central catalog authority

While we name two of those the same, we have a constant conflict between what the user wants and what they don’t.

Ultimately, we could have the same discussion about apply vs agent – shouldn’t we have a flag to agent that tells it to compile locally, rather than remotely? You can, after all, turn off all the other features that relate to a central system, one by one, along with the “also, use the local compiler” option.

Like apply, the proposed command would be a bundle of default behaviour that would, hopefully, better match the user expectations.

Think of the other way around. Are we enforcing reports/storeconfigs/ENC for agent runs?

No, although I would certainly entertain the notion that we should.

Ultimately, I think we have too many ways to do things, and building another switch, then another, then another to satisfy the various demands is adding more complexity for users without bringing them the benefits that are promised.

R.I. Pienaar wrote:

I have just such a need, to make a first class citizen of masterless operation we need among others:

nod Many people want to do this; we have several at the company alone who have done. It is a common enough pattern that there is plenty of documentation out there about just how to achieve this.

• someway to schedule it, not cron, but something like a apply daemon that works local only

Why not cron?

Daniel Pittman wrote:

Why not cron?

the puppet agent daemon has quite a few modes, enable, disable, run once in the background then exit, splaying etc. All of these are useful in standalone mode too. Would be a PITA to implement as a cron job

R.I. Pienaar wrote:

Daniel Pittman wrote:

Why not cron?

the puppet agent daemon has quite a few modes, enable, disable, run once in the background then exit, splaying etc. All of these are useful in standalone mode too. Would be a PITA to implement as a cron job

So, if we gave you a drop-in script for cron that implemented an enable/disable toggle, and splay, would that work for you? (Run once in the background is trivially implemented with either at(1) or batch(1), so we don’t even need to do anything beyond the above script there.)

Daniel Pittman wrote:

So, if we gave you a drop-in script for cron that implemented an enable/disable toggle, and splay, would that work for you? (Run once in the background is trivially implemented with either at(1) or batch(1), so we don’t even need to do anything beyond the above script there.)

actually this last mode is quite important – since thats exactly what the current mcollective agent use to kick off runs, could of course use various ways to achieve that but would be nice to just have it in one place close by

R.I. Pienaar wrote:

Daniel Pittman wrote:

So, if we gave you a drop-in script for cron that implemented an enable/disable toggle, and splay, would that work for you? (Run once in the background is trivially implemented with either at(1) or batch(1), so we don’t even need to do anything beyond the above script there.)

actually this last mode is quite important – since thats exactly what the current mcollective agent use to kick off runs, could of course use various ways to achieve that but would be nice to just have it in one place close by

Does at now fail in any meaningful way that the other option would? It will run the process in the background, detached from the parent, and without blocking it. I assume that you can’t be waiting for a child exit status or anything, given that forking inside the process will hide that from you…

Daniel Pittman wrote:

Does at now fail in any meaningful way that the other option would? It will run the process in the background, detached from the parent, and without blocking it. I assume that you can’t be waiting for a child exit status or anything, given that forking inside the process will hide that from you…

yeah yeah :) so we’re removing —onetime from the agent? :P

I’d like to +1 on this – I’ve just come across the “puppet apply doesn’t write classes.txt” feature, which means my Vagrant-based environments can’t usefully be used to tinker with the things I’m trying to work on with MCollective. I’d like a standard way to forcefully say “run masterless, do all the things an agent-based run would” – I appreciate the counterargument that “puppet apply” can be used in a number of use cases, but the option needs to be there.

Another +1 on this. It entirely defeats the well-documented filter of “—with-class” for mcollective.