Puppet 4

[John Florian]

On Thu, 2015-06-04 at 20:17 -0700, Michael Stahnke wrote:
> 
> 
> On Thu, Jun 4, 2015 at 2:21 PM, Haïkel <hguemar at fedoraproject.org>
> wrote:
>         2015-06-04 20:21 GMT+02:00 John Florian
>         <john.florian at dart.biz>:
>         > I’ve been curious how Fedora plans to tackle inclusion of
>         Puppet 4, but
>         > haven’t heard even a peep on the subject.  As described[1],
>         they’ve moved to
>         > an all-in-one packaging process that “includes Puppet 4,
>         both Facter 2.4 and
>         > CFacter 0.4, the latest Hiera and Mcollective, as well Ruby
>         2.1.5, OpenSSL
>         > 1.0.0r, and our gem dependencies.”  Furthermore, “the
>         package installs into
>         > its own area in /opt/puppetlabs”.  Thus upstream is both
>         bundling and using
>         > very Fedora-unfriendly file locations.  L
>         >
> The source itself really hasn't changed a ton. There might some
> pathing of /opt/puppetlabs in there, but the source of Puppet is
> nearly the same. (And if that's a big problem, we'd certainly look at
> patches on it).
> 
> 
> The packaging is quite different from us (Puppet Labs) certainly.
> However, every linux distro didn't use our packages and repackaged our
> source themselves anyway, so that shouldn't have changed much from a
> distro packager/consumer perspective.  We've reduced our test matrix
> by a hundreds (maybe thousands) of cells by supporting fewer rubies
> and including the bits we need rather than test all variables across
> 70+ targets that we support. 

Ok.  I certainly get the position that PuppetLabs or any other vendor is
in here.  My concern was with the 4.x announcement.  It sounded like a
significant change, at least as far as impact on distro packagers.
Combine that news  with the general desire in Fedora to not patch any
more than necessary so as to stay with upstream and I wasn't sure how
this would play out.  Sounds like I'm worrying unnecessarily.  Chalk it
up to better awareness of what everyone has been doing all along.

> I love Fedora and always want Puppet to be a part of it. If
> something's really broken, please let me know. 

We'll do.  Thank you for all the effort.

> I know we're behind on F21 and 22. Sadly, the time allotted means we
> stagger when certain releases come out. Fedora is in the mix to be
> done soon (how soon is difficult to say.) 

I don't mind the staggering, but I will worry if the only supported
Fedora is also EoL.  It would seem the rush is on for F21 support given
F20 withers away this month.


>         >
>         
>         Hi,
>         
>         F22 provides Ruby 2.2 and upstream has stated they will only
>         support it starting
>         Puppet 4.x.
>         I've been working with puppeteers to port Puppet 4.x on F22,
>         and it has been for
>         a long time in testing but Puppet 4.1 is being currently
>         pushed to stable.
>         I'm not backporting it to older Fedora, as Puppet 3.x is still
>         supported on these
>         platforms.
>         
>         As Orion and I were the ones doing Puppet updates recently, I
>         found a new
>         maintainer for Puppet who will be able to keep it in a sane
>         state.
>         
>         >
>         > I’ve long awaited having PuppetDB provided within Fedora[2]
>         and from what I
>         > understand the bundling has hindered that effort
>         substantially.  Are we
>         > going to lose Puppet in Fedora, or be stuck with an ever
>         aging old release?
>         > At home, I did the most undesirable thing and enabled the
>         PuppetLabs
>         > repositories and love the newer products.  Meanwhile I still
>         am waiting for
>         > PL to support Fedora 21 -- and F22 is already out!  At work
>         I’m hesitant
>         > with either route (native Fedora packages vs. PL’s repos)
>         for fear of being
>         > stuck in an unsupported situation.  (Yes, we probably should
>         be on a EL-ish
>         > distro if it’s critical, but we use Fedora almost
>         exclusively.)
>         >
>         >
>         
>         PuppetDB is a mess, it requires a lot of unbundling work and
>         it's in java.
>         We're considering packaging it for OpenStack but outside
>         Fedora as it will
>         be too much effort for us.
>         
> 
> 
> It's actually Clojure, not java. One could argue that the way distros
> want to package java-ecosystem tools is actually what's messy (hence
> people loving containers, fpm and other tools as well). Having to
> unbundle items that are tested together and allow a third party to
> move one of the libraries that the upstream isn't testing with doesn't
> seem all that sane either. I certainly see both sides of the argument
> here. I was a long time in the unbundle camp, but after working
> somewhere trying to appease packaging/distro guidelines on dozens of
> platforms, it's just impossible. We'd need an engineering team 3x the
> size it is just to do the testing, and nobody would get any new
> features. Even RH doesn't package all the jboss stuff in Fedora for
> the same reasons, and most Linux distribution are very short on
> packaging for applications and tools built on JVM vs what's really out
> there. 
> 
> 
> I'm not sure how we/I can help here, but again, discussion welcome. 

Yes, I too see both camps with clarity.  I wish the unbundled route were
always possible because it seems ideal... if only it were possible and
sustainable.  Containers of any sort seem like cheating, but I get it.
Perhaps the real challenge lies with far more sophisticated test
frameworks that automatically seek out the largest possible matrix ...
and libraries that are more dynamic and accommodating of their
environment.  I suspect SkyNet will govern us all by then though.


-- 
John Florian <john.florian at dart.biz>