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 doug.garst...@gmail.com 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.
Re: [Puppet Users] Re: Resources existing in different operating systems.
On Fri, Jun 3, 2011 at 12:52 AM, Luke Bigum luke.bi...@lmax.com 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.
-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 10:01 AM, Russell Howe rh...@moonfruit.com 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.
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 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.
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.
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.
[Puppet Users] Re: Resources existing in different operating systems.
On Thu, Jun 2, 2011 at 12:36 PM, Douglas Garstang doug.garst...@gmail.comwrote: 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.
