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:

Bug #7917

Puppet apply runmode should write classes.txt file

Added by Anonymous almost 5 years ago. Updated over 2 years ago.

Status:Needs DecisionStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:settings
Target version:-
Affected Puppet version:2.7.0 Branch:https://github.com/puppetlabs/puppet/pull/35
Keywords:apply classes.txt classes mcollective agent puppet.conf conf main

We've Moved!

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

This ticket is now tracked at: https://tickets.puppetlabs.com/browse/PUP-1042


Description

Overview

The classes.txt file is only written when running Puppet in the agent run mode.

It would be useful for integration with MCollective filtering if this file were also written when running Puppet the stand alone apply run mode.

# The file in which puppet agent stores a list of the classes
# associated with the retrieved configuration.  Can be loaded in
# the separate `puppet` executable using the `--loadclasses`
# option.
# The default value is '$statedir/classes.txt'.
classfile = /var/lib/puppet/state/classes.txt

This would be useful with MCollective’s configuration setting of:

classesfile = /var/lib/puppet/state/classes.txt

Impact Data

At least one community member has requested this feature. (See comments below).

This ticket is important for mcollective integration with “puppet apply.”


Related issues

Related to Puppet - Feature #12074: Add a top level "apply"-like and "agent"-like application... Needs Decision 01/21/2012
Related to Puppet - Feature #2935: Settings should use 'agent' and 'server' in addition to e... Closed 12/15/2009

History

#1 Updated by Edward Simmonds over 4 years ago

We would definitely like this feature added to “puppet apply”.

We use a decentralized Puppet configuration and use “puppet apply” exclusively. The puppet agent just won’t scale for the number of nodes we manage. We are rolling out mcollective, but unfortunately its usefulness will be lessened by the missing “classes.txt” on all of our nodes.

#2 Updated by Nan Liu over 4 years ago

  • Category set to settings
  • Status changed from Unreviewed to In Topic Branch Pending Review

Needs a decision first whether this should be accepted, but this seems fairly straightforward:

https://github.com/puppetlabs/puppet/pull/35

#3 Updated by Anonymous over 4 years ago

  • Status changed from In Topic Branch Pending Review to Code Insufficient

Puppet apply can be used for any number of things, including one-shot modifications to a system. Dropping all the data from regular runs just because someone ran something through it seems risky: your database server would stop being a database server until the next full run, which is probably not what you want.

I am pretty sure this is an unresolvable problem, because we have a single piece of data (classes.txt) that is trying to represent something much more dynamic, the set of applicable classes (or, perhaps, successfully applied classes) of the machine at a point in time.

Making this optional, or writing to a separate file, would be much more acceptable.

#4 Updated by Nan Liu over 4 years ago

  • Status changed from Code Insufficient to Needs Decision

You can configure this for apply/agent, perhaps we need a dedicated [apply] section:

[main]
  classfile = $vardir/state/apply_classes.txt

[agent]
  classfile = $vardir/state/classes.txt

I agree this should be clearly spelled out in release documentation. Should I submit a patch with a more sensible default for puppet.conf?

#5 Updated by Anonymous over 4 years ago

(Copied from github comments)

Daniel,

I’m in agreement with Nan.

We do make claims that puppet apply is a “first class citizen” and community members like Jordan Sissel heavily rely on puppet apply being feature complete with puppet agent.

Furthermore, puppet apply is more suitable for situations like Vagrant where a full master is not avaialable or necessary.

Finally, as we integrate more with MCollective, the classes.txt file becomes ever more important for filtering.

For these reasons I think we should still write the file and we should write it to the same file the agent writes to by default.

If the end user desires, we support writing to multiple files as Nan illustrated above.

I’ll re-open this once. If you still disagree, please feel free to close the pull request and I won’t re-open it.

-Jeff

#6 Updated by Anonymous over 4 years ago

  • Assignee set to Nigel Kersten
  • Affected Puppet version set to 2.7.0
  • Keywords set to apply classes.txt classes mcollective agent puppet.conf conf main

#7 Updated by Anonymous over 4 years ago

  • Branch set to https://github.com/puppetlabs/puppet/pull/35

#8 Updated by Anonymous over 4 years ago

  • Description updated (diff)

#9 Updated by Anonymous over 4 years ago

Jeff McCune wrote:

(Copied from github comments)

Daniel,

I’m in agreement with Nan.

We do make claims that puppet apply is a “first class citizen” and community members like Jordan Sissel heavily rely on puppet apply being feature complete with puppet agent.

Furthermore, puppet apply is more suitable for situations like Vagrant where a full master is not avaialable or necessary.

Finally, as we integrate more with MCollective, the classes.txt file becomes ever more important for filtering.

For these reasons I think we should still write the file and we should write it to the same file the agent writes to by default.

If the end user desires, we support writing to multiple files as Nan illustrated above.

I’ll re-open this once. If you still disagree, please feel free to close the pull request and I won’t re-open it.

-Jeff

I think it’s worth noting; In my experience it’s a far more common where end users run exclusively with puppet apply than it is end users mix puppet agent and puppet apply on the same node. Therefore, I think the more common case “wins” over the concern that puppet apply will “fight” with puppet agent.

Does this make sense Daniel?

-Jeff

#10 Updated by Edward Simmonds over 4 years ago

As the guy requesting this, I’ll just add one more comment. We do full puppet runs with ‘puppet apply’, never partials or subsets of our configs.

Thanks much for all your efforts!

#11 Updated by Nigel Kersten over 4 years ago

  • Status changed from Needs Decision to Accepted
  • Assignee deleted (Nigel Kersten)

Agreed on all counts.

Added Matt as a watcher, as he’s looking at implementing something similar for listing managed resources on nodes, and we should make sure that can work with apply as well as agent too.

#12 Updated by Anonymous over 4 years ago

On Fri, Aug 12, 2011 at 12:26 PM, Daniel Pittman daniel@puppetlabs.com wrote:

So, I think those are compelling use cases, and we should enable parity, but not by default.  Would a compromise that added a configuration option for apply mode, defaulting to classes_from_apply.txt or so, and allowing you to manually configure it to the default location satisfy your needs?

I’m OK with that compromise. MCollective also already allows you to configure the path to classes.txt, so you could point it to the “default” apply file if you wish.

Edward, Nan, what do you think?

-Jeff

#13 Updated by Edward Simmonds over 4 years ago

Anything that allows us to use mcollective would be great!

Thanks very much for your help with this.

Best,

Ed

#14 Updated by James Turnbull over 4 years ago

  • Status changed from Accepted to Needs Decision
  • Assignee set to Nan Liu

Can Daniel or Nan throw their ten cents into an email to puppet-dev given the lack of consensus on the pull request? Thanks.

#15 Updated by Nan Liu over 4 years ago

  • Assignee deleted (Nan Liu)

#16 Updated by James Turnbull over 4 years ago

Thanks Nan!

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

Keen to see a solution found for this. I am not sure if its viable but could the apply application just by default not write it as now but only write the classes file when specifically given a path in the config file or command line?

Failing that the extra command line option Deepak propose would be fine, rather have a solution that none at all. At the moment I had to write a custom application to do this.

#18 Updated by Anonymous over 4 years ago

  • Assignee set to Anonymous

This really reflects a deeper loss of context in our system; I have tried to capture my thinking about that in #12074. If folks with opinions here could take a look at that it would be great.

The summary is: add a new application that is like apply in terms of manifests, but does things like write classes.txt. That way we capture user intent around “apply” or “apply-like-an-agent”, and can make the right decision about things like this low level feature.

#19 Updated by Anonymous almost 3 years ago

  • Assignee deleted (Anonymous)

#20 Updated by Erik Dalén over 2 years ago

Redmine Issue #7917 has been migrated to JIRA:

https://tickets.puppetlabs.com/browse/PUP-1042

Also available in: Atom PDF