It's really not out of topic per se.

External nodes lets you decouple you declarations of classes from the
assignment.  Assignment becomes programmatic, both for the classes and any
variables.

A custom function would let you dynamically calculate the backups from a
table (or whatever logic).

External nodes would let you dynamically determine what server should be A
as well, if that makes sense.


On Thu, Dec 4, 2008 at 8:15 AM, Stasheck <[EMAIL PROTECTED]>wrote:

>
> That's a bit out of the topic, but what are external nodes for?
>
> /br
> Stanislaw
>
> On Dec 4, 10:18 am, "Andrew Shafer" <[EMAIL PROTECTED]> wrote:
> > I'd think a custom function with logic to parse a table would be easier
> to
> > maintain.
> >
> > Or, my new hammer for every nail, use external nodes and assign those
> > variables in logic there.
> >
> > On Thu, Dec 4, 2008 at 1:37 AM, Stasheck <[EMAIL PROTECTED]
> >wrote:
> >
> >
> >
> > > On Dec 3, 5:23 pm, "Evan Hisey" <[EMAIL PROTECTED]> wrote:
> > > > On Wed, Dec 3, 2008 at 5:14 AM, Stasheck <
> [EMAIL PROTECTED]>
> > > wrote:
> >
> > > > > Hi there,
> >
> > > > > As I don't like abstract talking, I'll make an example of what I
> need.
> >
> > > > > Let's say I have list of servers: A, B, C, D, E.
> >
> > > > > Now, every server should have a config file (let's give it a name
> of
> > > > > "test.conf") in which it's primary and secondary backup is
> specified.
> > > > > It should be maintained as a list of backups, like:
> >
> > > > > Cur Pri Sec
> > > > > A       B   C
> > > > > B       A   C
> > > > > C       B   D
> > > > > D       A   E
> > > > > E       D   B
> >
> > > > > Perfect way would be to make associative table (ATable) and do sth
> > > > > like:
> > > > > Pri_back = ATable ($current_server, Pri)
> > > > > Sec_back = ATable ($current_server, Sec)
> >
> > > > > and then use Ruby magic to put $Pri_back and $Sec_back into
> test.conf
> > > > > file.
> >
> > > > > All of this, of course, in puppet modules ;-)...
> >
> > > > > Can somebody point me to an idea how to create sth like this?
> >
> > > > This sounds way complicated, this way. I suspect it would be simpler
> > > > and safer to either use a template that you passed the servers to via
> > > > variables or used the generate function to create the list on the fly
> > > > from a master script on the server.
> >
> > > > If I get the setup correctly server A would have a file that listed
> > > > servers B and C as backup, server B would have a file that list
> > > > servers A and C, etc,etc. If this is correct the the simplest way
> > > > would be to just have two variables defined in the Node definition
> for
> > > > P_backup and S_backup. In your module just pass the variables to a
> > > > template to create the file.
> >
> > > > Or Option 2, create a template with case logic that checks the node
> > > > hostname and then assigns the correct backups to the template. I
> > > > personally suspect the first choice is saner.
> >
> > > > Evan
> >
> > > Yes, you got me right. All I want is to keep the list in one place,
> > > independent of node definitions. What I didn't wrote is that A, B, C
> > > and so on are about name of location the nodes are in, not the node
> > > names itself - that explains why I don't want to keep it in node
> > > definitions.
> >
> > > As a solution, I can create rvalue function in Ruby and use it in
> > > puppet, but I want to use only Puppet whenever I can.
> >
> > > I guess I'll do sth like this:
> >
> > > case $own_loc {
> > >          A:  {
> > >                    pri_back => "B";
> > >                    sec_back => "C";
> > >                 }
> > >          B:  {
> > >                     .....
> > >                }
> > > }
> >
> > > As insane as it may seem ;-), I'll put it into separate file included
> > > in site.pp and parsed for every node.
> >
> > > Oh, and $own_loc is a custom fact already.
> >
> > > Anyway, thanks :-)
> >
> > > Stanislaw
> >
>

--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to