On 2014-17-06 22:14, Trevor Vaughan wrote:
Do you like dead threads? like dead threads....
Only some of them (like this one)...
So, I was looking back over this and there's one thing that we
desperately need as a community.
We need defined(Class['foo']) and it needs to know about ALL classes in
the catalog at compile time, not just the ones that got included before it.
By ALL classes I assume you mean all the classes that will have been
evaluated and included in the catalog at the time the catalog
compilation is finished?
This would save a TON of heartburn in a lot of cases.
For instance, right now, I have to do:
# Don't reverse these two!
include 'foo'
include 'bar'
Where bar has something like:
if defined(Class['foo']) {
do something that happens if bar has foo
}
In theory, this also rides into unmangling some of the roles/profiles
configurations that I've seen posted around where people twist
themselves in knots using variables to make sure that their classes are
included properly when a simple if defined(Class['foo']) would make all
of that disappear.
I would like to suggest that this get fixed in the future parser and
that it be singled out as something like 'has_class'..
if has_class('foo') { stuff }
Thoughts?
It is quite difficult to achieve as a general "see if it is defined now"
since an inclusion can take place in conditional logic, from logic in
ruby code (using define_resources), classes can be parameterized and
instantiated with resource creation syntax (which makes them unknown to
the system until the class / resource type that realizes them is evaluated.
In other words - close to impossible to do this accurately given all the
ways classes can be added to the catalog during the evaluation. At least
as a simple lookup of Class['foo'].
I can imagine a mechanism that kicks in towards the end of the
compilation but that is also complicated - one part of the logic has a
rule that if X is missing it does Y, and another rule adds X if it is
(directly or indirectly missing). We can also add callbacks - say when a
class is added to the catalog - can trigger a code block that is then
evaluated. (This is harder to trigger for something that is not in the
catalog), but maybe this could be another set of callbacks, and they
keep triggering until nothing more is triggered).
(PROLOG anyone? Constraint solver?)
I can also imagine being made more aware of when things do occur and
only take action when certain things are known - a sort of orchestration
of the composition of the catalog. This would enable stating things like
"include this in the catalog when these conditions hold / when these
other things are done". This is not much unlike the callbacks /
constraints scenario above, but in a fashion where it is possible to
reason about what is going to happen (starving, deadlocking, endless
looping). (This is an idea that I think is very powerful and that can
extend to agents as well)
Maybe we can find some compromise. One area that has been discussed is
the domain of queries. The do run after the rest of the compilation has
been made, but they can currently only do certain pre-defined tasks
(like realizing resources). Maybe a better query and more powerful query
mechanism is enough. (Again very similar to registered callbacks with
predicates that trigger at the end - that is basically what the query
mechanism is now (i.e. the spaceship operators).
I do also think that there are other fundamental compositional
mechanisms missing - say the ability to extend things in a fashion that
the extended party is aware of how it is extended (or will be extended
because someone promised / declared this). Naturally, the reverse is
also needed; if module X is included and A, B are in the catalog, then X
will do something without A, and B being aware (a reverse dependency if
you like).
Just some thoughts on the topic.
- henrik
Thanks,
Trevor
On Thu, Feb 20, 2014 at 4:17 AM, Daniele Sluijters
<daniele.sluijt...@gmail.com <mailto:daniele.sluijt...@gmail.com>> wrote:
I like a constrains style solution much better myself to, wasn't
aware of it at the time.
I think with Puppet 4 we could introduce some additional pain,
semver wise we'd be
allowed to do that. If that helped fix this issue once and for all
I'm pretty sure the
community would support it too.
On Wednesday, 19 February 2014 23:31:24 UTC+1, Markus wrote:
> I'm not very fond of the idea of hardwiring special support for
> Package resources into Puppet (nor for resources of any other
specific
> type). I still like my "constraints" idea, to which Felix
directed
> your attention, but if something like that is ever
implemented then
> adopting it will require (smallish) modifications to be made
to a lot
> of manifests.
+1 to a constraints style solution. Figuring how to do it without
causing a lot of widespread minor pain would be an added plus. :)
--
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
<mailto:puppet-dev%2bunsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/d680773d-57bb-49e5-9875-f543ace773b0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com <mailto: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
<mailto:puppet-dev+unsubscr...@googlegroups.com>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoV3th5f-uHM7wqL6LOPoJf-%2BxWUhB%2BJAAhh7Tua2rA8Pw%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoV3th5f-uHM7wqL6LOPoJf-%2BxWUhB%2BJAAhh7Tua2rA8Pw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
For more options, visit https://groups.google.com/d/optout.
--
Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/
--
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/lnqqkl%245ai%241%40ger.gmane.org.
For more options, visit https://groups.google.com/d/optout.
