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? /br 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Wed, Dec 3, 2008 at 5:14 AM, Stasheck <stanislaw.kaminski@gmail.com> 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 --~--~---------~--~----~------------~-------~--~----~ 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+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Dec 3, 5:23 pm, "Evan Hisey" <ehi...@gmail.com> wrote:> On Wed, Dec 3, 2008 at 5:14 AM, Stasheck <stanislaw.kamin...@gmail.com> 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. > > EvanYes, 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 <stanislaw.kaminski@gmail.com>wrote:> > On Dec 3, 5:23 pm, "Evan Hisey" <ehi...@gmail.com> wrote: > > On Wed, Dec 3, 2008 at 5:14 AM, Stasheck <stanislaw.kamin...@gmail.com> > 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
That''s a bit out of the topic, but what are external nodes for? /br Stanislaw On Dec 4, 10:18 am, "Andrew Shafer" <and...@reductivelabs.com> 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 <stanislaw.kamin...@gmail.com>wrote: > > > > > On Dec 3, 5:23 pm, "Evan Hisey" <ehi...@gmail.com> wrote: > > > On Wed, Dec 3, 2008 at 5:14 AM, Stasheck <stanislaw.kamin...@gmail.com> > > 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 <stanislaw.kaminski@gmail.com>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" <and...@reductivelabs.com> 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 <stanislaw.kamin...@gmail.com > >wrote: > > > > > > > > > On Dec 3, 5:23 pm, "Evan Hisey" <ehi...@gmail.com> wrote: > > > > On Wed, Dec 3, 2008 at 5:14 AM, Stasheck < > stanislaw.kamin...@gmail.com> > > > 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---