Yes all of this is very convoluted, but not because of my mind,
just because Puppet PARSER is too strict and prevents states that can
exists in the real.
No, i do not try to use exec to change the change the state of the
service which is -executed- elsewhere (i aggree it would be stupid and
impossible, a ressource can not have two different status at the same
time), but i do use exec to set services that are -declared- elsewhere
in puppet, but not included(executed). So that the state of the
service is the one of the exec. Unfortunately, i had to do that,
because otherwise Puppet would complain at -parsing- time, not execute
time, since it does not want to have the same ressource(here service)
declared twice, even if one is not included for the node, nor be
overriden if not in a child class (and i understand very well the
logic behind that, it makes sense, if we do not consider that we could
assign priorities or precedences on puppet ressources (but then it
could be a mess :-/))
I also checked your solutions, but it does not solve what i wanted
to achieve. What i wanted is per node :
- if i want to include a class (eg mysql::server), then i
include it.
- If it is missing(not included or required by some other
included class), then have the default global stripdown executed.
As i understood, your solution says that if i do not want a
service in a node, then i should include the disabled class (eg
mysql::server::disabled). This is not what i want, what i want is my
nodes definition to be agnostic of what could have been included
previously in the past or may already be present on the server. I do
not want for each node to declare every ressource that exist in my
puppet repo to be disabled (Eg if only 1 node of my 100 needs mysql
running, i do not wish to have to include mysql::server::disabled in
the 99 other nodes definitions. But i want to ensure the mysqld
service is down for these 99 nodes, in case it was running on the node
for whatever reason).
Of course, we need to accept that puppet will try to stripdown
services that are not even installed, but i do not see it as a
problem.
I think this is good general practice of sysadmin to ensure
everything on a linux system that is not needed should be removed,
restricted or disabled (services, users, dir permissions). As we see
here, it seems Puppet can not fullfill this need, except by listing
explicitely and exhaustively what needs to be or not be activated for
each node. So of course, one way or another, there is a place where i
need to tell what should be stripdowned. But i want it to be accepted
as the default -state- of the node, unless specified otherwise by
including a class which redefines some of the ressources that need to
be activated. I do not want my nodes.pp to be 1000000 lines and
unmaintanable.
I understand the meaning of declarative language. I just miss the
fact that i can not declare something like if something is not
included, then apply this whole set of declarations.
-> Unfortunately for me, there might be a way to do this
"default state"/"included state" scheme in Puppet, or by including
ruby or facter or ..., but i am not a puppet expert. This could maybe
be the subject of another thread
On 15 déc, 22:56, jcbollinger <john.bollin...@stjude.org> wrote:
> 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.
