Date   
Re: Get rid of Puppet4?

David Hollinger
 

Yeah I think >=4.10.x is a good target - there aren't any earlier 4.x series releases that are getting patches, since 4.10.x is the 'last of the line' before 5. It is a very short step from 4.10.x to 5 too, so i'd suggest being generous about dropping 4.x compatibility unless you *know* a module uses some 5.x-only construct.

This is in no way an official Puppet Inc statement but I suspect there will be a longer tail to 4.10 than just October 2018, given its inclusion in Satellite and widespread use out in the world.
Thanks for the input, Eric. With this I think we can justify reducing our support range down to >= 4.10.

--dhollinger

Re: Get rid of Puppet4?

 

On 21.03.2018 19:32, Eric Sorenson wrote:
Hi all, good to see this thread - I put some comments inline.

On Mar 21, 2018, at 2:45 AM, Tim Meusel <@bastelfreak> wrote:
On 03/21/2018 10:39 AM, Ewoud Kohl van Wijngaarden wrote:
On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet
Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list:
https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
Satellite 6.3 just came out and it includes Puppet 4.10.9 so I'd be
happy if we continued to support it. Dropping anything older would be
fine by me. I think that aligns with the PE versions.
I agree. I'm fine with supporting 4.10.X until it's EOL (october?). But
we should not support anything that's EOL. As a module author we act as
a software "vendor" to or users, we're responsible for them. We should
not encourage them to run outdated software. We should also point out
that people are not required to update their local module version, just
because we released a newer version.

I wrote that many times in issues and pull requests. I just realized
that our Puppet 4.7.1 is now EOL as well and we should maybe bump the
puppet version in all modules to at least 4.10.X? No matter if they use
data-in-modules or not.
Yeah I think >=4.10.x is a good target - there aren't any earlier 4.x series releases that are getting patches, since 4.10.x is the 'last of the line' before 5. It is a very short step from 4.10.x to 5 too, so i'd suggest being generous about dropping 4.x compatibility unless you *know* a module uses some 5.x-only construct.
sounds good

This is in no way an official Puppet Inc statement but I suspect there will be a longer tail to 4.10 than just October 2018, given its inclusion in Satellite and widespread use out in the world.


But I don't think you can create a policy that fits for every
voxpupuli module. For some modules it maybe makes sense to support
older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.
Does it work to make a new major version of the module that has tighter compatibility constraints? I think we talked about this as a community in the 3.x->4.x timeframe but I'm not sure how it's played out in reality. Do most downstream users pin versions to avoid breakage?
We made that, in my opinion with quite a success, for the migration from
3.X to 4.7.1. We had some discussions about minor updates of a
dependency (mostly stdlib and/or puppet). Does that require a major
update of the module? In rare cases we said yes, in most cases no. The
general feedback for the Puppet 3-4 migration was good. Only a few users
complaint that the latest release isn't compatible with their puppet3
env. They didn't check the CHANGELOG.md properly. For most of those
releases we did a minor one to announce that the upcoming major one
doesn't work with Puppet 3 anymore.

--eric0




Re: Get rid of Puppet4?

Eric Sorenson <eric@...>
 

Hi all, good to see this thread - I put some comments inline.

On Mar 21, 2018, at 2:45 AM, Tim Meusel <@bastelfreak> wrote:
On 03/21/2018 10:39 AM, Ewoud Kohl van Wijngaarden wrote:
On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet
Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list:
https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
Satellite 6.3 just came out and it includes Puppet 4.10.9 so I'd be
happy if we continued to support it. Dropping anything older would be
fine by me. I think that aligns with the PE versions.
I agree. I'm fine with supporting 4.10.X until it's EOL (october?). But
we should not support anything that's EOL. As a module author we act as
a software "vendor" to or users, we're responsible for them. We should
not encourage them to run outdated software. We should also point out
that people are not required to update their local module version, just
because we released a newer version.

I wrote that many times in issues and pull requests. I just realized
that our Puppet 4.7.1 is now EOL as well and we should maybe bump the
puppet version in all modules to at least 4.10.X? No matter if they use
data-in-modules or not.
Yeah I think >=4.10.x is a good target - there aren't any earlier 4.x series releases that are getting patches, since 4.10.x is the 'last of the line' before 5. It is a very short step from 4.10.x to 5 too, so i'd suggest being generous about dropping 4.x compatibility unless you *know* a module uses some 5.x-only construct.

This is in no way an official Puppet Inc statement but I suspect there will be a longer tail to 4.10 than just October 2018, given its inclusion in Satellite and widespread use out in the world.


But I don't think you can create a policy that fits for every
voxpupuli module. For some modules it maybe makes sense to support
older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.
Does it work to make a new major version of the module that has tighter compatibility constraints? I think we talked about this as a community in the 3.x->4.x timeframe but I'm not sure how it's played out in reality. Do most downstream users pin versions to avoid breakage?

--eric0

Re: Get rid of Puppet4?

James Powis
 

I have mixed feelings on this, Just back in January I migrated a Client from 3.6 to 5 ... On one hand support can be maintained at a cost to the maintainers, mean while pinning versions and revving major versions is perfectly acceptable in my book... I have now worked at 3 different shops using puppet to varying degrees of success, but every one of them have pinned version of the external modules they were using (after learning the hard way first). 

At a bare minimum, mirroring the PE LTS EOL dates would be recommended.

Thanks,

James R. Powis



On Wed, Mar 21, 2018 at 2:50 AM, Tim Meusel <tim@...> wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.

I would like to get feedback from the community here. Do you think it is
still needed to support puppet 4 at all? Is 4.10 even to high as the
lowest version?

My point of view is that upgrades, since the AIO packages are available,
are really easy and everybody should be able to regularly update their
nodes. Dropping Puppet 4 would allow us to reduce the test matrix and
speed CI runs up. Also we would be safe with data-in-modules/hiera5. We
also need to keep in mind that not everybody is required to update their
used modules to the latest version, just because they are available.

The trigger for this was
https://github.com/camptocamp/puppet-systemd/pull/73. What are your
opinions on this topic?

Cheers, Tim





Re: Get rid of Puppet4?

David Hollinger
 

I'm with Thomas on this, we should always have the same support matrix as Puppet, Inc.
Many of our users will be relying on their support lifecycle and for us to stay relevant within Puppet world,
we need to ensure that we don't make it too hard for users to utilize our tools.

While it does appear that 4.7.1 would be EOL based on the patch releases for PE 2016.4, the support lifecycle
lists the minor release as the supported version. I almost think we need some feedback from Hunner and Eputnam
before we make any decisions.

Regardless, I'm strongly against dropping support for any version that Puppet, Inc still provides support for.

Re: Get rid of Puppet4?

 

On 03/21/2018 10:39 AM, Ewoud Kohl van Wijngaarden wrote:
On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet
Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list:
https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
Satellite 6.3 just came out and it includes Puppet 4.10.9 so I'd be
happy if we continued to support it. Dropping anything older would be
fine by me. I think that aligns with the PE versions.
I agree. I'm fine with supporting 4.10.X until it's EOL (october?). But
we should not support anything that's EOL. As a module author we act as
a software "vendor" to or users, we're responsible for them. We should
not encourage them to run outdated software. We should also point out
that people are not required to update their local module version, just
because we released a newer version.

I wrote that many times in issues and pull requests. I just realized
that our Puppet 4.7.1 is now EOL as well and we should maybe bump the
puppet version in all modules to at least 4.10.X? No matter if they use
data-in-modules or not.

But I don't think you can create a policy that fits for every
voxpupuli module. For some modules it maybe makes sense to support
older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.


Re: Get rid of Puppet4?

Ewoud Kohl van Wijngaarden
 

On Wed, Mar 21, 2018 at 09:58:20AM +0100, Thomas Mueller wrote:
On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list: https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x
Satellite 6.3 just came out and it includes Puppet 4.10.9 so I'd be happy if we continued to support it. Dropping anything older would be fine by me. I think that aligns with the PE versions.

But I don't think you can create a policy that fits for every voxpupuli module. For some modules it maybe makes sense to support older puppet and for others not.
Even if it's not a policy, some guidelines are good to have.

Re: Get rid of Puppet4?

Thomas Mueller <thomas@...>
 

On 03/21/2018 09:50 AM, Tim Meusel wrote:
Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.
Voxpupuli should generally support puppet versions supported by Puppet Inc.

Lifecycle: https://puppet.com/misc/puppet-enterprise-lifecycle
Oldest supported PE release: 2016.04
Component list: https://puppet.com/docs/pe/2016.4/overview_version_table.html

Oldest supported Puppet version: 4.10.x

But I don't think you can create a policy that fits for every voxpupuli module. For some modules it maybe makes sense to support older puppet and for others not.

- Thomas

Get rid of Puppet4?

 

Hi everybody,

Puppet 5 is available since a long time. Besides many bug fixes it also
has support for hiera 5 configs as data-in-modules. Some time ago in the
IRC channel we agreed on Puppet 4.7.1 as our lowest supported Puppet
version and at least Stdlib 4.13.1. A few of our modules ship
data-in-modules with hiera 5. This got introduced in Puppet 4.8(?) but
had some bugs. The agreement, and recommendation by Puppet, was to
require at least Puppet 4.10.X in those cases.

I would like to get feedback from the community here. Do you think it is
still needed to support puppet 4 at all? Is 4.10 even to high as the
lowest version?

My point of view is that upgrades, since the AIO packages are available,
are really easy and everybody should be able to regularly update their
nodes. Dropping Puppet 4 would allow us to reduce the test matrix and
speed CI runs up. Also we would be safe with data-in-modules/hiera5. We
also need to keep in mind that not everybody is required to update their
used modules to the latest version, just because they are available.

The trigger for this was
https://github.com/camptocamp/puppet-systemd/pull/73. What are your
opinions on this topic?

Cheers, Tim

Re: Modules migration to voxpupuli ?

 

Hi Sebastien,

thanks for reaching out to us. Can you join our IRC channel #voxpupuli
on freenode? That allows us to easily discuss the migration process.

Cheers, Tim

On 08.03.2018 00:12, Sebastien Badia wrote:
Hello voxpupuli!

If it's okay, I would like to move my puppet modules to voxpupuli.

allknowingdns, bird and dropbear may be good candidates :)

https://forge.puppet.com/sbadia

Thanks in advance,

Seb


Modules migration to voxpupuli ?

Sebastien Badia <seb@...>
 

Hello voxpupuli!

If it's okay, I would like to move my puppet modules to voxpupuli.

allknowingdns, bird and dropbear may be good candidates :)

https://forge.puppet.com/sbadia

Thanks in advance,

Seb

Re: Zabbix server not importing exported resources from zabbix agents

Brian Schonecker <bschonec@...>
 

On recommendation of a few people on the IRC who are much smarter than I, auto-discovery on the server is the preferred method and NOT using exported resources.

Thanks, Brian

Re: Zabbix server not importing exported resources from zabbix agents

Brian Schonecker <bschonec@...>
 

I'm getting closer.  I was hit by the chicken-egg issue described here:


However, now on my Zabbix server I see the following error:

Error: /Stage[main]/Zabbix::Resources::Agent/Zabbix_host[example.com]: Could not evaluate: Zabbix API version: 3.4.7 is not support by this version of zabbixapi

I've gone through the code but I don't see anywhere where zabbixapi versions are called out.


/opt/puppetlabs/puppet/bin/gem list zabbixapi

*** LOCAL GEMS ***

zabbixapi (3.2.1)




Thanks, Brian

Re: Zabbix server not importing exported resources from zabbix agents

bschonec@...
 

I've looked through the Postgres Database on the PuppetDB server and I am seeing Zabbix_host in the "type" column for the catalog_resources table.  I can only assume that the zabbix_host resource in https://github.com/voxpupuli/puppet-zabbix/blob/master/manifests/resources/agent.pp is being exported correctly.  Perhaps there's something wrong on the Zabbix server.  I've got SELinux to permissive mode.

Brian

On Fri, Mar 2, 2018 at 9:31 AM, <bschonec@...> wrote:
I'm having trouble getting the puppet zabbix server module importing zabbix::agent hosts into the server.  I have manage resources turned on and I know exported resources are working because other exported resources *are* being managed on the zabbix server (ssh keys for example).  My PuppetDB server seems to be working just fine.

Am I missing something other than: https://gist.github.com/bschonec/36fc2b0d73b9916ab8adb4dd400e2580


The zabbix server is running just fine but it isn't importing the resources into its configuration.  I've noticed, too, that the zabbix server shows all the agents unavailable even when I create the agents manually.  I'm sure that's not related but I want to give as much information as possible.


Zabbix server not importing exported resources from zabbix agents

bschonec@...
 

I'm having trouble getting the puppet zabbix server module importing zabbix::agent hosts into the server.  I have manage resources turned on and I know exported resources are working because other exported resources *are* being managed on the zabbix server (ssh keys for example).  My PuppetDB server seems to be working just fine.

Am I missing something other than: https://gist.github.com/bschonec/36fc2b0d73b9916ab8adb4dd400e2580


The zabbix server is running just fine but it isn't importing the resources into its configuration.  I've noticed, too, that the zabbix server shows all the agents unavailable even when I create the agents manually.  I'm sure that's not related but I want to give as much information as possible.

Re: Adopt hiera-eyaml-gpg backend into voxpupuli?

Rob Nelson
 

Simon,

I think we would be interested in that. I know hiera-eyaml is moving faster than it was with just one person on it, and the projects are very important to the ecosystem.

As you may have noticed, hiera-eyaml's transfer has not been as smooth as could be. Since both projects deal with cryptography, we have a much smaller pool of people to assist with them and a smaller pool of users to help test. Would you be willing to help us get the first VP-backed release out the door? That would involve us maybe applying our standards (rubocop and readme/contributing docs mainly) and then going through the backlog to see what needs taken care of before a release. It looks like you only have 16/1 issues/PRs open, so that seems less intimidating than hiera-eyaml's backlog during the transfer. We might need some assistance setting up a test environment so non-users can test patches effectively. I am sure we can do the work, we just need the direction to know where to start. Is that something you could assist with for a transfer?


Rob Nelson
rnelson0@...

On Thu, Mar 1, 2018 at 4:32 PM, Simon Hildrew <simon@...> wrote:
Hi all,

I was one of the original contributors to hiera-eyaml (mainly the edit command) and am the author of the gpg backend. I'm no longer using puppet/hiera in my day job and regret that I'm not able to find time to give the backend the love it needs - specifically I think it needs some changes to work with the latest versions of hiera.

I'd be interested to know if there is any appetite to adopt this project in the same way that hiera-eyaml was adopted?

Kind regards,
Simon

--
Simon Hildrew
simon@...


Adopt hiera-eyaml-gpg backend into voxpupuli?

Simon Hildrew <simon@...>
 

Hi all,

I was one of the original contributors to hiera-eyaml (mainly the edit command) and am the author of the gpg backend. I'm no longer using puppet/hiera in my day job and regret that I'm not able to find time to give the backend the love it needs - specifically I think it needs some changes to work with the latest versions of hiera.

I'd be interested to know if there is any appetite to adopt this project in the same way that hiera-eyaml was adopted?

Kind regards,
Simon

--
Simon Hildrew
simon@...

FOR REVIEW: puppet strings style guide

Jean Bond (via Google Docs)
 

Jean Bond has shared a link to the following document:
Sender's profile photoHello!

We've drafted some initial style guidelines for Puppet Strings, and we would love to get your feedback.

We would like to hear from you whether you find these guidelines clear, helpful, and reasonable. They aren't too extensive, but we just want to be able to provide a resource to help folks use Strings. Please feel free to make comments and suggestions on this Google doc.

Disclaimers: This doc refers to some functionality that doesn't exist in the current Strings release, but that we are working on now. Don't be sad if your version of Strings doesn't do all the things. This is only one part of planned documentation; how-to stuff isn't in this doc.

If you would like to comment, please do so by 1 March. Thank you so much for your help!

Best,

Jean Bond
Sr. Technical Writer
Puppet
Google Docs: Create and edit documents online.
Google LLC, 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA
You have received this email because someone shared a document with you from Google Docs.
Logo for Google Docs

RabbitMQ user credential encryption

Xinhuan Zheng <xzheng@...>
 

Hello,

I have setup my RabbitMQ environment using Puppet rabbitmq module. It worked great. However, per document from https://forge.puppet.com/puppet/rabbitmq, the example user has clear plain text. I did the same way but it does not comply security standard. Per RabbitMQ document, http://www.rabbitmq.com/configure.html#configuration-encryption, the sensitive information is possible to be encrypted using Erlang tuple. How do I do that with your rabbitmq Puppet module?
Thank you,

- Xinhuan

Re: Puppet forge module management

James Powis
 

Xinhuan,

You would define all of your modules in the Puppetfile (from forge, from github, and from your private repository).

While there is the Puppet Module called R10k which handles much of the r10k configuration on your master, it is unneeded so long as you have all the supporting files present on the master. In actuality the r10k command is provided via a Ruby Gem and is manually executed.

Fair warning that migrating from a monolithic repository to a fully managed r10k method with directory environments will take some downtime and a bit of a learning curve.

To prepare for such a change I would recommend the following procedure:

  1. Start with a code freeze. Lock the Monolithic repository hosting all of your modules. This prevents accidental config drift as you implement R10k.
  2. Backup your puppet master (specifically /etc/puppetlabs/code/environments)
  3. Remove everything in  /etc/puppetlabs/code/environments, R10k will manage the contents of this directory completely.
  4. Split every private puppet module off into its own repository.
  5. Create a repository called "control-repo" but ensure your default branch is production and you do not have a master branch. This will host the Puppetfile and Hieradata (copy this repo: https://github.com/puppetlabs/control-repo if you are on puppet 5 otherwise use https://github.com/puppetlabs/control-repo/tree/55f983ffc9e6e92113ceea0bc51efb6b69d32f13)
    1. Copy your hieradata into data (if on puppet5) otherwise copy into hieradata
    2. Update the Puppetfile to include modules from the forge (at the top of the example file), making sure you pin to whatever version you require
    3. Update the Puppetfile to include modules from github (at the bottom of the example file),  making sure you pin to whatever version or commit id you require.
    4. Add your private modules repos using this example https://ask.puppet.com/question/15236/can-you-use-r10k-to-deploy-from-a-private-repo/
    5. If you have multiple puppet environments being managed by your master, then each one will be represented by a different branch of the control-repo which matches the name of the environment
  6. Configure ssh deploy keys so you can pull from the repositories for each of your private modules and your control-repo.
  7. Configure r10k via /etc/puppetlabs/puppet/r10k.yaml (see: https://github.com/puppetlabs/r10k/blob/master/r10k.yaml.example)
  8. run `r10k deploy -pv` and if everything works out you should see all the modules you defined in the Puppetfile present in each environment.

Thanks,

James R. Powis



On Wed, Feb 7, 2018 at 5:28 AM, Xinhuan Zheng <xzheng@...> wrote:
Hello James,

Thanks for providing me this valuable information. I think using Puppetfile to manage forge modules is great. I'm still not clear as r10k appears to be a Puppet module installed on Puppetmaster. Does it keep its managed forge repositories up-to-date with upstream by each time Puppet run on Puppet master?

Also how do I let r10k know that it is only responsible for managing forge upstream modules, but not local module I wrote?