Good morning, I am trying to wrap my head around following problem. It would be wonderful to be able to reuse definitions applying either inheritance (ideally) or mix-ins but it seems that I have hit a puppet''s "by design" limitation. I absolutely understand than Classes are to be used for the singleton items on the nodes and definitions for any multiple items but I have exactly the case where it would be great to have inheritance on definition level. Example: For me granularity starts already on httpd.conf level ( I have to maintain 4 different Apache configs on a given node). So far I am using definitions to do this, but then inside configs I have to manage different configuration for SSL (engines on/off, different ciphers, CAs etc) for front and back interfaces for each of four instances, on case by case basis these configuration properties are inherited, redefined, override etc ... classes would be exactly the thing to manage those. Here are my top-down layers: node foo1{ $ip_front = xxx $ip_back = yyy include fw1_services } node foo2{ $ip_front = aaa $ip_back = bbb include fw1_services } class fw1_services { #call bunch of apache::httpd_config defines to create httpd.conf for each channel apache::httpd_config {"channel1": sslfront=>on} apache::httpd_config {"channel2": sslfront=>on, <potentially long list of highly specific modssl arguments specific>} apache::httpd_config {"channel3": sslfront/back=>off} apache::httpd_config {"channel4": sslfront/back=>on} } Or in terms of common puppet examples: node,apache (singleton), virtual host (defintion) - I need some inheritance reuse on virtual host level. Only one way to do this is via template, but so far I tied to stay rather generic here and keep all my "business" logic away from template "representation". Any other suggestions? Regards, Thomas --~--~---------~--~----~------------~-------~--~----~ 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 groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 13, 2009, at 5:11 AM, thomas wrote:> > Good morning, > > I am trying to wrap my head around following problem. It would be > wonderful to be able to reuse definitions applying either inheritance > (ideally) or mix-ins but it seems that I have hit a puppet''s "by > design" limitation. > > I absolutely understand than Classes are to be used for the singleton > items on the nodes and definitions for any multiple items but I have > exactly the case where it would be great to have inheritance on > definition level. > > Example: For me granularity starts already on httpd.conf level ( I > have to maintain 4 different Apache configs on a given node). So far > I am using definitions to do this, but then inside configs I have to > manage different configuration for SSL (engines on/off, different > ciphers, CAs etc) for front and back interfaces for each of four > instances, on case by case basis these configuration properties are > inherited, redefined, override etc ... classes would be exactly the > thing to manage those. > > Here are my top-down layers: > > node foo1{ > $ip_front = xxx > $ip_back = yyy > include fw1_services > } > > node foo2{ > $ip_front = aaa > $ip_back = bbb > include fw1_services > } > > class fw1_services { > #call bunch of apache::httpd_config defines to create httpd.conf for > each channel > apache::httpd_config {"channel1": sslfront=>on} > apache::httpd_config {"channel2": sslfront=>on, <potentially long > list of highly specific modssl arguments specific>} > apache::httpd_config {"channel3": sslfront/back=>off} > apache::httpd_config {"channel4": sslfront/back=>on} > } > > Or in terms of common puppet examples: node,apache (singleton), > virtual host (defintion) - I need some inheritance reuse on virtual > host level. > > Only one way to do this is via template, but so far I tied to stay > rather generic here and keep all my "business" logic away from > template "representation".I don''t think I totally understand where you actually need the reuse here, but I wouldn''t call this a limitation by design - I actually added inheritance to definitions at one point, but took it out as it was deemed too complex by the few people who seemed to notice the work. Can you elaborate on where the reuse is necessary? -- No matter how rich you become, how famous or powerful, when you die the size of your funeral will still pretty much depend on the weather. -- Michael Pritchard --------------------------------------------------------------------- Luke Kanies | reductivelabs.com | madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> Can you elaborate on where the reuse is necessary?In my case in the sections of httpd.conf. I''d love to find a way to have some ''abstract'' modssl, modproxy,modesc sections and derive from it for inbound/outbound traffic specifc configuration snippets assembling appropriate httpd.conf at the end (Have to use different logic for CAs, keys, logs). I ended up passing some variable into erb templates and keeping the decision logic there, but it would be rather cleaner to keep it at the class/definition level of course. I understand "limitation by design" though! --~--~---------~--~----~------------~-------~--~----~ 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 groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---