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 --
--
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%2BFoXBSteqdxsq1x6f4Y89uiciszxQvqzaSDWWz-8tyt%2BT6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
