On Sep 22, 2010, at 14:06 , Leslie Giles wrote: > I'm working on rolling out Puppet, but I'm stuck and I know somebody has > solved this problem... > > We have an engineering environment of around 200 Centos servers, plus a > production environment of roughly the same size. Currently, when we roll out > a new server, we do a 'yum update' so the new server has the latest packages; > however this means that just about every server has a different set of > package versions - a system rolled out today will have different versions > from one rolled out last month, and that will have different versions from > one rolled out last year.
This might be a bit OT on this list but.... Usually operating system vendors do stable releases for that purpose. They invest a lot of effort to provide a stable version of a certain set of packages. Once released, they tend to not update software versions, except for updates which will fix security patches. So really, if you need a stable environment, use the stable version of your distribution and DO make security updates. Doing so never caused any harm to my systems. The next thing is that you have to somehow migrate your systems from stable release to stable release. Thats where puppet comes into play. You simply apply your manifests on the distribution's new release, and test the major service provided by the server. > This has bitten me in the past, where a feature developed on a recent system > failed to run on an older server, so I'm looking for a solution. I am in the > middle of rolling out Puppet, and we have private mirrors of the yum repos, > so a solution could build on these. > I can see several possible solutions: > - manage changes to the yum repos, and use puppet to make sure that every > server is up to date w.r.t. the yum repo. However this makes it difficult to > roll out changes in a controlled way,or to rollback changes. Same here, there shouldn't be any issues with updates as long as you don't upgrade a system from one major distribution release to the next. If a security update causes any harm to your application, you should fix it too. > - use puppet to list all package versions, and manage the versions explicitly > in puppet, however this means that puppet is going to have hundreds of > entries, and I can imagine a situation where I upgrade one package in puppet > without realizing that it depends on a newer version of another package, thus > puppet and yum start fighting about which version of the other package should > be installed. Specifying each installed package's version manually in your puppet manifest doesn't sound like a wise idea to me. > - always make sure that all systems are updated to the latest, which means a > slightly less stable environment, but avoids incompatibilities between > systems, and particularly the possibility that a feature developed on a newer > system will be asked to run on an older system. I think you should invest some work to provide an environment to your developers which better fits your production environment. If they use applications or libraries provided by your operating system, they need to make sure, that as soon as you upgrade your system, their code is still in a workable state. If they don't want to do that, either you or them needs to ship their application bundled with the appropriate set of libraries, so you decouple your application release cycles from your distribution's one. Regards, Stefan. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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.
