The only situation I can think of is the following:
== file: site.pp ==
class { 'awesome':
do => 'All the awesome things to all systems'
}
... ENC or node defs take over here ...
Trevor
On Wed, Sep 11, 2013 at 4:14 PM, Luke Kanies <[email protected]> wrote:
> On Sep 11, 2013, at 12:32 PM, John Bollinger <[email protected]>
> wrote:
>
>
>
> On Wednesday, September 11, 2013 11:58:55 AM UTC-5, Trevor Vaughan wrote:
>>
>> This definitely works with the best practice of not having globally
>> floating classes.
>>
>>
>
> Please help me come up to speed here: why is it a best practice to avoid
> globally floating classes? If it truly doesn't matter when a given class
> is applied relative to any of the others, then how is it advantageous to
> declare ordering relationships for it? Does that not needlessly slow both
> master and agent, and make both more resource-hungry?
>
>
> Let's turn it around: What are the instances in which you would end up
> floating classes?
>
> E.g., what are the cases where you'd want a class to exist but have no
> concerns about its relationship to other classes?
>
> The only cases I can come up with are those that are specified at the node
> level, either in the ENC or in the Node.
>
> Every other class, almost by definition, must be in service to one of
> those top level classes, right?
>
> Are you OK with yelling at people that do though (for whatever reason)?
>>
>>
>
> Even if the assumption is that few classes are truly without ordering
> requirements, users should not be bullied / henpecked into declaring
> unneeded relationships. If it is desirable to warn users that they may
> have omitted needed relationships, then it is desirable to also afford them
> the opportunity to assert that they know better. At the coarsest level,
> that would mean a *continuing* ability to disable all such warnings, but
> ideal would be to support disabling the warnings on a class-by-class basis.
>
>
> Hrm, I don't think of it as henpecking, I think of it as encouraging but
> not requiring the right behavior, which I think we should do more of
> overall. I'm certainly not attached to the mechanism, or even whether it's
> a permanent thing or not; like my email said, it was just an idea, not
> something I'm trying to force through.
>
> As to how one would disable those behaviors, I guess we'd have to
> introduce another function or a pragma or something. That might not be
> worth it.
>
> --
> Luke Kanies | http://about.me/lak | http://puppetlabs.com/ |
> +1-615-594-8199
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/puppet-dev.
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
[email protected]
-- This account not approved for unencrypted proprietary information --
--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/puppet-dev.
For more options, visit https://groups.google.com/groups/opt_out.
