Puppet 2.7 v 3.0 in the PuppetLabs yum repo

[Robert Rothenberg]

I am using CentOS 6 with the PuppetLabs yum repo from http://yum.puppetlabs.com

I noticed that today version 3 is available on the repo, so of course, an upgrade to Puppet is available.

Ideally, it would have been better if v3 had a different distribution name, so that systems with v2.7.x are not upgraded (especially if there will be future releases if v2.7).

I am concerned about things breaking. So is there a document detailing incompatibilities? Will there be future 2.7 releases?

[Jeff McCune]

On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg <rob...@gmail.com> wrote:
> I am using CentOS 6 with the PuppetLabs yum repo from
> http://yum.puppetlabs.com
>
> I noticed that today version 3 is available on the repo, so of course, an
> upgrade to Puppet is available.

Yes, this major version update went live on Monday. There are a
number of breaking-changes between 2.7 and 3.0 which are described at:
http://links.puppetlabs.com/telly_breaking_changes

> Ideally, it would have been better if v3 had a different distribution name,
> so that systems with v2.7.x are not upgraded (especially if there will be
> future releases if v2.7).

Could you please file an issue (with impact data) about the
distribution name issue. I believe we considered doing what you
describe, but decided against it. I don't know the reasons off the
top of my head though, an issue will give us a clear place to track
the request, the impact it has on you and your organization, and the
decision we come to (or have already come to).

> I am concerned about things breaking. So is there a document detailing
> incompatibilities? Will there be future 2.7 releases?

There will be future releases of 2.7. We will continue to fix bugs in
the 2.7 series, but we are intending to avoid adding any new features
or make any large changes to the behavior of Puppet 2.7.

Hope this helps,
-Jeff

[Michael Stahnke]

On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune <je...@puppetlabs.com> wrote:
> On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg <rob...@gmail.com> wrote:
>> I am using CentOS 6 with the PuppetLabs yum repo from
>> http://yum.puppetlabs.com
>>
>> I noticed that today version 3 is available on the repo, so of course, an
>> upgrade to Puppet is available.
>
> Yes, this major version update went live on Monday. There are a
> number of breaking-changes between 2.7 and 3.0 which are described at:
> http://links.puppetlabs.com/telly_breaking_changes
>
>> Ideally, it would have been better if v3 had a different distribution name,
>> so that systems with v2.7.x are not upgraded (especially if there will be
>> future releases if v2.7).

We sent out several notices about this prior to doing it. The Puppet
Labs repositories are designed to be the place you get the latest
software from Puppet Labs. This was a conscious choice.

>
> Could you please file an issue (with impact data) about the
> distribution name issue. I believe we considered doing what you
> describe, but decided against it. I don't know the reasons off the
> top of my head though, an issue will give us a clear place to track
> the request, the impact it has on you and your organization, and the
> decision we come to (or have already come to).
>
>> I am concerned about things breaking. So is there a document detailing
>> incompatibilities? Will there be future 2.7 releases?

There will be. I'd imagine you'll see activity slow on it though.

>
> There will be future releases of 2.7. We will continue to fix bugs in
> the 2.7 series, but we are intending to avoid adding any new features
> or make any large changes to the behavior of Puppet 2.7.
>
> Hope this helps,
> -Jeff
>

> --
> You received this message because you are subscribed to the Google Groups "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
>

[Robert Rothenberg]

On Wednesday, October 3, 2012 1:36:22 AM UTC+1, Michael Stanhke wrote:

On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune <je...@puppetlabs.com> wrote:
> On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg <rob...@gmail.com> wrote:
>> I am using CentOS 6 with the PuppetLabs yum repo from
>> http://yum.puppetlabs.com
>>
>> I noticed that today version 3 is available on the repo, so of course, an
>> upgrade to Puppet is available.
>
> Yes, this major version update went live on Monday.  There are a
> number of breaking-changes between 2.7 and 3.0 which are described at:
> http://links.puppetlabs.com/telly_breaking_changes
>
>> Ideally, it would have been better if v3 had a different distribution name,
>> so that systems with v2.7.x are not upgraded (especially if there will be
>> future releases if v2.7).

We sent out several notices about this prior to doing it. The Puppet

Not everyone subscribes to notices or reads the mailing lists regularly.
 

Labs repositories are designed to be the place you get the latest
software from Puppet Labs.  This was a conscious choice.

Yes. And users would expect to receive things like security updates and bug fixes fairly quickly.

But a major upgrade than can break existing infrastructure should not have the same distribution name. It means that users who aren't ready to upgrade cannot use yum--- they will have to manually install updates to 2.7 because there will always be a newer v3 (unless you decide to create a separate distribution name for puppet 2.7, so that users can track that instead).
 
I maintain a network that uses a non-standard Puppet installation (where manifests are distributed using git hooks instead of using a Puppet master). So my concerns about a major upgrade are that much greater.

I should add that I work for a small company that chose Puppet because we don't want to use large amounts of our time with system administration. So releasing a major upgrade in this manner negates that reason.

>
> Could you please file an issue (with impact data) about the
> distribution name issue.  I believe we considered doing what you

Under what project should the issue be filed?
 

[Mister Guru]

I noticed this this morning as well, that some of my new cloud boxe installed puppet client 3, I'm also currently wondering if this is going to affect my new builds ... 

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

[jcbollinger]

I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series.  It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended.

The customary way to handle dual lines of packages is to give one line a different name, for example "puppet3-*" instead of plain "puppet-*".  Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being.  If that's the plan then the first "puppet2-*" packages should have been released at the same time that the mainline packages were updated to v 3.0.

Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases.

Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 will cause breakage for users.  PL, I urge you to reconsider.  Soon.


John

[Rilindo Foster]

I usually explicitly set the $puppetversion in my manifest for my environment. Furthermore, I have my own mirror copied from puppet labs repo and install it from that location instead. That way, I have control of what I push out and only update when I know that the new version is sound.

So I am not sure what the hubbub is all about. If you are not controlling what you push out, don't be surprised when something breaks.

 - RIlindo

On Oct 3, 2012, at 8:16 AM, jcbollinger <John.Bo...@stJude.org> wrote:

I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series.  It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended.

The customary way to handle dual lines of packages is to give one line a different name, for example "puppet3-*" instead of plain "puppet-*".  Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being.  If that's the plan then the first "puppet2-*" packages should have been released at the same time that the mainline packages were updated to v 3.0.

Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases.

Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 will cause breakage for users.  PL, I urge you to reconsider.  Soon.


John

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

[R.I.Pienaar]

----- Original Message -----
> From: "Rilindo Foster" <ril...@mac.com>
> To: puppet...@googlegroups.com
> Sent: Wednesday, October 3, 2012 3:02:58 PM
> Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo
>
> I usually explicitly set the $puppetversion in my manifest for my
> environment. Furthermore, I have my own mirror copied from puppet
> labs repo and install it from that location instead. That way, I
> have control of what I push out and only update when I know that the
> new version is sound.
>
> So I am not sure what the hubbub is all about. If you are not
> controlling what you push out, don't be surprised when something
> breaks.

+100, people seem to be expecting the rest of the world to maintain
a controlled environment simply because they don't?

Do you really trust a random third party as the source of your packages?

What if there is an outage at one of these 3rd party package providers
and you cannot build new machines? How do you explain that on the day
that you suddenly need to scale your infrastructure due to a critical
request or failure?

You have to build local repo mirrors and you have to be able to recover
from a disaster or simply provision new infrastructure based on your
own processes and systems you influence, if you do not you have bigger
problems than what version of Puppet is on some 3rd party repo.

[Mister Guru]

On 3 October 2012 15:02, Rilindo Foster <ril...@mac.com> wrote:

I usually explicitly set the $puppetversion in my manifest for my environment. Furthermore, I have my own mirror copied from puppet labs repo and install it from that location instead. That way, I have control of what I push out and only update when I know that the new version is sound.

So I am not sure what the hubbub is all about. If you are not controlling what you push out, don't be surprised when something breaks.

I'm partially pissed of with PL as well, and I'm really not liking the responses that say, "well you should manage the package versions you have installed"

To me, the point is here, that this is more of a case of BAD repo managment. It's NOT the same package, AND it doesn't have full 100% backward compatibility - So it's a DIFFERENT package - give it a new name. Also, those gloating that manage their packages using version numbers, and are not affected by this - YOU ARE NOT HELPING. The problem is HOW the package was pushed out, not the fact that it was pushed out.

Also, puppet v2 is also going to be available still - If it was me, I would have created a meta package called puppet, and 'linked' that puppet 2, and called puppet3, puppet 3. I'd also create a package called puppet2. And about 6 weeks after release, upgrade meta package puppet to puppet 3.   -- I'm just saying :)

 

 - RIlindo

On Oct 3, 2012, at 8:16 AM, jcbollinger <John.Bo...@stJude.org> wrote:

I am not directly affected by this issue, but I agree with those complaining that it was unwise, or at least inhospitable for PL to release Puppet 3 into its repositories in this way, especially considering that PL intends to continue with maintenance releases in the 2.7 series.  It is tantamount to a recommendation for all users to upgrade to the new line immediately, and considering the number of breaking changes, I cannot believe that that was intended.

The customary way to handle dual lines of packages is to give one line a different name, for example "puppet3-*" instead of plain "puppet-*".  Failing that, it is essential that the package name for the 2.7 series be changed, else the PL repository will be near-useless to people who want to stay at 2.7 for the time being.  If that's the plan then the first "puppet2-*" packages should have been released at the same time that the mainline packages were updated to v 3.0.

Alternatively, PL could set up a separate repository for the Puppet 2 maintenance releases.

Distinguishing the lines only by their version numbers simply isn't useful, and dropping v3 packages with their breaking changes into the same repository with v2 will cause breakage for users.  PL, I urge you to reconsider.  Soon.


John

Agreed + 101 (looks at RIP)

[Chad Huneycutt]

I agree that folks should manage their repos, but I wanted to throw in
a couple of thoughts:

* The package name hacks (eg puppet3) are usually done by
distributions to allow multiple versions of software to co-exist.

* Take a look at the yum versionlock plugin. My life has been much
simpler since I deployed it. For a while I was "exclude"ing puppet
and friends in yum.conf, but that was a real pain. The versionlock
plugin "pins" a package at the version you want, and then you can
update when ready.

- Chad

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

> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.

--
Chad M. Huneycutt

[Mister Guru]

On 3 October 2012 15:51, Chad Huneycutt <chad.hu...@gmail.com> wrote:

I agree that folks should manage their repos, but I wanted to throw in
a couple of thoughts:

* The package name hacks (eg puppet3) are usually done by
distributions to allow multiple versions of software to co-exist.

I think that we have the requirements for the package name hack, as in 2 separate package versions
 

* Take a look at the yum versionlock plugin.  My life has been much
simpler since I deployed it.  For a while I was "exclude"ing puppet
and friends in yum.conf, but that was a real pain.  The versionlock
plugin "pins" a package at the version  you want, and then you can
update when ready.

I will take a look at this plugin when I have a moment, thanks for the tip
 

[Throwe, Jesse]

It might be worth an enhancement request to have Package: ensure => version call yum versionlock or zypper add-lock if they are present

[Robert Rothenberg]

On Wednesday, October 3, 2012 3:51:28 PM UTC+1, Chad Huneycutt wrote:

I agree that folks should manage their repos, but I wanted to throw in
a couple of thoughts:

* The package name hacks (eg puppet3) are usually done by
distributions to allow multiple versions of software to co-exist.

No. The puppet2 and puppet3 packages can be marked as mutually exclusive.
 

* Take a look at the yum versionlock plugin.  My life has been much
simpler since I deployed it.  For a while I was "exclude"ing puppet
and friends in yum.conf, but that was a real pain.  The versionlock
plugin "pins" a package at the version  you want, and then you can
update when ready.

The problem I have is in deploying new VMs with Cobbler.  The versionlock plugin does not work for deploying new machines, and unfortunately, Cobbler's package exclusion doesn't work either.


 

[Robert Rothenberg]

BTW, I have reported this at https://projects.puppetlabs.com/issues/16729

[James Turnbull]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Rothenberg wrote:
> BTW, I have reported this at https://projects.puppetlabs.com/issues/16729
>

So taking my Puppet Labs hat off and speaking purely as a sysadmin ... I
guess I have some commentary on what I would consider best practice.

1. I never ensure => latest to a repo where I don't control the repo
content.
2. I always mirror the packages that are mission-critical to a local
repo where I can control the versions.
3. Where possible I manage versions by pinning not by relaying on the
multiple naming hacks distros use.

Regards

James

- --
Author of:
* Pro Puppet (http://tinyurl.com/ppuppet)
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQbF5/AAoJECFa/lDkFHAyTEQIAIZyCeLwt90Nh5wu/ynYLJkR
stMQM+SAXNwAsqWMXW1RHAOxa/GAtopJmMJKePduGT0m8adVbZp7qGcOlx3emNI2
FSWoW9dBCU5ncWj0aU/TxFUzbhfKzf89zzUu908SYMMqYCfNdgM2m5gAxGXCrjhT
wnu9K9Ls8Kv0LsawYylVuThaZmLVGhBH+DuSVmiGHir63h0sGDDazbxyHUMTlTMC
nBerxcEF6+2uxPuZgxQaSvon2ZpM7dkSjBOhZzI5S2WjOamnlxnjd7Hc/npe2xsI
wfKS40sq40pKifo35eDhwGp6svBPx/tyZUCC+Ukfxkyrrmn58eFQNTaPnsuB0SE=
=pnk6
-----END PGP SIGNATURE-----

[Jeff McCune]

On Wed, Oct 3, 2012 at 8:32 AM, Robert Rothenberg <rob...@gmail.com> wrote:
> BTW, I have reported this at https://projects.puppetlabs.com/issues/16729

Thank you for filing this ticket. We're having a hard time
understanding how many people were actually negatively affected by
this change. If you were affected by the backwards incompatible
release to the main package repositories, could you please update
ticket 16729 with any impact data you have and also vote up the
ticket?

The Puppet core team is currently using up-votes as a rough guide to
how many users are affected by particular issues.

Finally watching the ticket will help ensure you get up to date
information as it becomes available.

Thanks,
-Jeff McCune

[Jeffrey Watts]

+1

[Aaron Russo]

full disclosure: I don't use the puppetlabs repos. Below are just some observations and concerns I wanted to voice.

On Tue, Oct 2, 2012 at 5:36 PM, Michael Stahnke <sta...@puppetlabs.com> wrote:

On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune <je...@puppetlabs.com> wrote:
> On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg <rob...@gmail.com> wrote:
>> I am using CentOS 6 with the PuppetLabs yum repo from
>> http://yum.puppetlabs.com
>>
>> I noticed that today version 3 is available on the repo, so of course, an
>> upgrade to Puppet is available.
>
> Yes, this major version update went live on Monday.  There are a
> number of breaking-changes between 2.7 and 3.0 which are described at:
> http://links.puppetlabs.com/telly_breaking_changes
>
>> Ideally, it would have been better if v3 had a different distribution name,
>> so that systems with v2.7.x are not upgraded (especially if there will be
>> future releases if v2.7).

We sent out several notices about this prior to doing it. The Puppet
Labs repositories are designed to be the place you get the latest
software from Puppet Labs.  This was a conscious choice.

Where was this announced? On the list?  Not everyone who follows the official install instructions (http://docs.puppetlabs.com/guides/installation.html) is cool enough to join the mailing list :-P

The real problem, IMHO, is there is no clear policy regarding the PuppetLabs repo (or at least none I could find easily).  "These repos contain the latest available packages for Puppet, ..." is somewhat ambiguous (or maybe its just me) -- does that mean the latest of the current release or the latest version overall? We now know it's the latter.

To that affect, I think it would benefit the community if there was a clearly defined policy with respect to the repos, much like EPEL does (http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies).  The closest thing I found was (http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html), which I don't think is adequate to describe the intention of the repos.

Second-to-lastly, my biggest concern with this problem in its current state, is the potential fallout of users (and the people they influence) who now find puppet to be "too volatile" or "too unstable", and decide to look for alternatives.  I won't argue against that these users should have had better practices to prevent this, because it doesn't change the fact that these people are still put off.

Personally, I would have liked to see a separate repo for each version of puppet (so that users of 2.6.x, 2.7.x and 3.0.x could continue to receive the latest and greatest for their version).  But I also don't have to manage the thing, so I respect that it didn't turn out this way.  However, I think the method of communicating to the community can be improved to compensate.

And finally, thanks for all the work guys.  Puppet is a fantastic product, and has a fantastic community behind it.

Cheers,
Aaron Russo
 

[jcbollinger]

Of course it is ultimately my responsibility which versions of which packages get installed on my systems, from which repositories.  Of course it is in my best interest to ensure package availability if that's important to me.  Indeed, I do maintain local mirrors of the repositories I depend on.  All of that is beside the point.

Personally, I expect package repository managers to make a best effort at maintaining a managed environment because I perceive that as an implicit promise that repository management makes to clients by virtue of providing a public repository in the first place.  Whether that perception is reasonable is also not the point, but the fact that it seems to be shared by a a substantial number of users should certainly trigger an alarm at PL HQ.


John

[R.I.Pienaar]

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

> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
>

> maintaining a managed environment *because I perceive that as an
> implicit
> promise that repository management makes to clients* by virtue of

> providing
> a public repository in the first place. Whether that perception is
> reasonable is also not the point, but the fact that it seems to be
> shared
> by a a substantial number of users should certainly trigger an alarm
> at PL
> HQ.

It's indeed a concern don't get me wrong but I do not think playing
naming games isnt viable given the amount of product/releases/dependencies
etc especially when those products depend on each other. I think the
other poster in this thread hit the nail though - we should clearly
state the purpose and management practises related to the puppetlabs
repositories so users are better equipped to prepare themselves for
using our repos.

The link to the EPEL guides were good information

[R.I.Pienaar]

s/isnt/is

> product/releases/dependencies
> etc especially when those products depend on each other. I think the
> other poster in this thread hit the nail though - we should clearly
> state the purpose and management practises related to the puppetlabs
> repositories so users are better equipped to prepare themselves for
> using our repos.
>
> The link to the EPEL guides were good information
>

> --
> You received this message because you are subscribed to the Google
> Groups "Puppet Users" group.

[Sandra Schlichting]

Hi Chad

* Take a look at the yum versionlock plugin.  My life has been much
simpler since I deployed it.  For a while I was "exclude"ing puppet
and friends in yum.conf, but that was a real pain.  The versionlock
plugin "pins" a package at the version  you want, and then you can
update when ready.

When I do that I get

# yum versionlock add puppet-server-2.7\* puppet-2.7\*

# yum versionlock list

Loaded plugins: fastestmirror, security, versionlock

0:puppet-server-2.7.19-1.el6.*

0:puppet-2.7.19-1.el6.*

versionlock list done

which I suppose will lock it to 2.7.19 and never to 2.7.20.

Is it possible to lock it to 2.7.x ?

[Jakov Sosic]

On 10/03/2012 08:38 PM, Aaron Russo wrote:

> Personally, I would have liked to see a separate repo for each version
> of puppet (so that users of 2.6.x, 2.7.x and 3.0.x could continue to
> receive the latest and greatest for their version). But I also don't
> have to manage the thing, so I respect that it didn't turn out this
> way. However, I think the method of communicating to the community can
> be improved to compensate.

Yeah, this would be the best solution, to have different repositories
for different subversions.

I don't like the "naming" solution where puppet packages are named
puppet2 or puppet3...


--
Jakov Sosic
www.srce.unizg.hr

[devzero2000]

Well, in many enterprise distro having different name and, possibly,
no conflicting path for a complex package is a common option. In
rhel5 for example exists samba package for samba 3.0.x and samba3x for
samba 3.x , and samba it is often a critical package and the change
between different versión are many and important. I believe that it is
true also for puppet, and i think that should be a sysadmin's choice
to upgrade to a new major version. And not everyone is so expert in
dealing with yum repository, or apt fwiw.

Best

2012/10/7, Jakov Sosic <jso...@srce.hr>:

> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet...@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

--

Inviato dal mio dispositivo mobile

[Jakov Sosic]

On 10/07/2012 07:30 PM, devzero2000 wrote:
> Well, in many enterprise distro having different name and, possibly,
> no conflicting path for a complex package is a common option. In
> rhel5 for example exists samba package for samba 3.0.x and samba3x for
> samba 3.x , and samba it is often a critical package and the change

> between different versi�n are many and important. I believe that it is

> true also for puppet, and i think that should be a sysadmin's choice
> to upgrade to a new major version. And not everyone is so expert in
> dealing with yum repository, or apt fwiw.

I know for that practice, but the problem is that it makes upgrade from
samba to samba3x packages a problem. So I would rather avoid that with
the puppet. And if you know how to add puppetlabs repo to yum, then
you'll know how to choose what version repo to use. Just take a look at
postgresql repositories.


--
Jakov Sosic
www.srce.unizg.hr

[Sandra Schlichting]

I know for that practice, but the problem is that it makes upgrade from
samba to samba3x packages a problem. So I would rather avoid that with
the puppet. And if you know how to add puppetlabs repo to yum, then
you'll know how to choose what version repo to use. Just take a look at
postgresql repositories.

I would very much like how to do that, as it seams to me that "yum versionlock" locks the current installed package from being upgraded, which is not really what we want =)

We want that puppet-2.7.* and puppet-server-2.7.* can be upgraded.

 

[Jakov Sosic]

Currently the only way I know is to make your own repositories... We
we're chatting about what policy should puppetlabs adopt, and not how to
solve the current problem.

Currently the only way is to go with ensure => present + versionlock,
and to manually change the lock when new version is out :(




--
Jakov Sosic
www.srce.unizg.hr

[Jeff McCune]

On Wed, Oct 3, 2012 at 8:32 AM, Robert Rothenberg <rob...@gmail.com> wrote:

> BTW, I have reported this at https://projects.puppetlabs.com/issues/16729

I'm not sure if everyone here is subscribed to issue #16729, so I'd
like to take a moment to cross-post the update I posted there. I hope
this information is helpful.

Robert,

Thank you for taking the time to report this issue. I'm one of the
developers responsible for Puppet and Facter. My highest priority is
to make sure you, and all Puppet users, have a delightful experience.
I spent quite a bit of time reviewing the problem you've described,
and I've identified at least one viable solution to this problem.
We're still not exactly sure what we're going to do to resolve this
issue, but I'd like to take a moment and assure you of the following
things:

First, we acknowledge and accept that this is an flaw with the way
Puppet is delivered. We made a mistake with the 3.0.0 release and
this mistake causes some users to unwillingly install a version of
Puppet incompatible with their existing infrastructure. Specifically,
we acknowledge that our users must knowingly decide to install any
version of Puppet that we (Puppet Labs) knows to be incompatible with
previous releases. With the move to semantic version numbers as of
3.0.0, this means that future major versions of Puppet, e.g. 4.x, will
require some "opt-in" action on your behalf.

Second, If a minor version or patch version is found to be
incompatible with previous versions, we consider this to be a bug with
Puppet and we'll work as quickly as possible to release a subsequent
version to fix this incompatibility. This un-intentional backwards
incompatibility will happen from time to time, we're constantly
working to improve our existing QA and CI tools, but please rest
assured you should trust us not to knowingly release backwards
incompatible software that you might unknowingly install.

Finally, we acknowledge that using `ensure => latest` inside of
Puppet, or doing the equivalent of `yum install puppet` in kickstart,
scripts, or cobbler doesn't qualify as knowingly deciding to upgrade
across incompatible versions. Not everyone reads the documentation or
our announcements, and not everyone is an expert in apt and yum. This
acknowledgement applies for any system we support that has online
repositories such as APT and IPS. Furthermore, there is quite a bit
of documentation [1] [2] [3] that indicates this is a problem with our
design.

We're still not quite sure what we're going to do to resolve this
issue, but we do acknowledge and accept the issue as valid and we take
responsibility for resolving it.

I hope this helps and thank you again for reporting this issue,
-Jeff McCune

[1] http://infodesign.com.au/articles/themythofthestupiduser/
[2] http://swizec.com/blog/stupid-users-are-a-myth/swizec/449
[3] http://www.amazon.com/Design-Everyday-Things-Donald-Norman/dp/0465067107
(page 128)

[Jeff McCune]

On Mon, Oct 8, 2012 at 12:21 PM, Jeff McCune <je...@puppetlabs.com> wrote:
>
> Finally, we acknowledge that using `ensure => latest` inside of
> Puppet, or doing the equivalent of `yum install puppet` in kickstart,
> scripts, or cobbler doesn't qualify as knowingly deciding to upgrade
> across incompatible versions. Not everyone reads the documentation or
> our announcements, and not everyone is an expert in apt and yum. This
> acknowledgement applies for any system we support that has online
> repositories such as APT and IPS. Furthermore, there is quite a bit
> of documentation [1] [2] [3] that indicates this is a problem with our
> design.

I'd like to amend the paragraph above because I prematurely spoke for
Puppet Labs and more importantly our release engineering team who is
responsible for our repositories. This paragraph is too prescriptive
of the solution domain; the more general design principle we're
subjecting ourselves to can be summed up as, "stupid users are a myth"
and a good litmus test we are applying to this issue is; "If you're
using our repositories, Puppet runs successfully 10 times in a row,
and on the 11th run Puppet is broken," then that's a design issue
we'll work to correct.

-Jeff

[Jakov Sosic]

On 10/08/2012 09:21 PM, Jeff McCune wrote:

> I hope this helps and thank you again for reporting this issue,

I think the easiest way of handling this issue is to have different
repositories for different versions of puppet.

So for example yum/rhel-compatible distros would have

* 'puppet26-release-6-6'
for puppet 2.6

* 'puppet27-release-6-6'
for puppet 2.7

* 'puppet30-release-6-6'
for puppet 3.0

That way, user can add for example repo 27 and not worry about it. When
one decides to upgrade, it can simply replace puppet27-release with
puppet30-release, which would provide newer version of packages (with
the same name) which offers seamless upgrade to latest and greatest.


I surely would not like to see all versions of puppet in same repository
but with different names (like puppet26, puppet27, puppet30), cause
that's not the purpose of version-in-the-name naming scheme - and it
makes upgrades impossible. One would have to remove old version first
and then install new version, and I surely would not want to do that on
hundreds of machines :(


--
Jakov Sosic
www.srce.unizg.hr

[Gonzalo Servat]

On Sun, Oct 14, 2012 at 11:27 AM, Jakov Sosic <jso...@srce.hr> wrote:

On 10/08/2012 09:21 PM, Jeff McCune wrote:

I hope this helps and thank you again for reporting this issue,

I think the easiest way of handling this issue is to have different repositories for different versions of puppet.

I would certainly +1 this method! I was bitten by the puppet 3.x packages for 2 reasons. The first one is that in my kickstart configs, I have "puppet" specified as a package which gets installed during installation and performs some trickery to run Puppet for the first time on the client, and get the certificate signed. As Puppet 3.x was now being installed by yum, it broke our installations. My workaround was to set "puppet-2.7" in the kickstart file, but far from ideal :(

I was then bitten by Puppet doing what it's supposed to do :) As I had ensure => latest for the Puppet client, it went around and upgraded a lot of my clients to 3.x, which broke things. I guess I never expected such incompatible packages to be made available in the puppetlabs yum repo, but there's always a first :)

It looks like Puppetlabs are well aware of this issue, so I look forward to the resolution. Personally, I think packages should be grouped in a logical manner, so that any package in the group will not (or should not) break functionality if upgraded.

- Gonzalo

[Jakov Sosic]

On 10/14/2012 08:40 AM, Gonzalo Servat wrote:

> I would certainly +1 this method! I was bitten by the puppet 3.x
> packages for 2 reasons. The first one is that in my kickstart configs, I
> have "puppet" specified as a package which gets installed during
> installation and performs some trickery to run Puppet for the first time
> on the client, and get the certificate signed. As Puppet 3.x was now
> being installed by yum, it broke our installations. My workaround was to
> set "puppet-2.7" in the kickstart file, but far from ideal :(

Yeah, same thing here. So we decided to upgrade instead of changing
kickstarts...

> It looks like Puppetlabs are well aware of this issue, so I look forward
> to the resolution. Personally, I think packages should be grouped in a
> logical manner, so that any package in the group will not (or should
> not) break functionality if upgraded.

But as I've said already, multiple versions in the same repo would
enable that behaviour, but would bring another set of problems. So I
still urge puppetlabs to consider 'repository per version' kind of solution.



--
Jakov Sosic
www.srce.unizg.hr

[Michael Stahnke]

I'm trying to close the loop on this thread.

We recognize that some users were negatively impacted by having Puppet
3.0.0 in the same repositories as the previously released versions.
While we attempted to communicate our intentions to release that way
by design, not everybody saw those communications.

As a result, prior to releasing the next set of software that has
breaking changes, we will certainly reevaluate our distribution
strategies.

Completed:
* The upgrade guide has been updated to mention software
pinning/freezing etc: http://docs.puppetlabs.com/guides/upgrading.html
* We have filed an enhancement request to allow range pinning in
puppet itself. http://projects.puppetlabs.com/issues/17102 If this
is interesting to you, please watch, upvote and/or submit patches for
this.

Commitments:
* Puppet Labs Software Delivery org will be publishing policies around
our repositories
* We will do more communication around breaking changes landing in our
repositories, and evaluate needs to address breakage on a case-by-case
basis.


Comments:
* We've had over 90,000 downloads of Puppet 3 from our repositories
(not counting Mac, Windows, Solaris, or rubygems.org). We've had
concerns voiced by less than 15 people total. I realize this doesn't
mean everybody who had issues reported anything to us.


The idea of separate repositories has been brought up, and debated
heavily internally. We currently have over 500 package repository
targets based on versions, architectures and repo-streams (devel,
deps, products) etc. Branching for each major product (puppet,
puppetdb, mcollective) is multiplicative and would result in many,
many more each time we branch. This could easily cause confusion
about which repositories to enable, disable, use for migrations from
one version to the next etc.

While we haven't ruled out this approach in the future, it requires
quite a lot of build toolchain and automation changes. It's likely as
a user you would get more value from Puppet Labs spending their
efforts elsewhere.

[Jakov Sosic]

On 11/01/2012 10:44 PM, Michael Stahnke wrote:
> While we haven't ruled out this approach in the future, it requires
> quite a lot of build toolchain and automation changes. It's likely as
> a user you would get more value from Puppet Labs spending their
> efforts elsewhere.

Maybe you could take a look at a way PostgreSQL does it? It has separate
repositories for major versions, and they are going on just fine.



--
Jakov Sosic
www.srce.unizg.hr

[jcbollinger]

On Thursday, November 1, 2012 4:44:46 PM UTC-5, Michael Stanhke wrote:

I'm trying to close the loop on this thread.

I appreciate that.

 

Completed:
* The upgrade guide has been updated to mention software
pinning/freezing etc: http://docs.puppetlabs.com/guides/upgrading.html
* We have filed an enhancement request to allow range pinning in
puppet itself.  http://projects.puppetlabs.com/issues/17102  If this
is interesting to you, please watch, upvote and/or submit patches for
this.

Those are good things, but they don't really address the core issue as far as I'm concerned.

 

Commitments:
* Puppet Labs Software Delivery org will be publishing policies around
our repositories
* We will do more communication around breaking changes landing in our
repositories, and evaluate needs to address breakage on a case-by-case
basis.

Again, those are good things, but not directly responsive to the problem.

 

Comments:
* We've had over 90,000 downloads of Puppet 3 from our repositories
(not counting Mac, Windows, Solaris, or rubygems.org).  We've had
concerns voiced by less than 15 people total.  I realize this doesn't
mean everybody who had issues reported anything to us.

It is reasonable to attempt to gauge the scope and impact of the issue as part of your decision process for how to address it, but the number of people voicing concerns to PL about the issue is a really poor statistic for that purpose.  It may indeed be that the issue is insignificant, but I don't appreciate that implication being made on such an unsound basis.

 

The idea of separate repositories has been brought up, and debated
heavily internally. We currently have over 500 package repository
targets based on versions, architectures and repo-streams (devel,
deps, products) etc. Branching for each major product (puppet,
puppetdb, mcollective) is multiplicative and would result in many,
many more each time we branch.

That's a larger technical challenge than I appreciated, but it still isn't responsive to the issue.

 

 This could easily cause confusion
about which repositories to enable, disable, use for migrations from
one version to the next etc.

That problem is (or should be) addressed by all the revised and augmented documentation described.  It's a different issue than the one I thought we were discussing, however, which was about people who did not intend or want to migrate at all.  No amount of upgrade / migration documentation is useful to people who weren't looking to upgrade in the first place.

 

While we haven't ruled out this approach in the future, it requires
quite a lot of build toolchain and automation changes. It's likely as
a user you would get more value from Puppet Labs spending their
efforts elsewhere.

I'll have to take your word on that, though I find it surprising.  Multiplicative changes such as that tend to be cheap on the development side.  It's normally the resulting resource requirements (disk space, number of virtual web hosts, etc.) that are at risk of being large.

What I'm hearing is that it is a challenging problem to address in the way that I would consider right, and that although PL sees some benefits to doing it that way, it is not convinced that doing so would be an overall win.  Inasmuch as I am unlikely to raise any new points that have not already been covered above or in PL's internal discussions on the subject, I will stop here.  I can only say that I am disappointed.


John