On Aug 16, 11:24 am, Rich Rauenzahn <rraue...@gmail.com> wrote:
> On Tue, Aug 16, 2011 at 6:23 AM, jcbollinger <john.bollin...@stjude.org>
> wrote:
>
> [Lots of good ideas]
>
>
>
> > Of those, I would recommend either extlookup() or your ENC (if you
> > have one), with my personal preference being extlookup(). I think
> > Hiera may offer an even better solution (though similar to
> > extlookup()), but I'm not familiar enough with it to feel comfortable
> > recommending it.
>
> Unfortunately I've thought of some of those and they don't quite fit
> with our existing infrastructure.
>
> * We're not using ENC
Fair enough. I don't use one either, but it was worth pointing out
the possibility.
> * 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.
> Let me give more background:
>
> We have a nodes.pp with a lot of hosts in it. We map a nodename to a
> single class...
>
> node /our-squid\d+/ { include system:our_squid }
> node /our-db\d+/ { include system:our_db }
>
> and so on.
>
> We are making a failover site.
>
> node /special-our-squid\d+/ { include system::our_squid}
> node /special-our-db\d+/ { include system::our_db }
>
> I don't want to confuse the issue with more details, but due to some
> legacy naming conventions, we can't (..shouldn't...) use /^special-*/
> to determine the sites are failover. We would like the attribute in
> puppet.
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.
> I could do class { "system::our_db": failover => failover }, except I
> want that failover attribute within the class that system::our_db
> derives from.
>
> class system {
> // Am I special?
>
> }
>
> class system::our_db($failover) inherits system {
> // Am I special, too?
>
> }
>
> So ideally (except that this won't work with the new scoping rules in
> the future), I'd like to
>
> node /special-our-db\d+/ { $SPECIAL=true
> include system::our_db }
>
> Now, I could make a class
>
> class special($yesorno = false) {
> $SPECIAL = $yesorno
>
> }
>
> and include that in all nodes, and change it to false in the special
> nodes.... It isn't very elegant and makes our node file a lot
> messier. Each node is two lines now.. there must be a more elegant
> solution.
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.
> 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.
It may be that Hiera provides a way to paper over this problem. I
have not studied it enough to be sure, but it looks like it can
combine multiple data sources, including at least Puppet variables,
flat files, and databases. There are multiple ways you could use it,
including variations that set a variable in the node definition and
variations that put the lookup directly in the class that uses the
data. The data associating 'special' status with certain nodes could
be centralized or not, as you wish, and the data consumers need not be
affected if you later choose to change the data organization. If you
wanted, that data could be externalized, so that you would not need to
modify anything about your manifests when you add a new special node.
Extlookup() gives you most of that as well, but Hiera is the next,
more powerful generation of the idea.
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), 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
}
John
--
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.
