Feature #6517

should not display internal puppet resources

Added by Dan Bode about 1 year ago. Updated 3 months ago.

Status:Needs Decision Start date:02/28/2011
Priority:Normal Due date:
Assignee:Randall Hansen % Done:

0%
Category:-
Target version:-
Keywords: Affected URL:
Branch: Affected Dashboard version:
Votes: 0

Description

The Dashboard report view always shows the following resources:

* Schedule[never]
* Filebucket[puppet]
* Schedule[hourly]
* Schedule[daily]
* Schedule[puppet]
* Schedule[monthly]
* Schedule[weekly]

these are internal Puppet resources and do not provide any value by being displayed.

History

#1
Updated by James Turnbull about 1 year ago

  • Status changed from Unreviewed to Needs Decision

#2
Updated by James Turnbull about 1 year ago

  • Assignee set to Nigel Kersten

#3
Updated by Nigel Kersten about 1 year ago

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

#4
Updated by Daniel Pittman about 1 year ago

These are only irrelevant if nothing uses them; we shouldn’t hide them unconditionally. Assuming they come from the underlying catalog rather than from inspection of available classes, perhaps we should solve this by running a filtering pass before delivery to the client that removes orphan schedule resources, along with any other “lint”?

#5
Updated by Nigel Kersten 8 months ago

  • Status changed from Accepted to Needs More Information
  • Assignee set to Daniel Pittman

Is it unrealistic to ask for them not to be in the catalog itself unless they’re actually used Daniel?

#6
Updated by Daniel Pittman 5 months ago

  • Status changed from Needs More Information to Needs Decision
  • Assignee changed from Daniel Pittman to Randall Hansen

Nigel Kersten wrote:

Is it unrealistic to ask for them not to be in the catalog itself unless they’re actually used Daniel?

Not in the slightest, but that isn’t going to happen in the immediate term. The biggest challenge that gives us is that they are part of our API promise to our users, at the level of the DSL, even though they probably shouldn’t be. Given that, we would have to go down one of two paths:

  1. Deprecate them, and then eliminate them entirely at a later date. Ideally, without breaking every manifest, and without whining at every catalog compile.
  2. Eliminate them from the catalog after compilation, if they have no dependencies.

The second has some challenges: do we really want to introduce a “kill list” for resources that can be eliminated if they stand alone? We clearly can’t just eliminate detached resources, although we could theoretically mark some types as being “noop”, in that they don’t do anything unless they are triggered, and those can be removed.

Would people expect that, however? Would an exec { "foo": refreshonly => true } resource be eliminated? Should it?

Randall, this is very much in the space of language and user experience expectations. Can I pass this to you for a final decision on what we should do?

#7
Updated by Randall Hansen 4 months ago

Daniel, I think option (2) sucks. As you point out it will be hard for users to predict, thus magical. I don’t know the full consequences of deprecating them, however.

#8
Updated by Daniel Pittman 4 months ago

Randall Hansen wrote:

Daniel, I think option (2) sucks. As you point out it will be hard for users to predict, thus magical. I don’t know the full consequences of deprecating them, however.

Right now, a user can specify that a resource is only checked and applied once an hour, day, week, etc, without having to do anything. They just add schedule => daily to the resource, as per http://docs.puppetlabs.com/references/stable/metaparameter.html#schedule

That is because we magically generate, and inject, those schedule resources into the catalog.

If we deprecate them the user can’t do that without writing their own resource with that name, when it finally gets removed, and they have a brief (or, long, depending on how long we keep them about) headache where they either name their resource something different, or they get deprecation warnings for, eg, the life of Telly.

In practical terms I doubt much happens, because the schedule feature is relatively little used, and we almost never see any catalog in the wild that uses these – but I bet we have, like, five or ten percent of catalogs that “just work” that use one or another.

#9
Updated by Nigel Kersten 3 months ago

Daniel Pittman wrote:

In practical terms I doubt much happens, because the schedule feature is relatively little used, and we almost never see any catalog in the wild that uses these – but I bet we have, like, five or ten percent of catalogs that “just work” that use one or another.

I thought this, but it’s an incredibly valuable feature for users who use it, and there were more than I expected last time I polled the user list.

People use it heavily for change management windows.

What about this proposal?

We inject the resources in as we do now. At the end, we strip them out if nothing is using them.

Also available in: Atom PDF