Grr:
Also 'include' *would* accept hashes and include the specified module. In
the case that two are present on the system, you would need to deconflict
your include code or somehow be able to set a default for your system
(better due to legacy code). Perhaps, a 'default' entry in the Modulefile
or somesuch.
On Wed, Jun 18, 2014 at 6:56 AM, Trevor Vaughan <tvaug...@onyxpoint.com>
wrote:
> Sorry to reply to myself but I just thought of the perfect example of why
> I want this.
>
> puppetlabs-firewall
>
> So, pretty much all modules need to call out to a firewall if one is
> enabled for obvious reasons.
>
> However, you may have very real scenarios where you don't want
> puppetlabs-firewall managing your rules.
>
> So, the following may apply for any given module that could use
> puppetlabs-firewall:
>
> a) Have a variable that toggles firewall support off => Bad, nobody wants
> to declare variables that they don't have to, particularly when missing one
> means that you're going to end up with an unusable system
>
> b) Have a variable that toggles firewall support on => Better, because you
> can't accidentally modify the system, but you probably want this 99% of the
> time so that means you have to declare a lot of variables or again, have an
> unusable system.
>
> c) Have a global that toggles firewall support per node => Even Better
> because you can set something one time and call it done. But, you still
> have to declare a variable when you really shouldn't have to (and booo
> globals).
>
> d) Use if defined => Aw, parse order dependent. So, declare 'include
> firewall' first! But that's not really very intuitive.
>
> e) Use the new proposed magic => Woo, it "just works" if *anything* in the
> catalog includes 'firewall'. This way, if I don't want it, I don't get it
> in an intuitive fashion.
>
> This also dovetails into my second scenario in the previous e-mail which
> would mean that I could do if $::module_firewall[:provider] == 'puppetlabs'
> and $::module_firewall[:version] >= 1.2 { include firewall{ :provider =>
> 'puppetlabs', :version => '1.2' } which could happily include the *correct*
> firewall module for my custom module.
>
> Yeah, I expanded the example some when thinking about it. It would be nice
> to be able to include the *correct* module for your code. To do this:
>
> $::module_<foo> would be a hash of items that describes the Modulefile and
> $::module_foo without a key would just tell you if it is present in your
> catalog at all.
>
> Also 'include' would not accept hashes and include the specified module.
> In the case that two are present on the system, you would need to
> deconflict your include code or somehow be able to set a default for your
> system (better due to legacy code). Perhaps, a 'default' entry in the
> Modulefile or somesuch.
>
> Thanks,
>
> Trevor
>
>
> On Wed, Jun 18, 2014 at 5:22 AM, Trevor Vaughan <tvaug...@onyxpoint.com>
> wrote:
>
>> Hi Felix,
>>
>> Yes, I'm very aware that the current recommendations are to very cleanly
>> model your system to be able to non-ambiguously define your catalog.
>>
>> However, there have always been arguments that the Puppet language should
>> be declarative throughout which makes for more maintainable and intuitive
>> manifests overall.
>>
>> If you go look for posts surrounding this subject, I'd say that the
>> consensus is because reflection just doesn't work, not because it shouldn't
>> be there.
>>
>> Frankly, it can solve a LOT of problems for you and make the system
>> designer's life a lot easier.
>>
>> Scenario 1: A requires B if C but not otherwise.
>>
>> If I don't have reflection in this case, then I have to have
>> documentation that says, hey, if you put A and C together on a system,
>> remember to add B! This is prone to error and is something that the code
>> should just "take care of" for me. I'm aware that you could use a
>> role/profile model to take care of this but you're just making people write
>> extra code for no really good reason except that the language doesn't
>> actually address this issue. (I'll rant about the irritation of figuring
>> out what code is doing in a role/profile system later).
>>
>> Scenario 2: A requires B if module B is present but do something else
>> otherwise.
>>
>> This one is more about system introspection I suppose but we have all of
>> these lovely Module Forge description files and we can't use them in the
>> language! I would love to be able to do the following:
>>
>> if $::module_mysql <= '1.2' { include 'mysql' } else { service { 'mysql':
>> ensure => running, enable => true } }
>>
>> You can then also use $::module_mysql to set up automatic Hiera
>> hierarchies that run from version down to a default (hieradata/mysql/1.0,
>> hieradata/mysql/0.9, hieradata/mysql/default) and life is magic and
>> wonderful when modules on the forge change.
>>
>> Scenario 1 is obviously what we're referring to in this thread and I
>> think, with the way most cloud component architectures seem to be designed,
>> the burden is being placed on the system user as opposed to the system
>> designer in too many cases. And, frankly, some times you just need to get
>> something working and you hit a point where you realize that you'd have to
>> redesign the system to avoid using reflection and you just don't have time
>> for that or it is going to add a LOT of unnecessary code.
>>
>> Hope all this makes sense this early in the morning!
>>
>> Thanks,
>>
>> Trevor
>>
>>
>> On Wed, Jun 18, 2014 at 4:04 AM, Felix Frank <
>> felix.fr...@alumni.tu-berlin.de> wrote:
>>
>>> Hi,
>>>
>>> putting on my manifest design philosopher's hat :-)
>>>
>>> On 06/18/2014 04:11 AM, Trevor Vaughan wrote:
>>> > It does get hairy when you mix the callbacks with the reverse
>>> > dependencies. I can see having to iterate over the stack (mesh?) and
>>> > check for loops and correctness while doing so. It could certainly turn
>>> > into quite the recursive memory hog if not done properly.
>>>
>>> Yes, as Henrik mentioned, you'd basically need an advanced resolution
>>> mechanism to it right. I predict that there may well be cases that the
>>> system will not just get right.
>>>
>>> > However, I really do think that this is needed in the language as it
>>> > seems to be a place where people frequently stumble when putting
>>> > together what should be a straightforward thought process.
>>>
>>> While those are cool ideas (and I'm still rooting for a lazy
>>> evaluator...anyone? no?) I'd like to contend the proposition that actual
>>> support for this style of solving problems should be supported (and by
>>> extension, recommended).
>>>
>>> We are currently trying to teach users that in order to model a system,
>>> they typically need to find a way to non-ambiguously define what does
>>> and what does not need to be part of the catalog. This may often boil
>>> down to introducing a flag value in Hiera or somesuch.
>>>
>>> In other words, there seems to be a consensus that "reflection" (for
>>> lack of a better term) in manifests should be avoided in favor of a
>>> common data source in which to base your queries.
>>>
>>> And yes, I do realize that there are edge cases where this is quite
>>> painful in comparison to `if defined(Class[x])`, but I guess this is us
>>> discussing if those are worth the burden of supporting the scheme.
>>>
>>> Final aside (although I believe that you are aware of this, still got
>>> the urge to point this out): 'Don't reverse these two' will work on the
>>> node level, but as soon as you're two or three levels of `include` deep,
>>> it's wishful thinking at best. One should never rely on evaluation
>>> order. This is precisely why we need defined() gone.
>>>
>>> ...rereading, the whole message has a distinct Get Off My Lawn feel to
>>> it - sorry. Guess I'm that dude by now :-)
>>>
>>> Cheers,
>>> Felix
>>>
>>> --
>>> 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 puppet-dev+unsubscr...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-dev/53A14820.3080907%40alumni.tu-berlin.de
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Trevor Vaughan
>> Vice President, Onyx Point, Inc
>> (410) 541-6699
>> tvaug...@onyxpoint.com
>>
>> -- This account not approved for unencrypted proprietary information --
>>
>
>
>
> --
> Trevor Vaughan
> Vice President, Onyx Point, Inc
> (410) 541-6699
> tvaug...@onyxpoint.com
>
> -- This account not approved for unencrypted proprietary information --
>
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com
-- 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 puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUWjDmfG5DO5fP9YKh3LEaZk9zjd0MBEN5KCNgzvDvmDQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
