--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/6FF107F6-088A-43E2-BECF-772D8C153C49%40puppet.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAE%2BtgeMKENaAjphZ1SX0dPin0pXJZaR%2B8d%3DEMXvC6cX-NpZsqQ%40mail.gmail.com.
Hi all - we're nearing the end of the Puppet 4.x series feature development. It's been almost two years since Puppet 4.0 dropped and it seems like an opportune time to start thinking about the next semver major.There was some discussion last year[0], but the development work is truly rolling forward now, so I wanted to restart the conversation about Puppet 5 to elicit feedback and make sure to incorporate the community's needs into the plan.The headline here is that the core open-source "Puppet Platform" (puppet-agent, puppet-server, puppetdb) are moving to a more coordinated release model, with compatibility guarantees and consistent versioning among the components. The first release of this "Puppet Platform 5", currently targeted at May, will bring these components' major versions together and provide some nice features without a huge backwards-incompatible break.A couple of FAQs, or rather questions I imagine will be frequently asked:Q: Puppet 5, what the hell eric0?! I just spent a month updating my code to run under Puppet 4.A: No Puppet code that works under Puppet 4 needs changing[1] to work under 5. This is a semver major to release some backwards-incompatible changes that have stacked up, plus some additional feature work, but does not affect the language. Puppet 4 won't be EOL any time soon (and we're guaranteeing commercial customer support until 2018) but we've got to keep the platform moving forward. Plus, it seems like a good opportunity to eliminate the confusion caused by "Puppet 4" being delivered in packages, split between puppet-agent-1.x and puppet-server-2.x ....Q: So what *is* in it? Why should I upgrade?A: Lots of good stuff. Hiera 5 with eyaml is built-in; it's UTF-8 clean; network comms are pure, sweet, fast JSON.
Our current Ruby versions are EOL'ed, so we're moving to MRI Ruby 2.4 on the agent and jruby9k on the server. The PE-only puppet-server metrics service is getting some enhancements and will be open-sourced.Q: How's it going to be delivered? Are Puppet Collections still a thing?A: Funny you should ask. As we kicked around a couple of months ago[3], it's been two years and the collections idea just hasn't worked out in practice, so it seems wise to iterate and keep evolving. The current plan is to create a new repo, parallel with the existing PC1 repos, simply named 'puppet'. The platform components will roll into it and future semver-majors will be coordinated across the components, hopefully leading to smaller, easily digestible chunks of change.You can see the complete list of changes (which will evolve as we gather feedback and adjust scope) at this JIRA query[2]. If there's anything on the roster that looks like it'll break your world — or, conversely, if you want to nominate a change that's important to you but isn't currently on the list — this thread is the place to do that.--eric0[1] I'm reserving a tiny, tiny asterisk for some Ruby extensions that use internal APIs that may change, like pre-Puppet 4.9 lookup extensions.Eric Sorenson - eric.s...@puppet.com
director of product, ecosystem and platform
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/6FF107F6-088A-43E2-BECF-772D8C153C49%40puppet.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAC76iT8PquryseW873Sx2Q9URq4bdmCA3oX1FnMxKU6-%3D7Esjg%40mail.gmail.com.
Well, that was the whole collections idea in a nutshell, but every one of those new repos would inevitably leave some people stranded on an old one. Terrifyingly, there are still something like 100,000 hosts[1] hitting the EOL'ed 3.x repos, which will never get any updates... there's no clearly great answer here but optimizing to protect people who have 'ensure => latest' against upstream repos doesn't seem like the right thing.
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/070d678d-68eb-4147-913e-d453f6c411ff%40googlegroups.com.
+1 for just removing old repos.I would do something like CentOS where you have an archive or 'unsupported' space for people that simply can't upgrade for whatever reason.yum.puppetlabs.com/unsupported for the RPM users, for example.Trevor
On Mon, Mar 27, 2017 at 9:12 AM, John Bollinger <John.Bo...@stjude.org> wrote:
On Friday, March 24, 2017 at 5:09:31 PM UTC-5, Eric Sorenson wrote:Well, that was the whole collections idea in a nutshell, but every one of those new repos would inevitably leave some people stranded on an old one. Terrifyingly, there are still something like 100,000 hosts[1] hitting the EOL'ed 3.x repos, which will never get any updates... there's no clearly great answer here but optimizing to protect people who have 'ensure => latest' against upstream repos doesn't seem like the right thing.We've had this discussion before. Nevertheless, I submit that the proposition is not to "optimize" for people who rely on the upstream repos, but rather to faithfully fulfill the responsibilities that many people presume you undertake by providing software repos in the first place. In this case that also carries the benefit of avoiding torpedoing some 100K or so Puppet installations, and regardless of technical considerations, I question the wisdom of such a move on business and community relations grounds.
If you don't want to maintain repos for the EOL software versions (which is reasonable), then it would be much better to simply remove those repos than to drop incompatible package versions into them.
John
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/070d678d-68eb-4147-913e-d453f6c411ff%40googlegroups.com.
--Trevor Vaughan
Vice President, Onyx Point, Inc
-- This account not approved for unencrypted proprietary information --
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUTk6FrGRWtthFJK9doATAmNdLoisHUrMh7eh-6kzHTmg%40mail.gmail.com.
Doing like debian with both named releases like squeeze and jessie etc, but also repositories like stable would be a nice option. That way users can just choose if they only want to stick to puppet 4.x packages in the repo or if they prefer to use package pinning instead and have the repo contain all packages.I would assume the majority of users pin their package versions, so the current solution where you need to both start mirroring a new repo, switch your hosts to use that and update the pinning is a bit of a hassle with no benefits compared to just updating the pinning which was the case before the PC1 repo.
On Tue, 28 Mar 2017 at 13:31 Trevor Vaughan <tvau...@onyxpoint.com> wrote:
+1 for just removing old repos.I would do something like CentOS where you have an archive or 'unsupported' space for people that simply can't upgrade for whatever reason.yum.puppetlabs.com/unsupported for the RPM users, for example.Trevor
On Mon, Mar 27, 2017 at 9:12 AM, John Bollinger <John.Bo...@stjude.org> wrote:
On Friday, March 24, 2017 at 5:09:31 PM UTC-5, Eric Sorenson wrote:Well, that was the whole collections idea in a nutshell, but every one of those new repos would inevitably leave some people stranded on an old one. Terrifyingly, there are still something like 100,000 hosts[1] hitting the EOL'ed 3.x repos, which will never get any updates... there's no clearly great answer here but optimizing to protect people who have 'ensure => latest' against upstream repos doesn't seem like the right thing.We've had this discussion before. Nevertheless, I submit that the proposition is not to "optimize" for people who rely on the upstream repos, but rather to faithfully fulfill the responsibilities that many people presume you undertake by providing software repos in the first place. In this case that also carries the benefit of avoiding torpedoing some 100K or so Puppet installations, and regardless of technical considerations, I question the wisdom of such a move on business and community relations grounds.
If you don't want to maintain repos for the EOL software versions (which is reasonable), then it would be much better to simply remove those repos than to drop incompatible package versions into them.
John
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/070d678d-68eb-4147-913e-d453f6c411ff%40googlegroups.com.
----Trevor Vaughan
Vice President, Onyx Point, Inc
-- This account not approved for unencrypted proprietary information --
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUTk6FrGRWtthFJK9doATAmNdLoisHUrMh7eh-6kzHTmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLd5OEhjSL3hyvJGXk9zDpZKVGXYuvU3s%3DitjA%2BJp0G7Ww%40mail.gmail.com.
Doing like debian with both named releases like squeeze and jessie etc, but also repositories like stable would be a nice option. That way users can just choose if they only want to stick to puppet 4.x packages in the repo or if they prefer to use package pinning instead and have the repo contain all packages.I would assume the majority of users pin their package versions, so the current solution where you need to both start mirroring a new repo, switch your hosts to use that and update the pinning is a bit of a hassle with no benefits compared to just updating the pinning which was the case before the PC1 repo.
On Tue, 28 Mar 2017 at 13:31 Trevor Vaughan <tvau...@onyxpoint.com> wrote:
+1 for just removing old repos.I would do something like CentOS where you have an archive or 'unsupported' space for people that simply can't upgrade for whatever reason.yum.puppetlabs.com/unsupported for the RPM users, for example.Trevor
On Mon, Mar 27, 2017 at 9:12 AM, John Bollinger <John.Bo...@stjude.org> wrote:
On Friday, March 24, 2017 at 5:09:31 PM UTC-5, Eric Sorenson wrote:Well, that was the whole collections idea in a nutshell, but every one of those new repos would inevitably leave some people stranded on an old one. Terrifyingly, there are still something like 100,000 hosts[1] hitting the EOL'ed 3.x repos, which will never get any updates... there's no clearly great answer here but optimizing to protect people who have 'ensure => latest' against upstream repos doesn't seem like the right thing.We've had this discussion before. Nevertheless, I submit that the proposition is not to "optimize" for people who rely on the upstream repos, but rather to faithfully fulfill the responsibilities that many people presume you undertake by providing software repos in the first place. In this case that also carries the benefit of avoiding torpedoing some 100K or so Puppet installations, and regardless of technical considerations, I question the wisdom of such a move on business and community relations grounds.
If you don't want to maintain repos for the EOL software versions (which is reasonable), then it would be much better to simply remove those repos than to drop incompatible package versions into them.
John
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/070d678d-68eb-4147-913e-d453f6c411ff%40googlegroups.com.
----Trevor Vaughan
Vice President, Onyx Point, Inc
-- This account not approved for unencrypted proprietary information --
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
On Apr 7, 2017, at 6:46 AM, Miguel Di Ciurcio Filho <mig...@instruct.com.br> wrote:Hello Eric, just a heads up about my questions :-D
On Fri, Mar 3, 2017 at 2:53 PM, Miguel Di Ciurcio Filho
<mig...@instruct.com.br> wrote:On Mon, Feb 27, 2017 at 8:59 PM, Eric Sorenson <eric.s...@puppet.com> wrote:The headline here is that the core open-source "Puppet Platform"
(puppet-agent, puppet-server, puppetdb) are moving to a more coordinated
release model, with compatibility guarantees and consistent versioning among
the components. The first release of this "Puppet Platform 5", currently
targeted at May, will bring these components' major versions together and
provide some nice features without a huge backwards-incompatible break.
Good news!
Would be possible to also version the components that go inside the
puppet-agent package in the same way? For example: facter, hiera and
mcollective.
Speaking about mcollective, it has been notorious that Puppet Inc. has
stopped any further development and has put mcolletive in maintenance
mode for quite a while, in favor of the Orchestrator in 2015.
Fast forward to 2017 and there are a lot of useful stuff in
mcollective still not available in the Orchestrator.
Is also known that R.I.Pienaar is trying to work with Puppet Inc to
maintain mcollective. Also, I consider his work on choria.io
remarkable and has keep mcollective powerful and useful once again.
Last years PuppetConf we where told that the server side of the
orchestrator would be merged into Puppet Server.
Looking into a "Puppet Platform 5", what looks like to be the
orchestration option?
Q: How's it going to be delivered? Are Puppet Collections still a thing?
A: Funny you should ask. As we kicked around a couple of months ago[3], it's
been two years and the collections idea just hasn't worked out in practice,
so it seems wise to iterate and keep evolving. The current plan is to create
a new repo, parallel with the existing PC1 repos, simply named 'puppet'. The
platform components will roll into it and future semver-majors will be
coordinated across the components, hopefully leading to smaller, easily
digestible chunks of change.
Sounds reasonable.
Would be this the time to also use /etc/puppet and /opt/puppet?
--
You received this message because you are subscribed to the Google Groups "Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to puppet-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/654C2DD0-4A0F-48B7-9FE1-BE144E04A5A0%40gmail.com.
For more options, visit https://groups.google.com/d/optout.