On Thu, 2015-06-04 at 20:17 -0700, Michael Stahnke wrote:
On Thu, Jun 4, 2015 at 2:21 PM, Haïkel <hguemar(a)fedoraproject.org>
wrote:
2015-06-04 20:21 GMT+02:00 John Florian
<john.florian(a)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(a)dart.biz>