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
-~----------~----~----~----~------~----~------~--~---
