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

Search Discussions

  • Jeff McCune at Oct 2, 2012 at 8:31 pm

    On Tue, Oct 2, 2012 at 1:17 PM, 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.
    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.
  • Michael Stahnke at Oct 3, 2012 at 12:42 am

    On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune wrote:
    On Tue, Oct 2, 2012 at 1:17 PM, 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.
    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.
  • Robert Rothenberg at Oct 3, 2012 at 9:05 am

    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 wrote:
    On Tue, Oct 2, 2012 at 1:17 PM, 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.
    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.
  • Jcbollinger at Oct 3, 2012 at 1:16 pm

    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 wrote:
    On Tue, Oct 2, 2012 at 1:17 PM, 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.
    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.
  • Rilindo Foster at Oct 3, 2012 at 2:03 pm
    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 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.
  • R.I.Pienaar at Oct 3, 2012 at 2:23 pm

    ----- 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.
  • Jcbollinger at Oct 3, 2012 at 7:20 pm

    On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote:

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

    --
    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-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.
  • R.I.Pienaar at Oct 3, 2012 at 7:26 pm

    ----- Original Message -----
    From: "jcbollinger" <john.bollinger@stjude.org>
    To: puppet-users@googlegroups.com
    Sent: Wednesday, October 3, 2012 8:20:38 PM
    Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo



    On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote:


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


    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



    --
    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-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 9:24:01 AM UTC-5, R.I. Pienaar wrote:


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

    --
    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.
  • R.I.Pienaar at Oct 3, 2012 at 7:29 pm

    ----- Original Message -----
    From: "R.I.Pienaar" <rip@devco.net>
    To: puppet-users@googlegroups.com
    Sent: Wednesday, October 3, 2012 8:25:52 PM
    Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum repo


    ----- Original Message -----
    From: "jcbollinger" <john.bollinger@stjude.org>
    To: puppet-users@googlegroups.com
    Sent: Wednesday, October 3, 2012 8:20:38 PM
    Subject: Re: [Puppet Users] Puppet 2.7 v 3.0 in the PuppetLabs yum
    repo



    On Wednesday, October 3, 2012 9:24:01 AM UTC-5, R.I. Pienaar wrote:


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


    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



    --
    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-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 9:24:01 AM UTC-5, R.I. Pienaar wrote:


    ----- Original Message -----
    From: "Rilindo Foster" <ril...@mac.com <javascript:>>
    To: puppet...@googlegroups.com <javascript:>
    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.
    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.
    It's indeed a concern don't get me wrong but I do not think playing
    naming games isnt viable given the amount of 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.
    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.
  • Mister Guru at Oct 3, 2012 at 2:34 pm

    On 3 October 2012 15:02, Rilindo Foster 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 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.
  • Jeffrey Watts at Oct 3, 2012 at 5:09 pm
    +1
    On Wed, Oct 3, 2012 at 9:02 AM, Rilindo Foster 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.
  • Chad Huneycutt at Oct 3, 2012 at 2:51 pm
    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 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 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.
  • Mister Guru at Oct 3, 2012 at 2:55 pm

    On 3 October 2012 15:51, 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.
    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 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 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.
  • Throwe, Jesse at Oct 3, 2012 at 3:06 pm
    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" wrote:


    On 3 October 2012 15:51, 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.
    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.
  • Robert Rothenberg at Oct 3, 2012 at 3:38 pm

    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 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 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.
  • Sandra Schlichting at Oct 5, 2012 at 9:15 am
    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.
  • Aaron Russo at Oct 3, 2012 at 6:38 pm
    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 wrote:
    On Tue, Oct 2, 2012 at 1:30 PM, Jeff McCune wrote:
    On Tue, Oct 2, 2012 at 1:17 PM, 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.
    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.
  • Jakov Sosic at Oct 7, 2012 at 1:33 pm

    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.
  • Devzero2000 at Oct 7, 2012 at 5:31 pm
    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.
  • Jakov Sosic at Oct 7, 2012 at 8:17 pm

    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.
  • Sandra Schlichting at Oct 7, 2012 at 9:28 pm

    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.
  • Jakov Sosic at Oct 8, 2012 at 10:06 am

    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.
  • Mister Guru at Oct 3, 2012 at 9:43 am

    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.
  • Robert Rothenberg at Oct 3, 2012 at 3:32 pm
    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.
  • James Turnbull at Oct 3, 2012 at 3:49 pm

    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)



    --
    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.
  • Jeff McCune at Oct 3, 2012 at 4:39 pm

    On Wed, Oct 3, 2012 at 8:32 AM, Robert Rothenberg 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.
  • Jeff McCune at Oct 8, 2012 at 9:01 pm

    On Wed, Oct 3, 2012 at 8:32 AM, Robert Rothenberg 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.
  • Jeff McCune at Oct 9, 2012 at 7:19 pm

    On Mon, Oct 8, 2012 at 12:21 PM, Jeff McCune 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.
  • Jakov Sosic at Oct 14, 2012 at 12:27 am

    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.
  • Gonzalo Servat at Oct 14, 2012 at 6:40 am

    On Sun, Oct 14, 2012 at 11:27 AM, Jakov Sosic 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.
  • Jakov Sosic at Oct 14, 2012 at 8:17 am

    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.
  • Michael Stahnke at Nov 1, 2012 at 9:44 pm
    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.
  • Jakov Sosic at Nov 2, 2012 at 1:35 am

    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.
  • Jcbollinger at Nov 2, 2012 at 1:49 pm

    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.

Related Discussions

People

Translate

site design / logo © 2022 Grokbase