On Wed, Aug 17, 2011 at 6:44 AM, jcbollinger <john.bollin...@stjude.org> wrote:
>> * We're not using ENC
>
>
> Fair enough. I don't use one either, but it was worth pointing out
> the possibility.
Yes, and it is an additional argument to migrate there eventually.
>> * I want the special information right alongside the node decl. This
>> reduces chance for error and makes the data more maintainable.
>
>
> So that's the constraint that is really biting you, in more ways than
> one, and I feel obligated to observe that it is a style / practices
> issue, not an infrastructure issue.
But it is a good style. It is bad style to spread the information in
several places where they can get out of sync with each other. We did
our best to deploy our puppet deployment according to the best
practices at the time, and it would even still work with the current
version of puppet; I just don't want to depend on dynamic scoping
which is going away.
Yes, the ENC solves that, but I need a workaround now, not later after
we've migrated to ENC. We have a deadline for implementing the
failover and I'm trying to find the cleanest interim solution.
> Ok, so that rules out regex hostname matching, both in node
> declarations and in selector expressions. It makes it less palatable,
> but by no means impossible to use a selector somewhere to choose a
> value for $failover. It remains your stipulation that $failover be
> assigned in the node declaration that narrows your options here.
Yes - I don't want the failover variable buried in manifests further
below. It is an attribute of the node, not the classes the node
includes.
> Your constraint that the failover information be in the node
> declarations is again what's driving you here. It is not consistent
> to insist that node declarations must contain more information, but at
> the same time complain that they become longer / more complex.
It is consistent if I have to jump through hoops of making them more
complex just to set an attribute :)
>> Maybe the answer is to make a case statement in the nodes.pp that sets
>> $IMSPECIAL globally based on the hostname... which was one of your
>> suggestions. But I don't like maintaining two lists of host regex's,
>> which could get out of date.
>>
>> Is there no specifier to reach my node's scope? i.e.,
>> $mynode::IMSPECIAL? Maybe in Ruby?
>
>
> Only dynamic scoping, as far as I know, and that's going away. Also,
> it doesn't work with node inheritance the way you would like it to do.
That's unfortunate.. 'cause I can refer to an arbitrary class with
$foo::var. I'd hoped there was some scoping sugar to refer to my node
scope.
I can refer to my parent class by name, so I 'd think it natural to
want to refer to node scopes.
node "a" { include c }
class b { $b = 1 }
class c inherits b { notice($b::b) }
or
class b {
$b = 1
notice($c::c)
}
class c {
$c = 2
include b
notice($b::b)
}
> It may be that Hiera provides a way to paper over this problem. I
We'll definitely check out Hiera someday, but right now isn't the time.
> Alternatively, you could drop the plan to use node inheritance. You
> must have a viable plan for identifying your failover nodes by their
> hostnames (even if its just knowing specific names),
We have specific names, but it is prone to error as we add more. I'm
not the only one maintaining this puppet environment. The real
problem is that we deployed this failover site using the same naming
conventions as non-failover systems in the same datacenter.
We do have a machine database that we query inside of puppet to make
some variables... i.e., $machine_database::location,
$machine_database::category. I think THAT is how we're going to have
to solve this problem for now -- which is sort of like solving it with
an ENC. Eventually we want to have this db drive the ENC anyway.
> for your original
> idea is predicated on such a plan. Therefore, instead of applying
> that logic to choose which node declaration to apply, you can instead
> use it either within node declarations or without to set your magic
> variable or class parameter, or to include a different / extra class.
> For example:
>
> node /.*our-db\d+/ {
> $failover = $hostname ? { /our-db\d+/ => false, default => true }
> include system:our_db
> }
I'm not following -- doesn't that example have the same problem? The
variable $failover has no visibility outside of this scope.
Anyway, discussing it more internally, we're going to use an attribute
of the machine database.
Thanks for all the suggestions -- saves me time from heading down wrong paths!
Rich
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@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.
