Re: [Puppet Users] Re: [ACTION] Changes to release package links

[Morgan Rhodes]

We're still working on getting repositories set up on
release-archives.puppet.com. You can follow along with progress at
tickets.puppetlabs.com/browse/CPR-685

On Mon, May 20, 2019 at 12:21 PM choffee  wrote:

> So what at the new URL's for PC1 using apt? Just changing the hostname
> does not work, neither does adding the /apt prefix. It looks like the pool
> directory has been copied across but no the dist dir.
>
> The puppetlabs-release-pc1 package is also broken now so there is no
> simple way to install that I can see.
>
> Thanks
>
> john
>
> On Wednesday, 15 May 2019 16:14:00 UTC+1, Bob Vincent wrote:
>>
>> First sign of breakage: https://tickets.puppetlabs.com/browse/BKR-1590
>>
>> Fixed here: https://github.com/puppetlabs/beaker-puppet/pull/113
>>
>> On Monday, May 6, 2019 at 6:16:25 PM UTC-4, Molly Waggett wrote:
>>>
>>> Hey folks,
>>>
>>> REMINDER that the repository path changes* will take effect next week,
>>> on Tuesday, May 14.
>>>
>>> Please make sure any custom tooling using these paths has been updated.
>>>
>>> If you have any questions or concerns, please reply-all to this email.
>>>
>>> Thanks!
>>>
>>> * in case you forgot, changes include:
>>>
>>> 1. yum release packages will be removed from nested directories on
>>> yum.puppet.com (e.g. yum.puppet.com/puppet6/
>>> puppet6-release-el-7.noarch.rpm
>>>
>>> --> yum.puppet.com/puppet6-release-el-7.noarch.rpm).
>>>
>>> PLEASE NOTE that these are actually symlinks to release packages that
>>> live inside their respective repositories, so package updates can be
>>> applied via your package manager, like any other package.
>>>
>>> 2. links to nightly release packages will be removed from {yum,apt}.
>>> puppet.com.
>>> 3. PC1 (and older) packages will be moved to release-archives.puppet.com.
>>> This includes puppet-agent 1.10.x and puppet 4.x.
>>>
>>> On Tue, Apr 23, 2019 at 9:13 AM Molly Waggett 
>>> wrote:
>>>
 Hi John,

 The top-level release packages are actually symlinks to release
 packages that *are* inside their respective repositories. When we
 publish new release packages, we update those links so that users don't
 have to bump version numbers in any tooling that installs these
 repositories.

 Thanks!

 On Tue, Apr 23, 2019 at 6:21 AM jcbollinger 
 wrote:

>
>
> On Monday, April 22, 2019 at 4:31:09 PM UTC-5, Molly Waggett wrote:
>>
>> 1. Release packages (for all active streams) will live at the top
>> level only.
>>
>> This change only affects yum.puppet.com (and nightlies.puppet.com/yum
>> ), giving us consistency with the layout on apt.puppet.com.
>> Currently, yum release packages live inside their corresponding repo
>> directory, e.g. yum.puppet.com/puppet6/
>> puppet6-release-fedora-28.noarch.rpm
>> .
>> THESE WILL BE REMOVED.
>>
>> Here are some examples of where you will be able to find release
>> packages:
>>
>> Old: yum.puppet.com/puppet6/puppet6-release-el-7.noarch.rpm
>>
>> New: yum.puppet.com/puppet6-release-el-7.noarch.rpm
>>
>>
> It is conventional for repository release packages to be inside their
> repositories so that repository configuration updates can be published and
> applied via the same mechanism that is used for ordinary packages.  Even 
> if
> this is a capability that Puppet rarely uses, it seems ill-considered to
> give it up.  The desire for consistency could be as well served by moving
> the other release packages into their repos, or by making the release
> packages consistently  available in both places.
>
>
> John
>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/c711eeca-239c-4022-8f4b-55f9ea577c8d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


 --
 *Molly Waggett*
 she/her/hers
 Release Engineer @ Puppet, Inc.

>>>
>>>
>>> --
>>> *Molly Waggett*
>>> she/her/hers
>>> Release Engineer @ Puppet, Inc.
>>>
>> --
> 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/003ef1cb-1038-4a82-a9ab-8b2921dc999e%40googlegroups.com
> 

Re: [Puppet Users] class invocation conflicts

[Henrik Lindberg]

On 2019-05-20 18:57, Peter Berghold wrote:
So here I am I have a base profile for my Ubuntu (Debian family) 
machines that invokes the class


class{'apt':
     ... some paramters
}

I then invoke the class

class{'postgresql': }

and now Puppet is screaming that the class 'apt' cannot be invoked 
twice.   This seems to be a flaw in Puppet manifests to me.  How to fix?





The best practice is to not use the resource like `class { name: ... }` 
syntax to declare a class and instead use `include name` and letting all 
parameter values come from hiera via automatic parameter lookup.


That way, you can include the class as many times as you like - as the 
parameters are the same every time. Unfortunately, the compiler cannot 
do the same when classes are declared with parameters even if all places 
this is done use the exact same values.


While it is possible to have a single `class { name: ... }` declaration 
with subsequent `include name` declarations, the opposite does not work.


Hope this helps.
- henrik


--

Peter L. Berghold salty.cowd...@gmail.com 

http://devops.berghold.net


--
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/CAArvnv2Ya1Vo1R%3D%2B3YW%3DMp%2BubL%2BZR_WFG1J4o_7OKe33tfm4vw%40mail.gmail.com 
.

For more options, visit https://groups.google.com/d/optout.



--

Visit my Blog "Puppet on the Edge"
http://puppet-on-the-edge.blogspot.se/

--
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/qbuve5%246tlm%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: [ACTION] Changes to release package links

[Greg Delisle]

As of this morning I notice that the old directories have been restored 
under yum.puppetlabs.com -- the el/fedora repos, the puppet-nightly 
directories, the pc1 stuff, everything. 


On Wednesday, May 15, 2019 at 7:04:53 PM UTC-4, Chris Taylor wrote:
>
> Try 
> http://release-archives.puppet.com/yum/el/7/PC1/x86_64/puppetlabs-release-pc1-1.1.0-5.el7.noarch.rpm
>
> Just be aware it will probably install a repo with yum.puppetlabs.com 
> into /etc/yum.repos.d/, so you will need to update the path to the 
> appropriate place.
>
>
> On Wednesday, May 15, 2019 at 11:25:19 PM UTC+1, michael mack wrote:
>>
>> How do you get the following old repo to work?
>>
>> rpm -Uvh 
>> https://yum.puppetlabs.com/puppetlabs-release-pc1-el-7.noarch.rpm
>>
>>
>> On Monday, April 22, 2019 at 2:31:09 PM UTC-7, Molly Waggett wrote:
>>>
>>> TLDR: On May 14, 1. yum release packages will move to the top-level of 
>>> yum.puppet.com; 2. links to nightly release packages will be removed 
>>> from {yum,apt}.puppet.com; and 3. PC1 (and older) packages will be 
>>> moved to release-archives.puppet.com. 
>>>
>>> All Puppet-maintained tooling and documentation referencing these paths 
>>> will be updated by the time these changes are made. Please ensure that 
>>> you are using current versions.
>>>
>>> Read on for details, especially if you've written custom tooling with 
>>> hard-coded download paths (e.g. CI testing or provisioning workflows).
>>>
>>> ---*---*---
>>>
>>> Hey folks,
>>>
>>> In an effort to reduce clutter and confusion on some of our public 
>>> download sites (yum.puppet.com, apt.puppet.com, downloads.puppet.com, 
>>> and nightlies.puppet.com), we are planning to make some changes. 
>>>
>>> 1. Release packages (for all active streams) will live at the top level 
>>> only. 
>>>
>>> This change only affects yum.puppet.com (and nightlies.puppet.com/yum), 
>>> giving us consistency with the layout on apt.puppet.com. Currently, yum 
>>> release packages live inside their corresponding repo directory, e.g. 
>>> yum.puppet.com/puppet6/puppet6-release-fedora-28.noarch.rpm 
>>> . 
>>> THESE WILL BE REMOVED. 
>>>
>>> Here are some examples of where you will be able to find release 
>>> packages:
>>>
>>> Old: yum.puppet.com/puppet6/puppet6-release-el-7.noarch.rpm
>>>
>>> New: yum.puppet.com/puppet6-release-el-7.noarch.rpm
>>>
>>> Old: nightlies.puppet.com/yum/puppet-nightly/
>>> puppet-nightly-release-sles-12.noarch.rpm
>>>
>>> New: nightlies.puppet.com/yum/puppet-nightly-release-sles-12.noarch.rpm
>>>
>>> These new paths are currently available for use. We plan to remove the 
>>> old ones on May 14. Please plan to make all updates during this period. 
>>>
>>> 2. There will be no links to nightlies from main download sites.
>>>
>>> Links like yum.puppet.com/puppet-nightly 
>>>  and 
>>> apt.puppet.com/puppet-nightly 
>>>  WILL BE REMOVED on May 14.
>>>
>>> If you're looking for nightlies, visit nightlies.puppet.com. The 
>>> directory structure will match that of our main download sites.
>>>
>>> 3. All PC1 (and older) packages will be removed from {yum, apt, 
>>> downloads}.puppet.com. 
>>>
>>> PC1 (which includes puppet-agent 1.10.x and puppet 4.10.x) is reaching 
>>> end-of-life, so all packages will be moved to 
>>> release-archives.puppet.com on May 14 and no further updates will be 
>>> made to these streams.
>>>
>>> ---*---*---
>>>
>>> We have set up a temporary s3 bucket that reflects the new layout if 
>>> you’d like to test changes before the cutover:  
>>> yum-test.puppet.com.s3-website-us-west-2.amazonaws.com
>>>
>>> PLEASE NOTE that s3 buckets are not naturally browsable on the web. If 
>>> you visit the above url in your browser, the info you'll see is NOT 
>>> ACCURATE. You CAN, however, download packages via wget/curl/etc. so this 
>>> should only affect human eyes.
>>>
>>> If you have any questions or concerns about these changes, please 
>>> reply-all to this email.
>>>
>>> Thanks!
>>>
>>> -- 
>>> *Molly Waggett*
>>> she/her/hers
>>> Release Engineer @ Puppet, Inc.
>>>
>>

-- 
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/23bf2a97-48bf-4110-a2f9-063f19a14567%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Removing puppet-client-tools from puppet6

[Austin Blatt]

Hi Bram,

We are in the process of retiring puppet-client-tools entirely. Shipping
puppet-client-tools was significant overhead for a package that only
contained the PuppetDB CLI. Also, in an effort to limit the number of
languages we develop in, we have rewritten the PuppetDB CLI in Ruby and
released it as a gem.

On a machine running puppet 6 I recommend installing the PuppetDB CLI via
one of the following commands (depending on which scope you've installed
Puppet in), and ensure whichever path you use for --bindir is also added to
your shell's PATH.

For Puppet installed in its system location
gem install --bindir /opt/puppetlabs/bin puppetdb_cli

For Puppet installed for the current user
gem install --bindir ~/.puppetlabs/bin puppetdb_cli

If the machine is not managed by Puppet, it is also possible to install to
your default Ruby bindir (by omitting the --bindir option entirely) and use
via the puppet-query and puppet-db commands directly.
gem install puppetdb_cli

The documentation for installing puppet-client-tools will be updated
shortly with the new gem installation steps. If you have any problems with
the new PuppetDB CLI please file a PDB ticket in Jira
 so we can get it fixed.

On Thu, May 16, 2019 at 2:54 PM Bram Vogelaar 
wrote:

> hello Molly
>
> have there been any developments with regards to (re-) publishing a puppet
> 6 compatible version of this package?
>
> Bram
>
> On Fri, 5 Apr 2019 at 00:17, Molly Waggett 
> wrote:
>
>> Hey folks!
>>
>> Unfortunately we've had to pull the puppet-client-tools packages from the
>> puppet6 package repositories. These packages were built against puppet5 and
>> are therefore incompatible with the version of OpenSSL used in puppet6.
>>
>> We will republish puppet6-compatible packages soon.
>>
>> Thanks for your understanding!
>>
>> --
>> *Molly Waggett*
>> she/her/hers
>> Release Engineer @ Puppet, Inc.
>>
>> --
>> 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%2BbN-hKiH0H8oCfzDj5GEwc_c%2BSSSVqdpPOrLzxSyKtA%40mail.gmail.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> 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/CAGX-YaJPQrscSpwL5fnGLBxc_QzYcnvAXbqFKB61fXYeeZuaAQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
*Austin Blatt*
Associate Software Engineer
austin.bl...@puppet.com

-- 
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/CADVW12MPnW0qg6DpaXbHirR5HX4ok366FqZ_zB%2B6BukdPsQHyQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: [ACTION] Changes to release package links

[choffee]

So what at the new URL's for PC1 using apt? Just changing the hostname does 
not work, neither does adding the /apt prefix. It looks like the pool 
directory has been copied across but no the dist dir.

The puppetlabs-release-pc1 package is also broken now so there is no simple 
way to install that I can see.

Thanks

john

On Wednesday, 15 May 2019 16:14:00 UTC+1, Bob Vincent wrote:
>
> First sign of breakage: https://tickets.puppetlabs.com/browse/BKR-1590
>
> Fixed here: https://github.com/puppetlabs/beaker-puppet/pull/113
>
> On Monday, May 6, 2019 at 6:16:25 PM UTC-4, Molly Waggett wrote:
>>
>> Hey folks,
>>
>> REMINDER that the repository path changes* will take effect next week, 
>> on Tuesday, May 14.
>>
>> Please make sure any custom tooling using these paths has been updated.
>>
>> If you have any questions or concerns, please reply-all to this email.
>>
>> Thanks!
>>
>> * in case you forgot, changes include:
>>
>> 1. yum release packages will be removed from nested directories on 
>> yum.puppet.com (e.g. yum.puppet.com/puppet6/
>> puppet6-release-el-7.noarch.rpm
>>
>> --> yum.puppet.com/puppet6-release-el-7.noarch.rpm).
>>
>> PLEASE NOTE that these are actually symlinks to release packages that 
>> live inside their respective repositories, so package updates can be 
>> applied via your package manager, like any other package.
>>
>> 2. links to nightly release packages will be removed from {yum,apt}.
>> puppet.com.
>> 3. PC1 (and older) packages will be moved to release-archives.puppet.com. 
>> This includes puppet-agent 1.10.x and puppet 4.x.
>>
>> On Tue, Apr 23, 2019 at 9:13 AM Molly Waggett  
>> wrote:
>>
>>> Hi John,
>>>
>>> The top-level release packages are actually symlinks to release packages 
>>> that *are* inside their respective repositories. When we publish new 
>>> release packages, we update those links so that users don't have to bump 
>>> version numbers in any tooling that installs these repositories.
>>>
>>> Thanks!
>>>
>>> On Tue, Apr 23, 2019 at 6:21 AM jcbollinger  
>>> wrote:
>>>


 On Monday, April 22, 2019 at 4:31:09 PM UTC-5, Molly Waggett wrote:
>
> 1. Release packages (for all active streams) will live at the top 
> level only. 
>
> This change only affects yum.puppet.com (and nightlies.puppet.com/yum), 
> giving us consistency with the layout on apt.puppet.com. Currently, 
> yum release packages live inside their corresponding repo directory, e.g. 
> yum.puppet.com/puppet6/puppet6-release-fedora-28.noarch.rpm 
> . 
> THESE WILL BE REMOVED. 
>
> Here are some examples of where you will be able to find release 
> packages:
>
> Old: yum.puppet.com/puppet6/puppet6-release-el-7.noarch.rpm
>
> New: yum.puppet.com/puppet6-release-el-7.noarch.rpm
>
>
 It is conventional for repository release packages to be inside their 
 repositories so that repository configuration updates can be published and 
 applied via the same mechanism that is used for ordinary packages.  Even 
 if 
 this is a capability that Puppet rarely uses, it seems ill-considered to 
 give it up.  The desire for consistency could be as well served by moving 
 the other release packages into their repos, or by making the release 
 packages consistently  available in both places.


 John

 -- 
 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...@googlegroups.com.
 To view this discussion on the web visit 
 https://groups.google.com/d/msgid/puppet-users/c711eeca-239c-4022-8f4b-55f9ea577c8d%40googlegroups.com
  
 
 .
 For more options, visit https://groups.google.com/d/optout.

>>>
>>>
>>> -- 
>>> *Molly Waggett*
>>> she/her/hers
>>> Release Engineer @ Puppet, Inc.
>>>
>>
>>
>> -- 
>> *Molly Waggett*
>> she/her/hers
>> Release Engineer @ Puppet, Inc.
>>
>

-- 
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/003ef1cb-1038-4a82-a9ab-8b2921dc999e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] class invocation conflicts

[Peter Berghold]

So here I am I have a base profile for my Ubuntu (Debian family) machines
that invokes the class

class{'apt':
... some paramters
}

I then invoke the class

class{'postgresql': }

and now Puppet is screaming that the class 'apt' cannot be invoked twice.
 This seems to be a flaw in Puppet manifests to me.  How to fix?


-- 

Peter L. Berghold   salty.cowd...@gmail.com

http://devops.berghold.net

-- 
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/CAArvnv2Ya1Vo1R%3D%2B3YW%3DMp%2BubL%2BZR_WFG1J4o_7OKe33tfm4vw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] facter to return version of an installed package

[Helmut Schneider]

jcbollinger wrote:

> On Thursday, May 16, 2019 at 10:50:45 AM UTC-5, Helmut Schneider
> wrote:
> 
> > I don't want to install netplan but if it exists do the needful: 
> 
> I reiterate Ben Ford's comments: This is generally considered an 
> anti-pattern.
> 
> It is better from an administrative perspective for you to know which 
> systems are supposed to have netplan, and to unconditionally ensure
> that it is both installed and properly configured on those systems.
> You could go so far as to ensure it absent from other machines,
> though whether that's appropriate is a policy question whose answer
> will vary.  In any case, it is not only reasonable but safer for all
> concerned to demand that the identities of machines for which you are
> going to manage netplan configuration be statically known to you.

I see your point and in 99% of my tasks with Puppet I agree.

> With that said, if you insist on treading this path anyway then a
> custom fact is indeed the right way to convey the wanted information
> to Puppet, whether that's the version of netplan that's installed, if
> any, or merely whether netplan is installed at all.  For that you'll
> want either a fact specific to that purpose (e.g.
> $::netplan_version), or a more general fact from which you can glean
> the information (e.g. $::installed_packages).  There is no way to
> parameterize a fact so that it has different meaning depending on how
> it is evaluated.

Nevertheless knowing what packages are installed might help me, too,
and although my ruby knowledge is very rudimentary here is some output:

#!/usr/bin/ruby

Facter.add('installed_packages') do
  confine :osfamily => /freebsd|debian/

  setcode do
begin
  packages_hash = {}
  if Facter.value(:osfamily) == 'Debian'
packages = Facter::Util::Resolution.exec('/usr/bin/dpkg -l |
/bin/grep ^ii | /usr/bin/awk \'{print $2"|"$3}\'')
  elsif Facter.value(:osfamily) == 'FreeBSD'
packages = Facter::Util::Resolution.exec('/usr/sbin/pkg info |
/usr/bin/awk \'{print $1}\' | /usr/bin/sed -E
\'s#-([[:digit:]])#\|\1#g\'')
  end

  packages.each_line do |package|
if package
  name,*version = package.chomp.split(/\|/)
  packages_hash[name] = version.join("")
end
  end
  packages_hash
rescue
end
  end
end

-- 
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/xn0lu5wgxchwp1000%40news.gmane.org.
For more options, visit https://groups.google.com/d/optout.