[Puppet Users] Puppet agent and non-LTS Ubuntu releases policy change

[Scott Garman]

Hi all,

Some of you have probably noticed that our latest official puppet-agent 
release for Ubuntu was for version 16.10 "Yakkety", which is currently 
end of life and no longer supported. Due to the short lifecycle of 
non-LTS Ubuntu releases (9 months), and the backlog that the Puppet 
Platform OS team is working on, we've made the decision to no longer 
release official puppet-agent builds for non-LTS Ubuntu releases.


I will note however that so far it has been possible to use the LTS 
16.04 "Xenial" puppet-agent package on Ubuntu 17.04 and 17.10, they're 
just not officially supported. This is a workaround that may be useful 
to be aware of until the next LTS release of Ubuntu 18.04 "Bionic" comes 
out in April.


This policy change doesn't impact other platforms that are currently 
supported with a lifecycle of more than 12 months. For example, Fedora 
releases have a 13-month lifecycle, and we intend to keep releasing 
packages for them. Likewise for Debian releases, CentOS/RHEL, etc.


The Platform OS team at Puppet has an ever-growing list of platforms to 
support on an ongoing basis. We believe that focusing our efforts on 
existing platforms with at least a year-long lifecycle will result in 
the greatest return on effort we can offer to the community.


Scott Garman







--
You received this message because you are subscribed to the Google Groups "Puppet 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/13140f25-1373-730e-a757-87af1d991ed7%40puppet.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] puppet5-nightly repos coming soon to nightlies.puppet.com!

[Molly Waggett]

Hello Puppet Users!

We are excited to announce new and improved puppet5-nightly and
puppet-nightly package repositories, which will be rolling out mid-January!

The puppet5-nightly repo will always contain the latest dev builds from
components of Puppet Platform 5 (puppet-agent, puppetserver, and puppetdb),
while puppet-nightly will contain the latest dev builds for the latest
Puppet Platform major version. In other words, puppet-nightly will contain
Platform 6, 7, etc. builds when they are released, but puppet5-nightly will
not go beyond Platform 5.

Previously, nightlies were spread across apt.puppetlabs.com,
yum.puppetlabs.com, and downloads.puppetlabs.com. With this change, we will
consolidate all of the nightly builds in one place: nightlies.puppet.com.
Builds that currently exist on nightlies.puppet.com will be replaced with
these new nightly builds. If you have already downloaded nightly release
packages, you will need to replace them with one pointing at the new
location.

In general, nightly builds will be purged after 30 days.

If you have any questions, please let me know!

Thanks!

-- 
*Molly Waggett*
Assoc. Release Engineer

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAFOE68A_oF-3yapEAbj3Pyon8BBcGjcwL_768Rg0-Nd5MJD1VQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Work-flow for Control-repo in Git

[Barney Garrett]

I've too have been looking at workflow as part of a move to puppet 4 and 
I'm confused to hell and back ;) .

Currently we have a single CA Master and a number of production compilation 
masters and a production puppetdb, there are also a number of test 
compilation masters and a test puppetdb.  We run with essentially 2 
branches, one for production and one for test each being deployed *without 
*r10k 
to their respective compilation servers.  The changes in the production and 
test branches are synchronized using meldmerge.  

Personally I'd like to get away from this model and actually introduce a 
more rigorous peer review process, our software development teams use 
Gerrit and our puppet code is actually in this server we just don't 
currently use the features.  The things I've been reading suggest that 
having long running branches for what people seem refer to as application 
tier (dev, prod, test etc) is bad practice and you should have a single 
main branch with possibly a 2nd one for integration testing.  Work is done 
in short lived branches that are merged into the main line when the work is 
complete.  Membership of dev, prod, test etc is determined by facts on the 
node.

There are still some issues I don't really understand though.  It would 
appear that puppetdb doesn't support environments all that well either so 
it would follow that assuming we want to maintain a production and test 
estate for the servers we are maintaining then from a puppet infrastructure 
perspective you'd still have a Puppet CA, a number of production 
compilation servers with a puppetdb, and a number of test compilation 
servers with its own puppetdb.  Either of these could have multiple 
temporary environments deployed on them (hotfix branches on the prod 
compilation servers and feature branches on the test compilation servers) 
but ultimately each main application tier (prod or test) is actually 
deployed from the same branch but from different points in time.  
Unfortunately it would appear r10k doesn't support looking at a specific 
tag of the control repo so not sure how you'd work round that either.

Am I just being naive and foolish or is this kind of workflow possible or 
even desirable ?

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/b0ceac18-cc41-49b8-829a-c7a581f44ac6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Managing puppet module

[David Schmitt]

Hi Albert,



On Tue, Dec 26, 2017 at 11:22 AM Albert Shih  wrote:

> Le 14/12/2017 à 08:50:38+, David Schmitt a écrit
> Hi,
>
> Really sorry for not answering you sooner.
>
> >
> > I tested this quickly on my system and it seems to work fine here. Can
> you
> > share more details (puppet version, other installed modules) of your
> system?
>
> Well...in fact because I really need a feature in puppetlabs-apt 4.x, I
> force the upgrade and everything seem to work well.
>
> But thanks for your answer I will keep it in mind.
>
> Just one question : Where come from your bundle ? Is it come from some rvm
> ? or just the
> bundle from the system your on.
>

I'm running debian testing, and for generic ruby development, I use the
system's ruby (2.3.3). You should be able to use the pdk's bundle
subcommand in the same way.


Cheers, David

>
> Regards.
>
>
> >
> > david@davids:~/git/tmp/foo$ bundle exec puppet module install
> puppetlabs-apt
> > --version 2.4.0
> > Notice: Preparing to install into /home/david/.puppet/modules ...
> > Notice: Created target directory /home/david/.puppet/modules
> > Notice: Downloading from https://forgeapi.puppetlabs.com ...
> > Notice: Installing -- do not interrupt ...
> > /home/david/.puppet/modules
> > └─┬ puppetlabs-apt (v2.4.0)
> >   └── puppetlabs-stdlib (v4.24.0)
> > david@davids:~/git/tmp/foo$ bundle exec puppet module upgrade
> puppetlabs-apt
> > Notice: Preparing to upgrade 'puppetlabs-apt' ...
> > Notice: Found 'puppetlabs-apt' (v2.4.0) in /home/david/.puppet/modules
> ...
> > Notice: Downloading from https://forgeapi.puppetlabs.com ...
> > Notice: Upgrading -- do not interrupt ...
> > /home/david/.puppet/modules
> > └── puppetlabs-apt (v2.4.0 -> v4.4.1)
> > david@davids:~/git/tmp/foo$ bundle exec puppet module list
> > /home/david/.puppet/modules
> > ├── puppetlabs-apt (v4.4.1)
> > └── puppetlabs-stdlib (v4.24.0)
> > david@davids:~/git/tmp/foo$
> >
> > Puppet 4:
> >
> > david@davids:~/git/tmp/foo$ bundle exec puppet module install
> puppetlabs-apt
> > --version 2.4.0
> > Notice: Preparing to install into
> /home/david/.puppetlabs/etc/code/modules ...
> > Notice: Created target directory /home/david/.puppetlabs/etc/code/modules
> > Notice: Downloading from https://forgeapi.puppet.com ...
> > Notice: Installing -- do not interrupt ...
> > /home/david/.puppetlabs/etc/code/modules
> > └─┬ puppetlabs-apt (v2.4.0)
> >   └── puppetlabs-stdlib (v4.24.0)
> > david@davids:~/git/tmp/foo$ bundle exec puppet module upgrade
> puppetlabs-apt
> > Notice: Preparing to upgrade 'puppetlabs-apt' ...
> > Notice: Found 'puppetlabs-apt' (v2.4.0) in
> /home/david/.puppetlabs/etc/code/
> > modules ...
> > Notice: Downloading from https://forgeapi.puppet.com ...
> > Notice: Upgrading -- do not interrupt ...
> > /home/david/.puppetlabs/etc/code/modules
> > └── puppetlabs-apt (v2.4.0 -> v4.4.1)
> > david@davids:~/git/tmp/foo$ bundle exec puppet module list
> > /home/david/.puppetlabs/etc/code/modules
> > ├── puppetlabs-apt (v4.4.1)
> > └── puppetlabs-stdlib (v4.24.0)
> > /opt/puppetlabs/puppet/modules (no modules installed)
> > david@davids:~/git/tmp/foo$
> >
> >
> > Puppet 5:
> >
> > david@davids:~/git/tmp/foo$ bundle exec puppet module install
> puppetlabs-apt
> > --version 2.4.0
> > Notice: Preparing to install into
> /home/david/.puppetlabs/etc/code/modules ...
> > Notice: Created target directory /home/david/.puppetlabs/etc/code/modules
> > Notice: Downloading from https://forgeapi.puppet.com ...
> > Notice: VersionRanges will always be strict when using non-vendored
> > SemanticPuppet gem, version 1.0.1
> > Notice: Installing -- do not interrupt ...
> > /home/david/.puppetlabs/etc/code/modules
> > └─┬ puppetlabs-apt (v2.4.0)
> >   └── puppetlabs-stdlib (v4.24.0)
> > david@davids:~/git/tmp/foo$ bundle exec puppet module upgrade
> puppetlabs-apt
> > Notice: Preparing to upgrade 'puppetlabs-apt' ...
> > Notice: Found 'puppetlabs-apt' (v2.4.0) in
> /home/david/.puppetlabs/etc/code/
> > modules ...
> > Notice: VersionRanges will always be strict when using non-vendored
> > SemanticPuppet gem, version 1.0.1
> > Notice: Downloading from https://forgeapi.puppet.com ...
> > Notice: Upgrading -- do not interrupt ...
> > /home/david/.puppetlabs/etc/code/modules
> > └── puppetlabs-apt (v2.4.0 -> v4.4.1)
> > david@davids:~/git/tmp/foo$ bundle exec puppet module list
> > Notice: VersionRanges will always be strict when using non-vendored
> > SemanticPuppet gem, version 1.0.1
> > /home/david/.puppetlabs/etc/code/modules
> > ├── puppetlabs-apt (v4.4.1)
> > └── puppetlabs-stdlib (v4.24.0)
> > /opt/puppetlabs/puppet/modules (no modules installed)
> > david@davids:~/git/tmp/foo$
> >
> >
> > On Wed, Dec 13, 2017 at 1:26 PM Albert Shih 
> wrote:
> >
> > Hi everyone.
> >
> > I'm not sure if it's a bug or what. Here what puppet module list
> give me :
> >
> > ├── puppetlabs-apt (v2.4.0)
> > ├── puppetlabs-stdlib (v4.24.0)
> >
> > but if I try to