[PATCH/puppet 1/1] (#4974) Allow tags=main to apply all resources.

[Nigel Kersten]

From: Nigel Kersten <ni...@explanatorygap.net>

Sent on behalf of Tim Nicholas.
Make --tags main apply all resources.

Signed-off-by: Nigel Kersten <ni...@puppetlabs.com>
---
lib/puppet/util/tagging.rb | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/lib/puppet/util/tagging.rb b/lib/puppet/util/tagging.rb
index 6323ee0..a4556d6 100644
--- a/lib/puppet/util/tagging.rb
+++ b/lib/puppet/util/tagging.rb
@@ -21,6 +21,8 @@ module Puppet::Util::Tagging

# Are we tagged with the provided tag?
def tagged?(*tags)
+ # If one of the tags passed is a 'main' then it will always match
+ if tags.include?("main") then return true end
not ( self.tags & tags.flatten.collect { |t| t.to_s } ).empty?
end

--
1.7.2.3

[Nigel Kersten]

I'm not entirely convinced this is the best way to achieve this, so
consider this a discussion starting point.

--tags main should probably just be the main Stage, do we want to make
people explicitly list their stages, or do we want an "--alltags"
option of some kind?

[Hunter Haugen]

Random idea. If stages themselves worked via tags instead of adding
something to the graph (and creating many-to-many dependencies), would
that be more functional?

If you could use the tag() function to apply a tag to the class as
normal, then define if that tag comes before or after the 'main' tag
or any other arbitrary tag, then we could have cross-stage
dependencies (currently broken with stages) and use a syntax that's
already built in. Perhaps this would also circumvent the performance
problems associated with large stages.

This would also solve --tags main

-Hunter

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

[Luke Kanies]

I agree, this isn't really the best way to do it, given stages.

I think some kind of metatag like 'all' (which the tagmail report processor uses) or supporting '*' or something similar is the better move.

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

--
I can win an argument on any topic, against any opponent. People know
this, and steer clear of me at parties. Often, as a sign of their
great respect, they don't even invite me. -- Dave Barry
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199

[Luke Kanies]

I couldn't find a clean way of having them work via tags, and I think this model actually works better because it exposes that ordering directly in the graph, which I think is far easier to support in the long term. E.g., finding a cycle would be very hard if we were using tags, but is straightforward the way we're doing it now.

--
I hate to advocate drugs, alcohol, violence, or insanity to anyone,
but they've always worked for me. -- Hunter S. Thompson

[markus]

It's possible that I'm not understanding your suggestion, but:

> Random idea. If stages themselves worked via tags instead of adding
> something to the graph (and creating many-to-many dependencies), would
> that be more functional?

It would eliminate the main point of stages though; the whole point of
stages is to constrain the shape of the graph, which tags don't.

> If you could use the tag() function to apply a tag to the class as
> normal, then define if that tag comes before or after the 'main' tag
> or any other arbitrary tag, then we could have cross-stage
> dependencies (currently broken with stages) and use a syntax that's
> already built in.

Except there's presently no concept of ordering with regards to tags at
all, and that would be a pretty big change.

Also, what do you mean about cross-stage dependencies being broken?

> Perhaps this would also circumvent the performance
> problems associated with large stages.

The performance issues are independent of this.

-- Markus

[Hunter Haugen]

> Also, what do you mean about cross-stage dependencies being broken?

Sorry, misinterpreted something Nan said. It works like it should (ie,
creating circular dependencies when a resource in a later stage
requires a resource in an earlier stage).

-Hunter

[Matt Robinson]

I updated this ticket as needs design decision. I'm not getting a
clear consensus from the list discussion on how we'd like to implement
this.