Puppet users - Dec 2010 - Best practices using puppet on partially installed systems.

So, my configuration attempts are aimed at Linodes .


Ubuntu 10.10 to be exact.


Linodes are libcloud enabled as well as basically provisioned. What I
seek to do is add to that, not build from nothing, since libcloud et.
al. give me a base to work with.


What is the canonical way to manage this situation?


For example:



$ puppet resource package --verbose openssh-client


package { ''openssh-client'':
ensure => ''1:5.5p1-4ubuntu4''
}


Does my manifest need to take this and similar into account? 

-- 
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 Fri, Dec 10, 2010 at 15:00, Kevin Beckford <lazyweb@gmail.com> wrote:
> So, my configuration attempts are aimed at Linodes.  Ubuntu 10.10 to be
exact.
> Linodes are libcloud enabled as  well as basically provisioned.  What I
seek
> to do is add to that, not build from nothing, since libcloud et. al. give
me
> a base to work with.
> What is the canonical way to manage this situation?
I can''t necessarily speak to the "canonical" way, but the
process we
use for our infrastructure is relatively similar.  Debian based,
private cloud type facility, but the starting point is more or less
where the libcloud puppet example puts things - Debian, with puppet
installed.
> For example:
> $ puppet resource package --verbose openssh-client
> package { ''openssh-client'':
>     ensure => ''1:5.5p1-4ubuntu4''
> }
> Does my manifest need  to take this and similar  into account?
Puppet has a policy that if you don''t tell it about something one way
or another it will leave it the heck alone.  (This is worth mentioning
because other tools in the space take the view that if they don''t
know, get rid of it.)

So, to answer the specific question: it depends.  You could just
ignore it, and have faith that the pre-installed package was doing the
right thing.  Personally, I would have "package {
''openssh-client'':
ensure => latest }" in there because upgrades to it are smooth,
typically security related, and have a long history of not breaking
things.

In terms of the bigger philosophical question: I would advise that you
define in puppet what the machines should look like.  That means that
if you care about ssh as a service you should specify that it is
installed, at least.  When the package is already there puppet will
see that, and take no further action.  OTOH, if it doesn''t install on
some random machine for who knows what reason, or some typo purges it,
puppet will restore the machine to the way it should be.

OTOH, I probably left 95 percent of the "base" system packages out of
my manifests, because they were just there and there was no benefit to
writing out hundreds of "just in case" declarations.

Regards,
    Daniel
-- 
✣ Daniel Pittman            ✉ daniel@rimspace.net            ☎ +61 401 155 707
              ♽ made with 100 percent post-consumer electrons

-- 
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.

Much appreciated, the good advice. Thanks. That makes total sense, 

-- 
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.