On Dec 15, 4:03 am, Alexandre <alexandre.fou...@gmail.com> wrote:
> I though i found a way to do it, and i would like to show it here,
> but unfortunately it does not exactly work well, see the comment in
> uppercase: global variables seems to be set even if no class from
> the .pp file is included.
Yes. Modules and manifest files do not provide scoping.
> And i also think now i am going to far into akwardness, just trying
I agree (a bit more on that below).
> to work around some Puppet limitations, or maybe thinking of Puppet
> beyond its scope, as if it was a full featured language
Puppet is a declarative language. Users who come from a programming
background seem sometimes to have difficulty coming to grips with
that. If you ever find yourself thinking "how do a make Puppet do
foo?" then you are off to a wobbly start. A better question is
usually "how do I explain foo to Puppet?".
> I am wondering now if it is always a good idea to try to do
> everything within Puppet.
Puppet does have limits to what it can do natively for you (though it
is also highly extensible). Where it is possible, using Puppet types
other than Exec to get the work done has several advantages.
[...]
> and ended up having this
> define only get the parameters and give it all to a deployed script
> that does the processing (just because i needed to loop on the items
> of a puppet array).
Puppet is not built to do user-defined processing, except inasmuch as
you can always create your own types and / or providers.
> Anyway, here was my last, and almost working to get the default
> stripdown (shows relevant parts) :
[...]
> # This variable is global, not defined inside the class, otherwise it
> will never be seen as set, due to the dynamic scope
> $_service_is_managed_mysqld=1
So the idea is that you have a variable for each service that later
instructs Puppet whether to run "stripdown" commands for that
service? And that implies that somewhere you dynamically choose a
value for this variable based on the facts presented to the
puppetmaster?
That seems awfully convoluted. Why not use that same decision logic
to dynamically choose whether to include a class? Furthermore, if you
have to make that decision dynamically, then it is no harder to choose
between two alternative classes than to make only a yes/no decision
about a single class. That leads to having two alternative classes,
one declaring "stripdown"-configured resources and the other declaring
enabled resources, where you dynamically decide which to include for
each node. And that's what I have been recommending all along.
[...]
> if $pattern == "" {
> exec { "stripdown $name stop":
> command => "service $name stop",
> onlyif => "service $name status",
> path => "/usr/bin:/usr/sbin:/bin:/sbin",
> }
> }
[etc.]
I'm not seeing what that "stripdown" define does for you that the
Service type doesn't, unless .... Please tell me that you're not
using these Execs to change the state of Services declared elsewhere!
That way lies madness.
I guess I'm at a loss as to what problem you're trying to solve any
more. Silviu and I offered two solutions to you, either one of which
will work cleanly and entirely within Puppet to solve your problem as
I understood it. What more are you looking for that neither of these
provides?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
