The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using https://tickets.puppetlabs.com. See the following page for information on filing tickets with JIRA:

Feature #12074

Add a top level "apply"-like and "agent"-like application, to capture user intent.

Added by Anonymous over 4 years ago. Updated about 3 years ago.

Status:Needs DecisionStart date:01/21/2012
Priority:NormalDue date:
Assignee:J.D. Welch% Done:

0%

Category:executables
Target version:3.x
Affected Puppet version: Branch:
Keywords:ux

We've Moved!

Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com


Description

The Puppet agent application supports a bunch of features, like writing classes.txt, reporting, and other bits and pieces that are about having a relationship with a master and delegating all the responsibility for catalog compilation to the master. Generally speaking, it acts as though it is the central configuration management tool for the machine, and everything that it does reflects the “machine” state.

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.

There is a third class of actions that users take, where they don’t want to delegate selection of the catalog stuff to the master – retaining that locally – but they do want to behave as if this is the desired “machine” state.

We have plenty of things to turn on individual features in the apply application to, eg, send reports centrally, and so forth. These end up adding substantial complexity, because we try to infer the intention from these individual flags – rather than directly capturing the intent.

Adding a third option, which behaves like apply in terms of where manifests come from, but like agent in terms of acting like the machine-wide desired state, resolves this bind. Now we capture exactly the user intention, and we don’t have to guess what they wanted.

I guess this would be named something like puppet stand-alone, or puppet local, or puppet solo, or something like that.


Related issues

Related to Puppet - Bug #7917: Puppet apply runmode should write classes.txt file Needs Decision
Related to Puppet - Feature #17095: Improve puppet's command line interaction Investigating

History

#1 Updated by Anonymous over 4 years ago

  • Status changed from Unreviewed to Needs Decision
  • Assignee set to Anonymous

Randall, this seems like a good decision from a user perspective, but I wanted to get your feedback before pushing further with this.

Are you generally happy with the strategy? Is there some other way that you would like to see this modelled?

Anyone else with strong opinions is welcome to chime in.

#2 Updated by Anonymous over 4 years ago

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.

#3 Updated by Nigel Kersten over 4 years ago

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?

#4 Updated by R.I. Pienaar over 4 years ago

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.

#5 Updated by Anonymous over 4 years ago

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.

#6 Updated by Anonymous over 4 years ago

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?

#7 Updated by R.I. Pienaar over 4 years ago

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

#8 Updated by Anonymous over 4 years ago

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.)

#9 Updated by R.I. Pienaar over 4 years ago

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

#10 Updated by Anonymous over 4 years ago

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…

#11 Updated by R.I. Pienaar over 4 years ago

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

#12 Updated by Anonymous over 3 years ago

  • Assignee changed from Anonymous to J.D. Welch

#13 Updated by J.D. Welch over 3 years ago

  • Keywords set to backlog

#14 Updated by eric sorenson over 3 years ago

  • Keywords changed from backlog to ux

#15 Updated by Jon Topper over 3 years ago

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.

#16 Updated by Jo Rhett about 3 years ago

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

Also available in: Atom PDF