this topic is currently being massively discussed so I just would like to share
my pain also.
my intention was to have an array of node''s roles and each included
role class would just record into the array its role identificator. then I could
write simple function has_role and then write various condition with role
checks. imho this would be awesome however impossible to implement with variable
scoping.
individual roles would be defined as classes as follows (this is just an example
demonstrating the varscope issue so don''t try to find a workaround for
this simple case as I am more interested how to implement this whole idea):
class root_role {
$node_roles = []
}
class role_mysql extends root_role {
$node_roles += [ "role_mysql" ]
include mysql
}
class role_postgres extends root_role {
$node_roles += [ "role_postgres" ]
include mysql
}
class role_basehost {
if has_role("role_postgres") {
<some action>
} else {
<another action>
}
}
node lamp {
include role_postgres
include role_basehost
}
obviously this doesn''t work. maybe you have now idea to use directly
the $root_role::node_roles and reference it in all other roles however that
wouldn''t work neither cause the qualified variables from other classes
are readonly.
this is pain, pain and again pain!
cry with me,
Antony.
--
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.
Wow, this really makes Puppet look like a programming language, which it isn''t. Have you considered creating classes for each of the roles and then classes that include those roles and then assigning one of those classes to each node? We have hundreds of combinations here but that''s how we do it and it works fine. So in your example, your node lamp could just include postgres instead of a role_postgres and then rely on some other class to do the right thing. It seems like an inversion of the hierarchy, which is fun in programming but not in modeling. But yes, if you insist on doing it this way, it will be painful. :) ----- "Antony Mayi" <antonymayi@yahoo.com> wrote:> this topic is currently being massively discussed so I just would like > to share my pain also. > > > my intention was to have an array of node''s roles and each included > role class would just record into the array its role identificator. > then I could write simple function has_role and then write various > condition with role checks. imho this would be awesome however > impossible to implement with variable scoping. > > > individual roles would be defined as classes as follows (this is just > an example demonstrating the varscope issue so don''t try to find a > workaround for this simple case as I am more interested how to > implement this whole idea): > > > class root_role { > $node_roles = [] > } > > > class role_mysql extends root_role { > > $node_roles += [ "role_mysql" ] > include mysql > } > > > > > class role_postgres extends root_role { > $node_roles += [ "role_postgres" ] > include mysql > } > > > class role_basehost { > if has_role("role_postgres") { > <some action> > } else { > <another action> > } > } > > > node lamp { > include role_postgres > include role_basehost > } > > > obviously this doesn''t work. maybe you have now idea to use directly > the $root_role::node_roles and reference it in all other roles however > that wouldn''t work neither cause the qualified variables from other > classes are readonly. > > > this is pain, pain and again pain! > cry with me, > Antony. > > > > -- > 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.-- Digant C Kasundra <digant@stanford.edu> Infrastructure Systems Software Developer, ITS:IDG, Stanford University -- 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 Mon, Jun 28, 2010 at 10:22 AM, Antony Mayi <antonymayi@yahoo.com> wrote:> this topic is currently being massively discussed so I just would like to > share my pain also. > > my intention was to have an array of node''s roles and each included role > class would just record into the array its role identificator. then I could > write simple function has_role and then write various condition with role > checks. imho this would be awesome however impossible to implement with > variable scoping. > > individual roles would be defined as classes as follows (this is just an > example demonstrating the varscope issue so don''t try to find a workaround > for this simple case as I am more interested how to implement this whole > idea): > > class root_role { > $node_roles = [] > } > > class role_mysql extends root_role { > $node_roles += [ "role_mysql" ] > include mysql > } > > class role_postgres extends root_role { > $node_roles += [ "role_postgres" ] > include mysql > } > > class role_basehost { > if has_role("role_postgres") { > <some action> >why cant this logic just go in the role postgres class?> } else { > <another action> > } > } > > node lamp { > include role_postgres > include role_basehost > } > > obviously this doesn''t work. maybe you have now idea to use directly the > $root_role::node_roles and reference it in all other roles however that > wouldn''t work neither cause the qualified variables from other classes are > readonly. >you could always embed this kind of logic in an external node classifier.> this is pain, pain and again pain! > cry with me, > Antony. > > -- > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. >-- 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.