Puppet users - Dec 2012 - ensuring consistency in package versions

Hi all,

I would appreciate your help clarifying my thinking around the following 
problem.

Let''s say I have a third-party (one that I didn''t write)
package x which
depends on a package y.

Package x is installed somewhere and is working fine against package y (as 
in package x has been QA''ed and verified to work against package y).

Now, let''s imagine I need to spin up another server to meet some load
but
when I do so I find that package y has had a security fix that has caused a 
problem in package x.
This is probably a bit of contrived case but could at least happen in 
theory. Normally, I''d want to test the fix out before I put it live but
in
this case because I had to spin a
server to meet some load this wasn''t possible and as such my package 
versions has skewed between my old and new servers.

The obvious solution to this would be to manage package versions explicitly 
but is likely to become cumbersome quite quickly especially since I may not 
even be managing
package y in my manifests explicitly.

Another solution might be to have my own package repository containing just 
the packages I have tested against and only install from there but that 
means another bit of
infrastructure to look after and manage, which I''d like to avoid if at
all
possible.

One idea I had was to maybe have a script that dumps out package versions 
and use that to either seed hiera or create package resources automatically 
but I''m not sure if this
is a good idea or not.

What sort of solutions are people using to get round this?

Thanks for your help,
James

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/zLYnmQ-X5D4J.
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.

Hi James,


On 11.12.2012 05:41, James Gray wrote:
> Now, let''s imagine I need to spin up another server to meet some
load
> but when I do so I find that package y has had a security fix
> What sort of solutions are people using to get round this?
You''ll have to start managing versions. One way or the other. Client 
side there''s apt''s pinning, yum probably has some plugin to do
so.
Server side you can use a custom repo or puppet packages''s ensure =>
version.
> Another solution might be to have my own package repository
> containing just the packages I have tested against and only install
> from there but that means another bit of infrastructure to look after
> and manage, which I''d like to avoid if at all possible.
For any significant amount of machines and packages, you''ll really want
to look into hosting that repo yourself. That way you can

   * stage security and other updates
   * keep most control over package versions with the least
     per-node overhead
   * keep installs repeatable



Best Regards, David




-- 
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 11 December 2012 11:33, David Schmitt <david@dasz.at>
wrote:
>
> You''ll have to start managing versions. One way or the other.
Client side
> there''s apt''s pinning, yum probably has some plugin to do
so. Server side
> you can use a custom repo or puppet packages''s ensure =>
version.
I don''t think this is workable for the reasons I have described.
It''s
not realistic to list packages and versions of everything on my system
and keep them up to date etc.
> For any significant amount of machines and packages, you''ll really
want to
> look into hosting that repo yourself. That way you can
>
>   * stage security and other updates
>   * keep most control over package versions with the least
>     per-node overhead
>   * keep installs repeatable
Sure but the problem I have described is with even small
infrastructures where you don''t want to maintain anymore than you have
too. If you just have a web server and a database server, you don''t
want to setup a repository too just (and make sure it''s
monitored/always available/update to date) etc. It is also not clear
to me how you''d manage the process of pulling security fixes into your
repository from upstream.

I should say this is on EC2 and so another solution would be just to
use AMI''s I guess. Maybe building the AMI''s with Puppet.

Thanks,
James

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

To me it sounds like you need to make a design decision: Either you care
enough about these potential version differences to go through all the
trouble to manage them properly, or you don''t. Both are fine,
personally I
feel that the small chances that dependent packages have different versions
installed with one having more bugs then the other is so negligible that it
doesn''t warrant the time investment needed to manage all those
dependencies.

my 2 cents :)

Walter

On Tue, Dec 11, 2012 at 1:10 PM, James Gray
<james.gray@stillidream.org>wrote:
> On 11 December 2012 11:33, David Schmitt <david@dasz.at> wrote:
> >
> > You''ll have to start managing versions. One way or the other.
Client side
> > there''s apt''s pinning, yum probably has some plugin
to do so. Server side
> > you can use a custom repo or puppet packages''s ensure =>
version.
>
> I don''t think this is workable for the reasons I have described.
It''s
> not realistic to list packages and versions of everything on my system
> and keep them up to date etc.
>
> > For any significant amount of machines and packages, you''ll
really want
> to
> > look into hosting that repo yourself. That way you can
> >
> >   * stage security and other updates
> >   * keep most control over package versions with the least
> >     per-node overhead
> >   * keep installs repeatable
>
> Sure but the problem I have described is with even small
> infrastructures where you don''t want to maintain anymore than you
have
> too. If you just have a web server and a database server, you
don''t
> want to setup a repository too just (and make sure it''s
> monitored/always available/update to date) etc. It is also not clear
> to me how you''d manage the process of pulling security fixes into
your
> repository from upstream.
>
> I should say this is on EC2 and so another solution would be just to
> use AMI''s I guess. Maybe building the AMI''s with Puppet.
>
> Thanks,
> James
>
> --
> 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.
>
>

-- 
Walter Heck

--
Check out my startup: Puppet training and consulting @
http://www.olindata.com
Follow @olindata on Twitter and/or ''Like'' our Facebook page at
http://www.facebook.com/olindata

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

Op dinsdag 11 december 2012 05:41:40 UTC+1 schreef James Gray het volgende:
>
> What sort of solutions are people using to get round this?
>
> Thanks for your help,
> James
>
Honestly, we''re not really managing versions much. We deploy our EC2 
servers from the official Ubuntu 12.04 LTS AMI''s to avoid maintaining
our
own AMI''s. We bootstrap Puppet via cloud-config metadata (see
CloudInit),
to connect to our Master. The Master autosigns the nodes and configures 
them. Since Ubuntu''s stock AMI''s are used so often by EC2
customers a new
instance is booted very quickly. In general a new instance is started and 
fully configured within 7-10 minutes, which is fast enough for our 
auto-scaling demands.

Some important software-versions are set via Hiera 
(ensure=>''<someversion>''), but we try to avoid that
if at all possible. We
also try to avoid ensure=>''latest''.

These hosts are mostly public-facing webservers, so we automatically 
install security-updates via ''unattended-upgrades'' but
we''ve provided
exclusions for packages that are set via Hiera since we have to test those 
first. Non-security-updates are periodically evaluated and applied 
''manually'' via mcollective.

This may not be the best way to manage versions, but it works for us. In 
our experience Ubuntu''s maintainers generally provide reliable updates,
and
most web-applications are not that dependent on very specific versions so 
we let dpkg figure out the dependency hell. We''ve not had any issues in
the
9 months since we started using EC2 that we could blame on versions.

Of course upgrading to a newer Long Term Support release will take some 
serious testing, but so far this simple method seems to work and saves us a 
lot of time.

Regards, Martijn

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/BPp1C4NhWswJ.
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.