Re: [Puppet Users] Re: Resources existing in different operating systems.
Great to see this discussed, thanks for bringing it up. (Disclaimer: I'm the author of the blog post) On 03/06/11 18:05, Luke Bigum wrote: > On 03/06/11 16:21, Douglas Garstang wrote: >> I'd also like to see something, maybe in the best practices document >> on the Puppet Labs website indicating which is the correct way to >> handle specific operating ystem logic. Having multiple classes (ie a >> lot of classes) per module, means more files, which in my opinion, >> makes things confusing and it's never really clear which is the best >> way to break things up. When you have more than a few files, there's >> also a tendency to create subdirectories under manifests/, and have >> stuff like module::A::B.pp and when you start doing that, it >> becomes even more unclear how things should be arranged. I tend to use a single init.pp still for a lot of things, as I find myself writing a fair amount of common code even across different platforms. I don't find it particularly useful to split it into a new file for common bits, another for Red Hat and another for Solaris. It becomes difficult to manage as dependencies are spread across files and opportunities to rationalise common code are missed. Where I have modules where the OSes have nothing in common then I would split them out into separate redhat.pp and solaris.pp manifests. For me, this is a very small number, but it'll naturally depend on your environment. > I guess it's up to the site and the Puppet admins on how to break up > their classes. I'm not sure there's an all encompassing best practice as > everyone's requirements will be different. For example if I was just > managing CentOS and Red Hat systems, I might simply embed if/else logic > in a single class and handle the differences in the OS there, as they > are mostly the same and splitting off a separate class might be a waste > of time. > > If I was managing a site with Fedora, Ubuntu, Macs, etc, I'd definitely > go down the "conditionally include classes and subclasses", mainly for > management reasons, like a typo in "class somefile::ubuntu" doesn't > affect "class somefile::redhat". Also the logging of resources indicates > exactly which class::subclass::subsubclass a resource is declared in, so > I know where to go hunting to make a change to it. In practice I'd make > judgement calls about when to split a class into subclasses based on > operating systems or to nest if/else statements in a class based on how > complex the class was getting, and so I'd have a mixture of both. That's fair enough. I found the consistency quite useful when working in a team, so it became a familiar pattern across every module in this case - even if that meant some classes were empty. -- Dominic Cleal Red Hat Consulting m: +44 (0)7818 512168 -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
RE: [Puppet Users] Re: Resources existing in different operating systems.
> What if the file doesn't exist at all on the other distro? I > know for example that centos creates a symlink from > /boot/grub/grub.conf to /etc/grub.conf. What if I only wanted > to manage this file for CentOS, and for other distro's, do nothing ? Put the file resource inside the case statement itself? -- Russell Howe rh...@moonfruit.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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Resources existing in different operating systems.
On 06/03/2011 10:04 AM, Douglas Garstang wrote: What if the file doesn't exist at all on the other distro? I know for example that centos creates a symlink from /boot/grub/grub.conf to /etc/grub.conf. What if I only wanted to manage this file for CentOS, and for other distro's, do nothing ? Doug. if $operatingsystem == 'centos' { file { '/etc/grub.conf': . } } is one possible solution -- Pietro Monteiro Senior Developer DECK Monitoring 115 W 8th Ave. Eugene, Oregon 97401 Office: 541-343-0110 www.deckmonitoring.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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Resources existing in different operating systems.
On 03/06/11 16:21, Douglas Garstang wrote: I'd also like to see something, maybe in the best practices document on the Puppet Labs website indicating which is the correct way to handle specific operating ystem logic. Having multiple classes (ie a lot of classes) per module, means more files, which in my opinion, makes things confusing and it's never really clear which is the best way to break things up. When you have more than a few files, there's also a tendency to create subdirectories under manifests/, and have stuff like module::A::B.pp and when you start doing that, it becomes even more unclear how things should be arranged. I guess it's up to the site and the Puppet admins on how to break up their classes. I'm not sure there's an all encompassing best practice as everyone's requirements will be different. For example if I was just managing CentOS and Red Hat systems, I might simply embed if/else logic in a single class and handle the differences in the OS there, as they are mostly the same and splitting off a separate class might be a waste of time. If I was managing a site with Fedora, Ubuntu, Macs, etc, I'd definitely go down the "conditionally include classes and subclasses", mainly for management reasons, like a typo in "class somefile::ubuntu" doesn't affect "class somefile::redhat". Also the logging of resources indicates exactly which class::subclass::subsubclass a resource is declared in, so I know where to go hunting to make a change to it. In practice I'd make judgement calls about when to split a class into subclasses based on operating systems or to nest if/else statements in a class based on how complex the class was getting, and so I'd have a mixture of both. All I was asking for was a way to conditional manage a resource based on the operating system. Something like: file { $operatingsystem ? { 'centos' => { "/etc/somefile": source => }, 'default' => {} } Regarding your example above, that won't work, a Selector is a RHS operator, so can't be used like that. You'd need to either use a case statement or if/else block, from the docs: | if $is_virtual { service {'ntpd': ensure => stopped, enable => false, } } else { service { 'ntpd': name=> 'ntpd', ensure => running, enable => true, hasrestart => true, require => Package['ntp'], } } | -- Luke Bigum Information Systems luke.bi...@lmax.com | http://www.lmax.com LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Resources existing in different operating systems.
On Fri, Jun 3, 2011 at 10:01 AM, Russell Howe wrote: > > -Original Message- > > From: puppet-users@googlegroups.com > > [mailto:puppet-users@googlegroups.com] On Behalf Of Douglas Garstang > > Sent: 03 June 2011 16:21 > > To: puppet-users@googlegroups.com > > Subject: Re: [Puppet Users] Re: Resources existing in > > different operating systems. > > > All I was asking for was a way to conditional manage a > > resource based on the operating system. Something like: > > > > file { > > > > $operatingsystem ? { > > 'centos' => { > > "/etc/somefile": > > source => > > }, > > 'default' => {} > > } > > > > Haven't tried it, but I don't think that's allowed. > > > > Doug. > > How about > > case $operatingsystem { >'centos': { $filesource = "/bar" } >default: { $filesource = "/foo" } > } > > file { "name": >source => $filesource, ># ... > } > > What if the file doesn't exist at all on the other distro? I know for example that centos creates a symlink from /boot/grub/grub.conf to /etc/grub.conf. What if I only wanted to manage this file for CentOS, and for other distro's, do nothing ? Doug. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
RE: [Puppet Users] Re: Resources existing in different operating systems.
> -Original Message- > From: puppet-users@googlegroups.com > [mailto:puppet-users@googlegroups.com] On Behalf Of Douglas Garstang > Sent: 03 June 2011 16:21 > To: puppet-users@googlegroups.com > Subject: Re: [Puppet Users] Re: Resources existing in > different operating systems. > All I was asking for was a way to conditional manage a > resource based on the operating system. Something like: > > file { > > $operatingsystem ? { > 'centos' => { > "/etc/somefile": > source => > }, > 'default' => {} > } > > Haven't tried it, but I don't think that's allowed. > > Doug. How about case $operatingsystem { 'centos': { $filesource = "/bar" } default: { $filesource = "/foo" } } file { "name": source => $filesource, # ... } -- Russell Howe rh...@moonfruit.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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Resources existing in different operating systems.
On Fri, Jun 3, 2011 at 12:52 AM, Luke Bigum wrote: > Douglas, > > If you don't use a conditional somewhere, how are you going to decide what > resources are declared on what clients? > I never said I didn't want to use conditionals somewhere. > > In that blog example, the classes are loaded based on the value of a fact > reported by the Puppet client, in some ways "more reliable" than a variable > defined in a Puppet master manifest. It's also not that bad a practice to > conditionally include on variables declared at the top level (node.pp) - > avoids variable scoping issues, a number of people on the list do that. > Yes, I understand that. We don't put our variables in the manifests. We put them into csv files and use extlookup, which works great. However, I'm not talking about the use of variables here. I'm talking about logic based on operating system. I'd also like to see something, maybe in the best practices document on the Puppet Labs website indicating which is the correct way to handle specific operating ystem logic. Having multiple classes (ie a lot of classes) per module, means more files, which in my opinion, makes things confusing and it's never really clear which is the best way to break things up. When you have more than a few files, there's also a tendency to create subdirectories under manifests/, and have stuff like module::A::B.pp and when you start doing that, it becomes even more unclear how things should be arranged. I've been working with puppet for over three years now and variable scoping still isn't clear to me. > Using sub classes based on operating system also gives you the added > advantage of tracking down problems sooner, a Puppet error will look like: > > Foo::Redhat::File["foo.conf"] ... > > What approach would you like to see, conceptually? Maybe someone's done > something similar with an ENC. > > All I was asking for was a way to conditional manage a resource based on the operating system. Something like: file { $operatingsystem ? { 'centos' => { "/etc/somefile": source => }, 'default' => {} } Haven't tried it, but I don't think that's allowed. Doug. } -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Resources existing in different operating systems.
Douglas, If you don't use a conditional somewhere, how are you going to decide what resources are declared on what clients? In that blog example, the classes are loaded based on the value of a fact reported by the Puppet client, in some ways "more reliable" than a variable defined in a Puppet master manifest. It's also not that bad a practice to conditionally include on variables declared at the top level (node.pp) - avoids variable scoping issues, a number of people on the list do that. Using sub classes based on operating system also gives you the added advantage of tracking down problems sooner, a Puppet error will look like: Foo::Redhat::File["foo.conf"] ... What approach would you like to see, conceptually? Maybe someone's done something similar with an ENC. -Luke On 03/06/11 05:25, Douglas Garstang wrote: On Thu, Jun 2, 2011 at 12:36 PM, Douglas Garstang mailto:doug.garst...@gmail.com>> wrote: So... I'm thinking about how to have puppet manage different operating systems. It's one thing to use a selector to determine the value of specific resources attribute, but what do you do when a file may not exist on a specific O/S? You can't use a selector in this case. I really don't like the approach described here either... http://m0dlx.com/blog/Puppet_manifests__a_multi_OS_style_guide.html ...where classes are loaded dynamically based on the value of a variable. What would best practice indicate? Doug. *jabs anyone that's prepared to be jabbed* -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Luke Bigum Information Systems luke.bi...@lmax.com | http://www.lmax.com LMAX, Yellow Building, 1A Nicholas Road, London W11 4AN The information in this e-mail and any attachment is confidential and is intended only for the named recipient(s). The e-mail may not be disclosed or used by any person other than the addressee, nor may it be copied in any way. If you are not a named recipient please notify the sender immediately and delete any copies of this message. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Any view or opinions presented are solely those of the author and do not necessarily represent those of the company. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.