----- Original Message ----- > From: "jcbollinger" <john.bollin...@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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
