Puppet users - Oct 2012 - Puppet 2.7 v 3.0 in the PuppetLabs yum repo

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?



-- 
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.
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 Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg <robrwo@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

-- 
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 Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune <jeff@puppetlabs.com>
wrote:
> On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg <robrwo@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-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.
>
-- 
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 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<javascript:>>
> wrote: 
> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg
<rob...@gmail.com<javascript:>>
> 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?
 
> > 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<javascript:>.
>
> > To unsubscribe from this group, send email to 
> puppet-users...@googlegroups.com <javascript:>. 
> > For more options, visit this group at 
> http://groups.google.com/group/puppet-users?hl=en. 
> > 
>
-- 
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/-/XKCXN15MfqMJ.
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 2 Oct 2012, at 21:17, Robert Rothenberg 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.
> 
> 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?
> 
> 
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.
> 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.
-- 
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 Tuesday, October 2, 2012 7:36:22 PM UTC-5, Michael Stanhke
wrote:
>
> On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune
<je...@puppetlabs.com<javascript:>>
> wrote: 
> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg
<rob...@gmail.com<javascript:>>
> 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. 
>
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.
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.

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

----- Original Message -----
> From: "Rilindo Foster" <rilindo@mac.com>
> To: puppet-users@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.

-- 
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 3 October 2012 15:02, Rilindo Foster <rilindo@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.Bollinger@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)
-- 
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.

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

On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger <John.Bollinger@stjude.org>
wrote:
>
>
> On Tuesday, October 2, 2012 7:36:22 PM UTC-5, 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
>> 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.
>
>
> 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.
>
> 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.


-- 
Chad M. Huneycutt

-- 
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 3 October 2012 15:51, Chad Huneycutt <chad.huneycutt@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

>
> - Chad
>
> On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger
<John.Bollinger@stjude.org>
> wrote:
> >
> >
> > On Tuesday, October 2, 2012 7:36:22 PM UTC-5, 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
> >> 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.
> >
> >
> > 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.
> >
> > 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.
>
>
>
> --
> Chad M. Huneycutt
>
> --
> 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.
>
>
-- 
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.

It might be worth an enhancement request to have Package: ensure => version
call yum versionlock or zypper add-lock if they are present
On Oct 3, 2012 10:55 AM, "Mister Guru" <misteritguru@gmail.com>
wrote:
>
>
> On 3 October 2012 15:51, Chad Huneycutt <chad.huneycutt@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
>
>
>>
>> - Chad
>>
>> On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger
<John.Bollinger@stjude.org>
>> wrote:
>> >
>> >
>> > On Tuesday, October 2, 2012 7:36:22 PM UTC-5, 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
>> >> 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.
>> >
>> >
>> > 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.
>> >
>> > 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.
>>
>>
>>
>> --
>> Chad M. Huneycutt
>>
>> --
>> 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.
>>
>>
>  --
> 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.
>
-- 
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 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.


 
> - Chad 
>
> On Wed, Oct 3, 2012 at 9:16 AM, jcbollinger
<John.Bo...@stjude.org<javascript:>>
> wrote: 
> > 
> > 
> > On Tuesday, October 2, 2012 7:36:22 PM UTC-5, 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
> >> 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. 
> > 
> > 
> > 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. 
> > 
> > To post to this group, send email to
puppet...@googlegroups.com<javascript:>.
>
> > To unsubscribe from this group, send email to 
> > puppet-users...@googlegroups.com <javascript:>. 
> > For more options, visit this group at 
> > http://groups.google.com/group/puppet-users?hl=en. 
>
>
>
> -- 
> Chad M. Huneycutt 
>
-- 
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/-/ohWv88bzTbYJ.
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.

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

-- 
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/-/0mmf1DmfyDIJ.
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.

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

-- 
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 Wed, Oct 3, 2012 at 8:32 AM, Robert Rothenberg <robrwo@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

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

+1

On Wed, Oct 3, 2012 at 9:02 AM, Rilindo Foster <rilindo@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.
>
-- 
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.

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
<stahnma@puppetlabs.com>wrote:
> On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune <jeff@puppetlabs.com>
wrote:
> > On Tue, Oct 2, 2012 at 1:17 PM, Robert Rothenberg
<robrwo@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

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

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 ?





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

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

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 <jsosic@srce.hr>:
> 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
>
> --
> 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.
>
>
-- 
Inviato dal mio dispositivo mobile

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

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

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


 

-- 
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/-/R5rn3iiiobMJ.
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 10/07/2012 11:28 PM, Sandra Schlichting wrote:
>
>     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.
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

-- 
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 Wed, Oct 3, 2012 at 8:32 AM, Robert Rothenberg <robrwo@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)

-- 
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 Mon, Oct 8, 2012 at 12:21 PM, Jeff McCune <jeff@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

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

-- 
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 Sun, Oct 14, 2012 at 11:27 AM, Jakov Sosic <jsosic@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

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

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

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.

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

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

-- 
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/-/1iKmgqa_m7gJ.
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.