Re: Puppet 4
On Mon, Jun 22, 2015 at 10:22 PM, Michael Stahnke stah...@puppetlabs.com wrote: As a point of moderation, we could probably break out the FHS/stateless discussion into its own thread, as at this point this has nearly nothing to do with Puppet. Good point. Let me circle it back around: It seems reasonable for a management toolkit like Puppet, which may require somewhat non-system versions of critical libraries and scripting language modules, to follow the FHS for third-party packages and live in /opt/puppet. There's a real burden in relying on, and integrating with, the Fedora system components due to the potential for incompatible upgrades of those modules in the Fedora operating system, or for leading edges of those components to be introduced for Puppet but be incompatible with other, especially older, existing Fedora systems. So it's sometimes safer, as in this case, to segregate those components from the base OS. So while as a recommended practice segregating tools like Puppet to a separate working area can be non-standard for Fedora, it certainly seems both workable and justified in this case. It helps retain independent upgradeability across Fedora releases and for the RHEL environments, the corporate supported OS which provides a great deal of Fedora support and ingrastructure. I've been through similar issues recently with chef, chefdk, RT, cfengine, GForge, and other add-on components. The desire to root the core of such a package in the operating system's own internal modules and libraries is understandable, but it can become a maintenance and integration nightmare quite quickly and needs to be, occasionally, rejected. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Mon, Jun 15, 2015 at 6:58 AM, Nico Kadel-Garcia nka...@gmail.com wrote: The /etc migration, however, is part of the stateless linux work desribed at http://0pointer.de/blog/projects/stateless.html. They're planning on resetting /etc to a pristine vendor state, and basdically keep it that way. That's a pretty basic violation of 30 years of the use of /etc. You appear to ignore the fact that they aren't forcing every system to be stateless. They specifically discuss at several points that stateful systems where /etc et al work as they always have will continue to be supported. -- Jeff Ollie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
As a point of moderation, we could probably break out the FHS/stateless discussion into its own thread, as at this point this has nearly nothing to do with Puppet. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Mon, Jun 8, 2015 at 11:04 AM, Zbigniew Jędrzejewski-Szmek zbys...@in.waw.pl wrote: On Sat, Jun 06, 2015 at 06:52:35PM -0400, Nico Kadel-Garcia wrote: Given the profound discrepancies between the FHS 3 and everything that systemd touches, I'm afraid it's become a confusing guideline for Fedora work. Fully agreed that using FHS as a guideline in confusing. It is disappointing that the authors seem to completely ignore changes like the merge to /usr, the ways in which /run is being used, etc. Ignoring a long stable and well documented standard, and then kvetching about how the standard has not documented the ways relatively new developers violated it, is quite an unreasonable expectation. It's like finding a five year old with their mouth full of their sister's kid's birthday cake, and the kid saying mom, you should have brought me my own cake! It's especially disengenuous because various features, such as the /media for detachable and /etc for configuration files, are directly or indirectly being replaced as part of the stateless Linux part of systemd, which has zip, zero, nada to do with the original improvements to init processes and low level logging for which its a good solution. Whatever one may think about it, systemd and the locations promulgated by systemd have become *the* defaults for a great majority of modern linux landscape. Even if systemd was spearheading some of those changes, such decisions have to be implemented by the whole distro, and were coordinated between multiple distros. FHS makes itself obsolete by ignoring them. We've got the kid with his mouthful of his sister's birthday cake here again. In particular, the insistence in sytemd of putting mountable medie under /run, and of migrating system-specific conffigurations from /etc to /run are at direct variance with even that most recent FHS. So it's not going to be a complete or reliable guideline. Actually it's not systemd: udisks uses this location for removable media. Neither is systemd migrating configurations from /etc to /run (they would get wiped at reboot ;)). Thank you for the correction. I'd seen Lennart Pottering's name associated with this change, but that was a systemd tweak to go with it. It was apparently David Zeuthen. https://plus.google.com/u/0/+DavidZeuthen/posts/NqPUifsFUYH The /etc migration, however, is part of the stateless linux work desribed at http://0pointer.de/blog/projects/stateless.html. They're planning on resetting /etc to a pristine vendor state, and basdically keep it that way. That's a pretty basic violation of 30 years of the use of /etc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Sat, Jun 06, 2015 at 06:52:35PM -0400, Nico Kadel-Garcia wrote: On Fri, Jun 5, 2015 at 11:31 AM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Jun 05, 2015 at 01:31:10PM +, John Florian wrote: Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE, but to my knowledge the FHS has never ratified anything like that. The FHS seems to take a rather vague stance on /opt overall IMHO. This is actually specifically addressed in FHS 3.0, released, actually, _just this week_. See http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30 and specifically http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html and the provider list: http://www.lanana.org/lsbreg/providers/providers.txt which includes Fedora. (Credit to Tom and Toshio for working on this.) Given the profound discrepancies between the FHS 3 and everything that systemd touches, I'm afraid it's become a confusing guideline for Fedora work. Fully agreed that using FHS as a guideline in confusing. It is disappointing that the authors seem to completely ignore changes like the merge to /usr, the ways in which /run is being used, etc. Whatever one may think about it, systemd and the locations promulgated by systemd have become *the* defaults for a great majority of modern linux landscape. Even if systemd was spearheading some of those changes, such decisions have to be implemented by the whole distro, and were coordinated between multiple distros. FHS makes itself obsolete by ignoring them. In particular, the insistence in sytemd of putting mountable medie under /run, and of migrating system-specific conffigurations from /etc to /run are at direct variance with even that most recent FHS. So it's not going to be a complete or reliable guideline. Actually it's not systemd: udisks uses this location for removable media. Neither is systemd migrating configurations from /etc to /run (they would get wiped at reboot ;)). Zbyszek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Fri, Jun 5, 2015 at 11:31 AM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, Jun 05, 2015 at 01:31:10PM +, John Florian wrote: Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE, but to my knowledge the FHS has never ratified anything like that. The FHS seems to take a rather vague stance on /opt overall IMHO. This is actually specifically addressed in FHS 3.0, released, actually, _just this week_. See http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30 and specifically http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html and the provider list: http://www.lanana.org/lsbreg/providers/providers.txt which includes Fedora. (Credit to Tom and Toshio for working on this.) Given the profound discrepancies between the FHS 3 and everything that systemd touches, I'm afraid it's become a confusing guideline for Fedora work. In particular, the insistence in sytemd of putting mountable medie under /run, and of migrating system-specific conffigurations from /etc to /run are at direct variance with even that most recent FHS. So it's not going to be a complete or reliable guideline. Tools like RT, puppet, and chef that may be open source, but require extensive internal modules and libraries that are incompatible with other system components are prime examples of tools that benefit from segregation from the rest of the environment. I've taken a shot at resolving the ruby gem dependencies of chef, and some Java integration for puppet, and perl module librares for RT. It's a nightmare to resolve the dependency hell: they're much safer to manage separately. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Thu, 2015-06-04 at 23:21 +0200, Haïkel wrote: 2015-06-04 20:21 GMT+02:00 John Florian john.flor...@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 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. Oh, that's great news! I'm still on F21 ATM and haven't had chance to play with F22 yet. I'm not backporting it to older Fedora, as Puppet 3.x is still supported on these platforms. Fair enough -- seems logical. PuppetDB is a mess, it requires a lot of unbundling work and it's in java. My understanding is that it's not Java but rather Clojure running atop the JVM. But understand it's a mess from what I've seen in the BZ. It certainly seems to have all the bundling characteristics that comes from that Java mentality. We're considering packaging it for OpenStack but outside Fedora as it will be too much effort for us. Under my rock, I'm unfamiliar with OpenStack though I've certainly heard of it. Would that mean I'd be able to use Puppet from Fedora's repos and PuppetDB via OpenStack somehow? Presently I get both from PuppetLabs, as I mentioned. I enabled their repos to get PuppetDB and then found my Puppet also jumped to theirs simply because it was newer. It surprised me though I should have seen it coming. Then I was hooked on the capabilities the DB brought and also from the newer Puppet, especially the Clojure-based Server. Now I'm just trying to figure out what the best approach is going forward while staying based on Fedora as much as possible. If you're willing to contribute packaging it, then I could help you in this task. I wish I could. Alas my spare time has been gobbled up by a multi-year effort of home repairs. :-( -- John Florian john.flor...@dart.biz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Thu, 2015-06-04 at 20:17 -0700, Michael Stahnke wrote: On Thu, Jun 4, 2015 at 2:21 PM, Haïkel hgue...@fedoraproject.org wrote: 2015-06-04 20:21 GMT+02:00 John Florian john.flor...@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
Re: Puppet 4
On Fri, 2015-06-05 at 01:12 -0400, Nico Kadel-Garcia wrote: On Thu, Jun 4, 2015 at 2:21 PM, John Florian john.flor...@dart.biz wrote: 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 As long as it's in /opt, what's the problem? That's what /opt is for! Unwielding and resolving individual components of an integrated tool suite is often a nightmare, which is why puppet, chef, and numerous commercial packages do the same thing. Packaging Guidelines for one. My personal belief is that /opt should only be populated by the local admin, never the distro nor a vendor. Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE, but to my knowledge the FHS has never ratified anything like that. The FHS seems to take a rather vague stance on /opt overall IMHO. -- John Florian john.flor...@dart.biz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
Hi! (Sorry for top-quote, but on mobile...) Copy that and FHS states this quite clear. Personally I'm also not a huge fan of software installing to /opt. Neither am I a fan of packaging (local) libraries in there - for a variety of reasons. I even think the Fedora packaging guidelines forbid this. -of (mobile) Am 05.06.2015 um 17:17 schrieb Michael Stahnke stah...@puppetlabs.com mailto:stah...@puppetlabs.com : On Fri, Jun 5, 2015 at 8:15 AM, Michael Stahnke stah...@puppetlabs.com mailto:stah...@puppetlabs.com wrote: On Fri, Jun 5, 2015 at 6:31 AM, John Florian john.flor...@dart.biz mailto:john.flor...@dart.biz wrote: On Fri, 2015-06-05 at 01:12 -0400, Nico Kadel-Garcia wrote: On Thu, Jun 4, 2015 at 2:21 PM, John Florian john.flor...@dart.biz mailto:john.flor...@dart.biz wrote: 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 As long as it's in /opt, what's the problem? That's what /opt is for! Unwielding and resolving individual components of an integrated tool suite is often a nightmare, which is why puppet, chef, and numerous commercial packages do the same thing. Packaging Guidelines for one. My personal belief is that /opt should only be populated by the local admin, never the distro nor a vendor. Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE, but to my knowledge the FHS has never ratified anything like that. The FHS seems to take a rather vague stance on /opt overall IMHO. Could functionally explain the difference then between /usr/local and /opt? Opt has been for thrid-party/commercial/optional software for as long as I've used *NIX. /usr/local more for the local admin to build/compile/setup what he/she would like. Just as a point of record, we do /opt/$VENDOR/$PRODUCT not so much with the release, but we're close to what you wanted. -- devel mailing list devel@lists.fedoraproject.org mailto:devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Fri, Jun 05, 2015 at 06:48:45PM +, John Florian wrote: http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html Thanks for that info. I've always referenced http://www.pathname.com/fhs/ before. Is that no longer authoritative ... or was it ever? It was authoritative for a long time, but the Linux Foundation officially took over in 2011 or so. However, it languished for a while with only a draft; it's only been in the past year or so that there's been this push to actually get the 3.0 revision out the door. -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Fri, 2015-06-05 at 11:32 -0400, Matthew Miller wrote: On Fri, Jun 05, 2015 at 11:31:04AM -0400, Matthew Miller wrote: This is actually specifically addressed in FHS 3.0, released, actually, _just this week_. See http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30 and specifically http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html and the provider list: http://www.lanana.org/lsbreg/providers/providers.txt which includes Fedora. (Credit to Tom and Toshio for working on this.) Oh, and not to forget: https://fedoraproject.org/wiki/Packaging:Guidelines#Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader Thanks for that info. I've always referenced http://www.pathname.com/fhs/ before. Is that no longer authoritative ... or was it ever? -- John Florian john.flor...@dart.biz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Fri, Jun 05, 2015 at 11:31:04AM -0400, Matthew Miller wrote: This is actually specifically addressed in FHS 3.0, released, actually, _just this week_. See http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30 and specifically http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html and the provider list: http://www.lanana.org/lsbreg/providers/providers.txt which includes Fedora. (Credit to Tom and Toshio for working on this.) Oh, and not to forget: https://fedoraproject.org/wiki/Packaging:Guidelines#Limited_usage_of_.2Fopt.2C_.2Fetc.2Fopt.2C_and_.2Fvar.2Fopt -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Fri, Jun 5, 2015 at 6:31 AM, John Florian john.flor...@dart.biz wrote: On Fri, 2015-06-05 at 01:12 -0400, Nico Kadel-Garcia wrote: On Thu, Jun 4, 2015 at 2:21 PM, John Florian john.flor...@dart.biz wrote: 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 As long as it's in /opt, what's the problem? That's what /opt is for! Unwielding and resolving individual components of an integrated tool suite is often a nightmare, which is why puppet, chef, and numerous commercial packages do the same thing. Packaging Guidelines for one. My personal belief is that /opt should only be populated by the local admin, never the distro nor a vendor. Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE, but to my knowledge the FHS has never ratified anything like that. The FHS seems to take a rather vague stance on /opt overall IMHO. Just as a point of record, we do /opt/$VENDOR/$PRODUCT not so much with the release, but we're close to what you wanted. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Fri, Jun 5, 2015 at 8:15 AM, Michael Stahnke stah...@puppetlabs.com wrote: On Fri, Jun 5, 2015 at 6:31 AM, John Florian john.flor...@dart.biz wrote: On Fri, 2015-06-05 at 01:12 -0400, Nico Kadel-Garcia wrote: On Thu, Jun 4, 2015 at 2:21 PM, John Florian john.flor...@dart.biz wrote: 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 As long as it's in /opt, what's the problem? That's what /opt is for! Unwielding and resolving individual components of an integrated tool suite is often a nightmare, which is why puppet, chef, and numerous commercial packages do the same thing. Packaging Guidelines for one. My personal belief is that /opt should only be populated by the local admin, never the distro nor a vendor. Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE, but to my knowledge the FHS has never ratified anything like that. The FHS seems to take a rather vague stance on /opt overall IMHO. Could functionally explain the difference then between /usr/local and /opt? Opt has been for thrid-party/commercial/optional software for as long as I've used *NIX. /usr/local more for the local admin to build/compile/setup what he/she would like. Just as a point of record, we do /opt/$VENDOR/$PRODUCT not so much with the release, but we're close to what you wanted. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Fri, Jun 05, 2015 at 01:31:10PM +, John Florian wrote: Personally I do so using a scheme like /opt/$VENDOR/$PRODUCT/$RELEASE, but to my knowledge the FHS has never ratified anything like that. The FHS seems to take a rather vague stance on /opt overall IMHO. This is actually specifically addressed in FHS 3.0, released, actually, _just this week_. See http://www.linuxfoundation.org/collaborate/workgroups/lsb/fhs-30 and specifically http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html and the provider list: http://www.lanana.org/lsbreg/providers/providers.txt which includes Fedora. (Credit to Tom and Toshio for working on this.) -- Matthew Miller mat...@fedoraproject.org Fedora Project Leader -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
2015-06-04 20:21 GMT+02:00 John Florian john.flor...@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 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. If you're willing to contribute packaging it, then I could help you in this task. Regards, H. [1] https://docs.puppetlabs.com/puppet/4.0/reference/release_notes.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1068867 -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Thu, Jun 4, 2015 at 2:21 PM, John Florian john.flor...@dart.biz wrote: 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 As long as it's in /opt, what's the problem? That's what /opt is for! Unwielding and resolving individual components of an integrated tool suite is often a nightmare, which is why puppet, chef, and numerous commercial packages do the same thing. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Puppet 4
On Thu, Jun 4, 2015 at 2:21 PM, Haïkel hgue...@fedoraproject.org wrote: 2015-06-04 20:21 GMT+02:00 John Florian john.flor...@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. I love Fedora and always want Puppet to be a part of it. If something's really broken, please let me know. 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.) 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. If you're willing to contribute packaging it, then I could help you in this task. Regards, H. [1] https://docs.puppetlabs.com/puppet/4.0/reference/release_notes.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1068867 -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Puppet 4
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. :( 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.) [1] https://docs.puppetlabs.com/puppet/4.0/reference/release_notes.html [2] https://bugzilla.redhat.com/show_bug.cgi?id=1068867 -- John Florian -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
