-Josh
--
--
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/546B9CA0.3060504%40cpan.org.
For more options, visit https://groups.google.com/d/optout.
Hi all, as some of you have noticed, our target date in JIRA for Puppet 4 is not too far off now. (We just moved it out from early December to early January based on the remaining must-have workflow). While you can poke through tickets to see exactly what's going in, it might be helpful to have a little higher level overview of what is happening. Let me try to provide that as well as ask some questions of things we're not sure about.1. Ruby 1.8.7 support is going away.2. To enable #1 but still support OSes that ship with 1.8.7, we're going to be packaging and delivering Puppet 4 an an 'all-in-one' (AIO) package bundled together with- openssl- ruby- augeas- ruby-augeas- ruby-stomp- ruby-shadow- puppet- mcollective- facter- hiera- + misc supporting gems/libs (deep merge, yaml, etc)(Question: are there other *agent side* components you feel are essential to the functioning of the puppet stack?)
3. The AIO packages will have a filesystem layout that installs the programs into /opt/puppetlabs/agent and the configs into /etc/puppetlabs/agent ; the packages will be a different basename than puppet ('puppet-agent') so won't install automatically on an upgrade, but *will* obsolete the puppet packages if you decide to install them. AIO packages will be available from the Nightly repos Real Soon Now[tm] and I expect Melissa or Haus will update when they're up so everyone can poke at 'em.4. We are planning to break cross-major-version compatibility over the network. The amount of change we need to support in order to keep moving components to the Puppet Server and out of Ruby is the main driver for this, but generally, if you can't break compatibility on a major version boundary... when CAN you? See PUP-3641 for the overview of that work.5. The upgrade process would be as Chris described above, where you'd set up a new server running puppet 4 (hey it's an opportunity to move your puppetmasters to EL 7!) and point the new agents at it, leave the old ones running until their agents are drained.Question: What can/should we do to make that kind of transition go more smoothly? (One idea that just struck me is to have the puppet4 agent have a different default value for $server than 'puppet', so it wouldn't need post-install configuration to point at the new server)6. We're going to stop providing the puppetmaster/puppet-server (passenger) packaging in favour of the puppetserver packages. There will still be rack/passenger support in Puppet 4, but not in Puppet 5.7. Umm.. I think that's all.Eric Sorenson - eric.s...@puppetlabs.com - freenode #puppet: eric0
puppet platform // coffee // techno // bicycles
--
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/FF17DBFD-7DB1-4241-AC3C-EE9520A2E1C9%40puppetlabs.com.
On EL6.x, why not use a new SCL? Or even install into the existing
ruby193 SCL?
Part of the goal here is to have control of the ruby version. The SCL offers one version of Ruby 1.9.3, Ubuntu offers another in their distribution, as does Mac OS X, and the next OS. Compound that with libssl fun and End of Life constraints on Ruby 1.9.3, and it's just not that fun. (SCLs also have their own lifecycle that is different than RHEL).
We'll be picking one Ruby (2.1.z), and using that everywhere for a consistent stack.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CACD%3DwAdWbfyibjox4%2BPmj9ZKFsHBF%2Bd%3DGYG4PTCb6Q3NtihtJA%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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/472E836F-A255-4EA7-B98E-D71DFCC73E83%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.
Thats cool a controlled and independent stack with all the dependencies. Independent of the OS is great. Scl works only on rhel 6 and 7.
Please don't forget rhel 5 packages also. I know it is outdated but it is still widely used .
And bundled software will need to receive security updates, ex ruby openssl, etc .
Best
Lmello
Best
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CACD%3DwAeOeHxhtTUBY1FDeoiOQWRzGJuhF6xWYaJp_i5As0UvYA%40mail.gmail.com.
First question is, can you gracefully deprecate a line of agents, i.e.
retain 3.x agent compatibility throughout 4.x masters, and drop it at 5.0.
I shall assume that the engineering effort to go such a route would be a
magnitude or two above just dropping cross-version support, so doing the
hard cut is likely the right thing to do. But I will go on record
stating that this is not the kind of decision that should be made lightly.
Would the gems still be released ? I am concerned because we use the mcollective client gem in a web application and I also use multiple puppet and facter gems in rbenv for testing.
Best
--
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/472E836F-A255-4EA7-B98E-D71DFCC73E83%40puppetlabs.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAM%3D8oNJ0FvT03Y-ydYPPdzCagqWuQA3v10gj1%3DRcZhKA_1%2BdGQ%40mail.gmail.com.
Breaking this on 4.0 is OK with semver . breaking it on 4.1 would be a mess.
Best
Lmello
--
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/546DD9BB.5080901%40alumni.tu-berlin.de.
I could be wrong , but I believe this change in the way puppet open source would be distributed makes it similar on with the way puppet enterprise is distributed.
So we should expect something like pe_gem to install gems on the puppet bundle.
And provider gem to install on system ruby.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/E1661A4A-8685-412E-A45C-AA013FE72A85%40gmail.com.
--eric0
--
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/472E836F-A255-4EA7-B98E-D71DFCC73E83%40puppetlabs.com.
On Wed Nov 19 2014 at 8:36:46 PM Eric Sorenson <eric.s...@puppetlabs.com> wrote:
On Nov 19, 2014, at 11:20 AM, Trevor Vaughan <tvau...@onyxpoint.com> wrote:
> Hmm...Facter and MCollective not being independently upgradable isn't super exciting.
If any one of the main constituent projects having a release would cause a new AIO to come out, is that the right cycle?
(Do you currently always track the latest package of the Puppet-related projects you use?)generally we don't, but almost.Seems a bit odd to me to not be able to upgrade puppetdb, facter or mcollective independently of puppet though.And we would likely need to install things into that ruby env anyway. So why not have the ruby env as one package and the other packages depend on that and install things into it?
Hi all, as some of you have noticed, our target date in JIRA for Puppet 4 is not too far off now. (We just moved it out from early December to early January based on the remaining must-have workflow). While you can poke through tickets to see exactly what's going in, it might be helpful to have a little higher level overview of what is happening. Let me try to provide that as well as ask some questions of things we're not sure about.1. Ruby 1.8.7 support is going away.2. To enable #1 but still support OSes that ship with 1.8.7, we're going to be packaging and delivering Puppet 4 an an 'all-in-one' (AIO) package bundled together with- openssl- ruby- augeas- ruby-augeas- ruby-stomp- ruby-shadow- puppet- mcollective- facter- hiera- + misc supporting gems/libs (deep merge, yaml, etc)(Question: are there other *agent side* components you feel are essential to the functioning of the puppet stack?)
3. The AIO packages will have a filesystem layout that installs the programs into /opt/puppetlabs/agent and the configs into /etc/puppetlabs/agent ; the packages will be a different basename than puppet ('puppet-agent') so won't install automatically on an upgrade, but *will* obsolete the puppet packages if you decide to install them. AIO packages will be available from the Nightly repos Real Soon Now[tm] and I expect Melissa or Haus will update when they're up so everyone can poke at 'em.
4. We are planning to break cross-major-version compatibility over the network. The amount of change we need to support in order to keep moving components to the Puppet Server and out of Ruby is the main driver for this, but generally, if you can't break compatibility on a major version boundary... when CAN you? See PUP-3641 for the overview of that work.
On Nov 18, 2014, at 11:04 AM, Eric Sorenson <eric.s...@puppetlabs.com> wrote:
> 7. Umm.. I think that's all.
Wow thanks for all the responses, there are a ton of very good questions in here -- some of them got answered inline and I think we rolled up the rest into this little FAQ. which I''m sure will generate a new set of questions :)
0 - Which platforms will get FOSS AIO packages?
RHEL/Centos 5, 6, 7
Fedora 20, 21
Ubuntu 10.04, 12.04, 14.04
Debian Squeeze, Wheezy
Windows x86, x64
Commercial OS'es (Windows excepted) will get PE-only AIO
SLES 10, 11
Solaris 10,11
AIX
Mac OS X
1 - How do I manage gems with AIO ruby?
Use the AIO included gem binary. ('/opt/puppet/agent/bin/gem install somerandomgem') To make this easier, we can either fix PUP-3688 or add a module with a minimal 'puppet_gem' provider using the AIO path.
2 - Will there be security updates, etc?
Yes, absolutely.
3 - Will it include puppetdb-terminus?
Yes.
4 - What will the release cadence look like? What if I want to manage component upgrades on a different cadence than upstream, e.g. just facter, or just hiera?
We're planning to provide three trains of packaging:
• Nightlies, that get built whenever there's a change in one of the component repositories that passes through CI. These will essentially track the latest, like the nightly repos do now.
• Roll-up releases that would track tagged versions of the component repositories. This would work like having 'ensure => latest' pointed at the current 'products' repository.
• PE releases that track stable releases and are coordinated with the rest of the PE ecosystem, are QA tested, and have some set of backports / commercial enhancements.
For power users who want more control than that, we’ll have documentation on how to roll your own. The tooling to create AIO will itself be open-sourced so you could build a package that picks the versions you want to include.
5 - Why not use a metapackage which has no content of its own, but has requirements on specific versions of the other 'real' packages that contain the actual programs?
• Avoiding a coordinated major version ship across all projects… We're changing the layout on the filesystem (moving to opt) for a few reasons, including shipping our own stack without conflicting with system libraries. This kind of change shouldn't be done in a "y" release (of x.y.z). Components that have been updated can’t mix/match with components that haven’t. Example: A user has facter ensure => latest, but not puppet. They’ll get facter with the new layout (and maybe the new PL-provided ruby, if its a dependency of the new facter), but not puppet, and have a broken install. If the meta-package provides facter, then users with ensure => latest on facter but not puppet will have a completely new install of their whole stack. Neither of these are ideal. To avoid any automatic installs, we could have facter *not* provide itself, which is also probably not the route to go down. The AIO ensures users have everything they need at the same time, and can just continue using the agent after upgrade.
• We want to simplify the endpoint install experience for users. A single endpoint puppet agent package is arguably among the simplest possible deployment mechanisms.
• Meta-package only solves the problem for agents with a package manager that can do remote dependency resolution. We want the install experience for agents to be excellent/seamless regardless of the platform you are running, and be the same experience across the board. Users installing a Solaris 10 agent package shouldn’t have a different experience than users installing a Debian 7 agent package.
6 - Will using AIO puppet/mco to upgrade AIO work?
Once we have AIO packages ready, we’ll be doing some testing of upgrade scenarios.
7 - Why are you dropping 3.x agent compat with 4.0 master?
We didn’t take this decision lightly, and it came down to getting 4.0 features out into people’s hands sooner rather than later.
Backward compatibility on the network in this case is a fair bit of work, which we haven’t fully scoped, so in 4.0 we opted for the current tradeoff.
We recommend users take a “migrate, not update” approach to 4.0 upgrades, and people taking this approach probably won’t much care about this change.
On Fri, Nov 21, 2014 at 12:46 PM, Eric Sorenson <eric.s...@puppetlabs.com> wrote:
On Nov 18, 2014, at 11:04 AM, Eric Sorenson <eric.s...@puppetlabs.com> wrote:
> 7. Umm.. I think that's all.
Wow thanks for all the responses, there are a ton of very good questions in here -- some of them got answered inline and I think we rolled up the rest into this little FAQ. which I''m sure will generate a new set of questions :)
0 - Which platforms will get FOSS AIO packages?
RHEL/Centos 5, 6, 7
Fedora 20, 21
Ubuntu 10.04, 12.04, 14.04
Debian Squeeze, Wheezy
Windows x86, x64Windows 7/8/2008/12?
--
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/CACqVBqDKb8pV5zT8ER%2Bk3hiE6Om2mPs6yA6FnF6iNtvWxxkg0g%40mail.gmail.com.
--
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/08BAFC24-F5DB-401B-99FD-046B1AAB3917%40gmail.com.
On Nov 24, 2014 11:33 AM, "Erik Dalén" <erik.gus...@gmail.com> wrote:
>
> Will there be a version of this AIO package for 3.7.4 (or even 3.7.3) so we can try out the packaging without trying out all the stuff in puppet 4.0 at the same time?
+1
>
> On Sat Nov 22 2014 at 11:46:16 AM Martin Alfke <tux...@gmail.com> wrote:
>>
>>
>> On 21 Nov 2014, at 21:46, Eric Sorenson <eric.s...@puppetlabs.com> wrote:
>>
>> >
>> > 0 - Which platforms will get FOSS AIO packages?
>> >
>> > RHEL/Centos 5, 6, 7
>> > Fedora 20, 21
>> > Ubuntu 10.04, 12.04, 14.04
>> > Debian Squeeze, Wheezy
>> > Windows x86, x64
>>
>> OpenSuSE?
>> Debian Jessie?
>>
>> >
>> > 1 - How do I manage gems with AIO ruby?
>> >
>> > Use the AIO included gem binary. ('/opt/puppet/agent/bin/gem install somerandomgem') To make this easier, we can either fix PUP-3688 or add a module with a minimal 'puppet_gem' provider using the AIO path.
>>
>> That would be very ugly (e.g. for installing hiera add ons).
>> Why can we not adopt the behaviour of pe_gem provider?
>>
>> >
>> > 3 - Will it include puppetdb-terminus?
>> >
>> > Yes.
>> Can we choose from multiple versions?
>> e.g. we have new puppet and older puppet (migration process) running in parallel and we want both masters to make use of the same puppetdb.
>>
>> >
>> > 4 - What will the release cadence look like? What if I want to manage component upgrades on a different cadence than upstream, e.g. just facter, or just hiera?
>> >
>> > For power users who want more control than that, we’ll have documentation on how to roll your own. The tooling to create AIO will itself be open-sourced so you could build a package that picks the versions you want to include.
>>
>> +1
>>
>>
>> --
>> 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/08BAFC24-F5DB-401B-99FD-046B1AAB3917%40gmail.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+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAAAzDLe72HCy8OBoi1s18eOb1bYOoTVE2VVL%3DhbyVY3LpCdVuA%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CAH_Azc2p_3MuwcUS_zQHTA1_CVpw2r5nuVUQJ-eRjsD%2Bs2Xmzg%40mail.gmail.com.
5 - Why not use a metapackage which has no content of its own, but has requirements on specific versions of the other 'real' packages that contain the actual programs?
• Avoiding a coordinated major version ship across all projects… We're changing the layout on the filesystem (moving to opt) for a few reasons, including shipping our own stack without conflicting with system libraries.
• We want to simplify the endpoint install experience for users. A single endpoint puppet agent package is arguably among the simplest possible deployment mechanisms.
• Meta-package only solves the problem for agents with a package manager that can do remote dependency resolution. We want the install experience for agents to be excellent/seamless regardless of the platform you are running, and be the same experience across the board. Users installing a Solaris 10 agent package shouldn’t have a different experience than users installing a Debian 7 agent package.
--
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/50155310-cda5-4384-b7d8-45ebe729449c%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUSjRqZUv29Ofu%3DpiHz3Y2Nk9Lwu3oT1qXDf53bCnbchg%40mail.gmail.com.
Hi All,I'm curious as to what decisions (if any) have been made here.Thanks,Trevor
I'm in 100% agreement with John here.As with John, if this is not the case, I'll just end up re-packaging everything myself and forgo the AIO packages (and not be thrilled about it).
Right now, I have a forked Hiera that I'm using based off of some patches that I have PRs in for. Once this gets resolved, I'll merge everything back to the mainline, but I *must* have the ability to deviate when necessary for the best results of my users.
Thanks,
Trevor
On Mon, Nov 24, 2014 at 11:12 AM, John Bollinger <john.bo...@stjude.org> wrote:
On Friday, November 21, 2014 2:47:05 PM UTC-6, Eric Sorenson wrote:
5 - Why not use a metapackage which has no content of its own, but has requirements on specific versions of the other 'real' packages that contain the actual programs?
• Avoiding a coordinated major version ship across all projects… We're changing the layout on the filesystem (moving to opt) for a few reasons, including shipping our own stack without conflicting with system libraries.• We want to simplify the endpoint install experience for users. A single endpoint puppet agent package is arguably among the simplest possible deployment mechanisms.
Not buying it. An AIO package does not inherently avoid these sorts of problems (i.e. what if I have both 'facter' and 'puppet-aio' packages installed at the same time?), and a metapackage approach is not inherently any more susceptible to them (it's all about which packages are managed).
Yay for simple installation. A metapackage achieves that, too.
• Meta-package only solves the problem for agents with a package manager that can do remote dependency resolution. We want the install experience for agents to be excellent/seamless regardless of the platform you are running, and be the same experience across the board. Users installing a Solaris 10 agent package shouldn’t have a different experience than users installing a Debian 7 agent package.
So? You are committed to separate native packaging for a wide variety of systems anyway. Why not make use of the features of those systems that have more capable package managers?
I really, really dislike AIO packages. In fact, I tend to break them up when I can. They do confer a greater level of control on packagers, but along with that comes considerably more responsibility and exposure, and considerably less user flexibility. If anything needs changing in any component, the whole AIO needs to be updated. Any flaw or vulnerability in any component is a flaw in the whole AIO. The more components you bundle together, the worse it is, and it is particularly bad when you bundle third-party components.
It just doesn't have to be that way on systems that can support metapackages. You can have your cake and eat it too: a metapackage provides for easy installation and update, and done right it provides for ensuring that a given installation has a tested and approved combination of components, but you still have the flexibility of managing components individually (possibly requiring the removing the metapackage but retaiing the component packages).
In the end, you'll of course do what you think best. If it ends up being AIO packages across the board, then I simply won't use your packages. What a shame.
--Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com
-- This account not approved for unencrypted proprietary information --
--Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvau...@onyxpoint.com
-- 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%2BFoUSjRqZUv29Ofu%3DpiHz3Y2Nk9Lwu3oT1qXDf53bCnbchg%40mail.gmail.com.
We're not going to ship deb and rpm metapackages, to address the last points on the thread. We _will_ make it as easy as possible to build AIO with different combinations of component versions so you can compose your own but still retain up- and down-grade compatibility with PL supplied packages. I'm sorry you and John aren't convinced by the all-in-one plan; I see your point and totally agree that as an advanced Linux+FOSS Puppet user, it's not the optimum solution.
Additionally, avoiding hardcoded paths and avoiding the assumption that Puppet has a private Ruby to play around in will be helpful (and wise in any case).
On Wed, Dec 10, 2014 at 10:27 AM, John Bollinger <john.bo...@stjude.org> wrote:Additionally, avoiding hardcoded paths and avoiding the assumption that Puppet has a private Ruby to play around in will be helpful (and wise in any case).If the best predictor of future behavior is past behavior then our components will make assumptions about hardcoded paths and the location of specific dependencies like Ruby, Java, etc... I don't think it's possible to avoid this outcome given the number of people and teams working on the various projects and the desire to reduce the complexity of the system.
Do you have a sense of how much impact this will be on you John?
If I cannot install Puppet into a Ruby installation of my choice (of sufficiently recent version) and have it work correctly, or if its installation alters the behavior of other software relying on that Ruby, then I do not foresee updating until I or someone else can fix those problems. I am unlikely to be able to devote any effort to such an endeavor any time soon, so my adoption of the new version would be forestalled indefinitely.
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/548DFC3B.2070604%40dasz.at.
I think it’s worth asking the question of whether you want PL to spend their time building good CM software or dealing with and QA’ing the myriad combinations of Rubies and gems that they are currently forced to support due to the sloppiness and inconsistency of distro packaging and the gem ecosystem.
Personally, I’d rather allow PL to vendor the Ruby and gems required to keep Puppet itself working properly so that I can rely on it to perform basic system tasks. Since the vendored Ruby and gems are far away from system Ruby, I view this as a *freedom* in my ability to manage a system. I now don’t have to worry about keeping my custom or third-party Ruby tool code at the same version and gemset as a single tool across the system.
This then switches the burden to them to keep up with security and bugfix issues in the Rubies and gems they bundle, but frankly I have a greater belief that PL will manage to do this successfully - in aggregate - than the distributions and hand-rolled gemsets that people are using now.
On December 15, 2014 at 7:51:58 AM, John Bollinger (john.bo...@stjude.org) wrote:
This then switches the burden to them to keep up with security and bugfix issues in the Rubies and gems they bundle, but frankly I have a greater belief that PL will manage to do this successfully - in aggregate - than the distributions and hand-rolled gemsets that people are using now.
And that's a large reason why I don't think it's a particularly wise business decision to provide AIO packages: the fewer CVEs have Puppet's name on them, the better. But that's really beside the point, which is not so much about PL offering AIO packages as about future Puppet being dependent on AIO form, and on a particular AIO form at that. I don't have to use PL's packages, but I do have to deal with Puppet's built-in requirements and limitations, and to reconcile those with my system management policies and practices.
As an armchair IP quarterback, I'd also be concerned that if Puppet works only in AIO form then it will be the AIO form that must then be considered "Puppet". The AIO will incorporate a great deal of IP that does not belong to PL. In the past, PL has preferred a conservative approach to IP, so I'll suppose that either this isn't an issue of genuine concern or that PL has not considered it.
Without speaking for PL, I’d suspect that’s *exactly* how they’d like users to see it, as with Omnibus packaging. You get Puppet, and Puppet can assist in troubleshooting for Puppet only as delivered.