[Puppet Users] Re: [Puppet-dev] Availability of Facter 4 nightly gems

[David Schmitt]

Are these also fed into the nightly agent builds, or do I need additional
steps to get nightly facter on top of a nightly agent build?

On Thu, 20 May 2021 at 13:40, Gabriel Nagy  wrote:

> Hello,
>
> We are happy to announce that Facter 4 nightly gems are now available to
> use under http://nightlies.puppet.com/downloads/gems/facter-nightly/
> We highly encourage folks who are interested in the latest Facter 4
> features and fixes to try out the builds. Please note that nightly builds
> come with a degree of instability, but it's the best way to test out
> features that have not yet been officially released.
>
> As always, we welcome your feedback either on the #puppet Slack channel (
> slack.puppet.com), and if you find any issues please open a ticket on our
> JIRA under the FACT project: http://tickets.puppetlabs.com/browse/FACT
>
> Gabriel Nagy
> Software Engineer - Puppet
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAALo1wFET5PLKm7u0q%2BNfjzKEX%3DBN%2BHjrLwMWAivsm7-ceUQLA%40mail.gmail.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/CALF7fHa3WdG9%3DDfFSD7_yGQb7NDK%2BDCio5GywxdOXN9RDEouEA%40mail.gmail.com.

Re: [Puppet Users] Re: rspec, trusted facts, and node facts

[David Schmitt]

Did you see https://rspec-puppet.com/ ?

On Thu, 25 Mar 2021 at 18:00, nand...@gmail.com  wrote:

> Hi all ,
> I have started my rspec code to test modules for unit testing .as there is
> no good document to start with ,  Can you share some of your rspec code
> testing the modules using rspec and steps to run spec against servers ,
>
> Regards,
> Nandha
>
> On Friday, 6 April 2018 at 20:00:49 UTC+5:30 jcbollinger wrote:
>
>>
>>
>> On Friday, April 6, 2018 at 9:19:04 AM UTC-5, Nick Miller wrote:
>>>
>>> There was some discussion on a GitHub issue relating to this:
>>> https://github.com/rodjek/rspec-puppet/pull/643
>>>
>>>
>> Thanks, NIck.  It looks like I've finally got this sorted.  I went back
>> to twiddling the trusted_node_data and derive_node_facts_from_nodename
>> rspec-puppet parameters, tweaked the tests, and made some spelling
>> corrections in the class under test.  My tests are now passing, and I'm
>> satisfied that I understand why.
>>
>> Cheers,
>>
>> 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-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/ddf8c041-7e44-4e2b-b381-8f8e9c48e422n%40googlegroups.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/CALF7fHaZnnVKafvQtxf9ti9XvNeJwjzAVA9xgyKr7jvDwn%2BWWA%40mail.gmail.com.

Re: [Puppet Users] Re: [INFO, maybe ACTION] r10k Feature Proposal

[David Schmitt]

The PDK by default is ignoring all of those directories (
https://github.com/puppetlabs/pdk-templates/blob/7be43a3903e798ae72095379ed3f8d9187416ff2/config_defaults.yml#L47-L65)
when building modules.

On Tue, 16 Mar 2021 at 23:07, Corey Osman  wrote:

> Why stop at the spec directory?  Ignore all those other pesky files too
> that pdk and others leave behind.  Gemfile*  *.travis, *.gitlab-ci,
> *.ignore, ...
>
> On Thursday, March 11, 2021 at 4:04:38 PM UTC-8 Molly Waggett wrote:
>
>> Hey folks!
>>
>> We are planning an r10k feature to stop deploying module spec
>> directories. This will lower disk usage, particularly for folks with a lot
>> of modules and multiple compilers.
>>
>> Our hope is to enable this behavior by default, but leave the option to
>> opt out (i.e. continue including spec directories when deploying
>> modules). This is based on the assumption that most folks have no need for
>> module spec directories in a production environment, since they
>> typically just include testing materials for module development.
>>
>> If you think this assumption is inaccurate, or even if it’s just
>> inaccurate for you, please let us know! If we don’t hear any objections by 
>> Tuesday,
>> March 23, we will proceed with the above plan to adopt this behavior but
>> include a way to opt out.
>>
>> If you have any questions, please reply to this email or ping @r10k in
>> the Puppet Community Slack .
>>
>> Thanks!
>>
>> --
>> *Molly Waggett*
>> she/her
>> Senior Software Engineer @ Puppet
>>
> --
> 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/30a3ca9f-3fc3-408e-8776-0e46a17ac96dn%40googlegroups.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/CALF7fHbi2v7Ysdj9tC3R8Bci9N-vNUUL%3DbdeeEJawsfEVkU2wg%40mail.gmail.com.

Re: [Puppet Users] Transaction style resources

[David Schmitt]

The Palo Alto module  is a
good example for talking to an API. It also contains panos_commit

which activates all collected config changes that were already uploaded to
the device. That's maybe not exactly what you're looking for, but it's the
closest example I have.

On Tue, 10 Nov 2020 at 23:28, juliogu...@gmail.com <
julioguevara...@gmail.com> wrote:

> Hi all,
>
> Currently I'm working of implementing some puppet types and providers that
> will talk with a RESTful API that support transaction style queueing of
> requests.
> Just like in SQL you can BEGIN a transaction, put a lot of changes on the
> transaction and COMMIT all of them as a single unit.
>
> I have implemented custom types and providers before, but have never come
> across cases like this.
> Does anybody has some examples of something similar to this?
> Does puppet can even support this type of workflow?
>
> Any idea, suggestion, tip is more than welcome!
> Julio
>
> --
> 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/7a5f12a8-8442-4d9b-92f4-56e0ea6607c5n%40googlegroups.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/CALF7fHaBJBOPqOc_gX6Dr8Nd-LGy7EbBjieK7SC9XmDUzZgXGw%40mail.gmail.com.

Re: [Puppet Users] Error while installing the docker on Ubuntu 18.04 using existing puppet forge module

[David Schmitt]

For automatic installation from upstream sources. the module reaches out to
https://apt.dockerproject.org/ to retrieve the repo keys. Please make sure
that is accessible to your puppet agent. If that is not possible in your
organisation, please follow the documentation to find the overrides to
configure installation from a local mirror.


Cheers, David


On Thu, 25 Jun 2020 at 09:38, Vinay Korrapati  wrote:

> Hi Team,
>
> We are facing the below issue while installing the docker Ubuntu 18.04
> using existing puppet forge module. we already added the include 'docker'
> to the manifest file. And all dependent modules also installed.
>
> *Error:*
> *change from 'absent' to 'present' failed: Could not set 'present' on
> ensure: SSL_connect SYSCALL returned=5 errno=0 state=SSLv3/TLS write client
> hello (file:
> /etc/puppetlabs/code/environments/production/site/apt/manifests/key.pp,
> line: 55)*
>
>
> *Puppet Version:* 6.14.0
> *Link referred:* https://forge.puppet.com/puppetlabs/docker#images
>
>
> Any firewall need to be white list at server end ? could you please
> suggest me to address the issue.
>
>
> Regards
> Vinay
>
> --
> 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/aefc16d3-eaee-46dc-a5de-d5ea9a13aa5co%40googlegroups.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/CALF7fHa95L%3DD%2BcnTrKH%3D%2B6RbzGfka9MmocrpLvgZOrC_K5SkEA%40mail.gmail.com.

Re: [Puppet Users] Install software by running script

[David Schmitt]

To answer the original question: when a software vendor delivers software
that does not conform to your distributions native packaging format, invest
some time in the excellent FPM  tool
that can build native packages for your local environment. Injecting the
complexity of dragging a vendor's ... err ... prioritisation decisions into
your production systems is really only the last resort if you can't get it
to work *any* other way.



On Tue, 14 Apr 2020 at 12:53, Andy Hall  wrote:

> exactly just push the devs of the package resource type to add a new
> provider. I mean nodejs is kinds popular now so I see no reason not to add
> it...
>

If I may chime in as one of the devs of the package resource type:

My understanding is that - like ruby and python - only very few people
actually use the system installed version of npm and npm packages. Instead
the default workflow uses custom installs and multiple "virtual"
environments stashed away in their application directories. At least for
ruby and python this makes the main package providers practically unusable
because they either
* interfere with system-packaged gems/packages/modules
or
* can't detect which virtual environment to use
or - if we were to magically solve enumerating virtual environments on the
systems
* find multiple versions of the same package and confuse puppet even more

See the puppet_gem and puppetserver_gem for ways this has been "fixed" for
ruby gems. Both of which are very application-specific workarounds for
those problems that are not  generalizable.

I hope this provides enough reasons why this won't get added any time soon.


Cheers, David

>
> On Tuesday, April 14, 2020 at 7:04:46 AM UTC+1, Dirk Heinrichs wrote:
>>
>> Am Samstag, den 11.04.2020, 12:15 +0200 schrieb Martin Alfke:
>>
>> Of course for just pip/bundle/etc. I can do something like
>>
>>   exec { 'install':
>> command => 'pip/bundle/npm install',
>> creates => 'some file created by the pip/bundle/npm
>> }
>>
>> but still it's painful because if the pip/bundle/npm failed the exec would
>> not be execute again, unless you put every file create by the 1
>> dependencies need for every software.
>>
>> The worst case for me is those software installed by some
>>
>>   wget 'URL' | sh
>>
>> (Ok I know it's not secure...) but well...
>>
>>
>> The same pattern: let the wget | sudo bash command run on a dev platform
>> or a container and build a package.
>>
>>
>> Either this, or: Write a package provider, like the ones already
>> available for Ruby gems or Python modules, which turns this into
>>
>> package { 'foo':
>> ...
>> provider => npm,
>> ...
>> }
>>
>>
>> Bye...
>>
>> Dirk
>>
>> --
>>
>> *Dirk Heinrichs*
>> Senior Systems Engineer, Delivery Pipeline
>> OpenText ™ Discovery | Recommind
>> *Phone*: +49 2226 15966 18
>> *Email*: dhei...@opentext.com
>> *Website*: www.recommind.de
>> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
>> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan,
>> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
>> This e-mail may contain confidential and/or privileged information. If
>> you are not the intended recipient (or have received this e-mail in error)
>> please notify the sender immediately and destroy this e-mail. Any
>> unauthorized copying, disclosure or distribution of the material in this
>> e-mail is strictly forbidden
>> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
>> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
>> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
>> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
>> Weitergabe dieser Mail sind nicht gestattet.
>>
> --
> 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/89c471a3-fc4e-466f-ad7d-0cb81e7d77f8%40googlegroups.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/CALF7fHb_Vj1AxPuMNyYtQ%2Brt04t4PXEQhc9-KDGqzfng5vt4FQ%40mail.gmail.com.

Re: [Puppet Users] Puppet Resource Api and attributes 'behaviour: :parameter'

[David Schmitt]

Hi Fred,

I'm sorry to say that this kind of behaviour is the topic of an open
feature request:
https://github.com/puppetlabs/puppet-resource_api/issues/225

I've added a link to this conversation there, to record the need for this.
Until this gets implemented, you can try your hand at the "nasty munging in
canonicalize method" that Sean is talking about: when reading values from
the system always return the age value as maxage. When processing user
input (from manifests) in canonicalize, set the incoming maxage value to
the value of age read from the system if it does not require an update yet.
That way puppet doesn't see the mismatched values and doesn't trigger an
update. Of course, this is "a bit" brittle and unintuitive, so tread with
care.



The newest version (and a bit better edited, too) of the Resource API docs
ist at https://puppet.com/docs/puppet/latest/custom_resources.html


Regards, David

On Mon, 24 Feb 2020 at 20:55, Frédéric Lespez 
wrote:

> Hi,
>
> I currently trying to develop a custom type with Puppet Resource API.
> Using this documentation:
>
> https://github.com/puppetlabs/puppet-specifications/blob/master/language/resource-api/README.md
> I managed to develop something that works with attributes of behavior
> 'namevar' and 'readonly'.
> I would like to create a new attributes of behavior 'parameter' to
> influence how the provider behaves (quoting the doc).
> But I don't understand how you could use this kind of attributes in the
> provider.
>
> Here is what I want to do :
> My custom type manages host ssh keys : The current attributes are type
> (dsa, rsa, etc.), length (of the key), comment and 2 'read_only' attributes
> : the file path of private ssh key (/etc/ssh/ssh_host_rsa_key) and 'age'
> (the number of days since the creation of the key - based on the key file
> modification time). The 'type' and 'length' are both 'namevar'.
> All of this works as expected :-)
> Now i want to add an attribute 'parameter' called 'maxdays' and implement
> the following behavior: If read-only attribute 'age' is greater that
> attributes parameter 'maxdays', I want to trigger the generation of a new
> key.
>
> I don't see a way in the get method to tell Puppet that since 'age' is
> greater that 'maxdays', it should call the set method to change the state
> of the system (ie. generate a new key).
>
> Is this doable with Puppet Resource API ?
> If yes, could you show me the way please ?
>
> Thanks in advance for your help.
>
> Regards,
> Fred
>
>
> --
> 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/87019d6c-1415-4de6-a611-2313e279b021%40googlegroups.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/CALF7fHZ%2BmYYnvtm%3DAS3-NzpDc-29wNEVD8%2BzoEpkpn4agBxP2w%40mail.gmail.com.

Re: [Puppet Users] Github actions for Puppet module deploy

[David Schmitt]

This was just a topic of conversation on the community slack (
https://puppetcommunity.slack.com/archives/C11LCKKQ9/p1576194567348200)

* There is no finished example yet
* PDK 1.15.0 (due next week) will have a `pdk release` subcommand that will
handle most of the puppet-specific workflow
* The content team (which I'm am part of) is currently supercharging a lot
of our processes through github actions, so expect some development from us
in the next weeks.


Cheers, David Schmitt

On Thu, 12 Dec 2019 at 12:17, Thomas Bendler 
wrote:

> Hi @all,
>
> are there any official Github Actions available to deploy Puppet modules
> to the Puppet forge? I know they exist for TravisCI (
> https://docs.travis-ci.com/user/deployment/puppetforge/) but didn't find
> the equivalent for Github Actions yet. Does anyone know more?
>
> Kind regards Thomas
> --
> Linux ... enjoy the ride!
>
> --
> 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/CAELoU1M%2BiKsH3Y_G7P3KrHC0PDQjv5NytVNWbFXP1hPWqFkOow%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAELoU1M%2BiKsH3Y_G7P3KrHC0PDQjv5NytVNWbFXP1hPWqFkOow%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CALF7fHZM4stUHRjrjUirwqPHddNObKDLdV4iYvjG-6JWfqC-fg%40mail.gmail.com.

Re: [Puppet Users] Optional / mutually exclusive resource parameters with the Puppet Resource API

[David Schmitt]

Hi Ben,

to avoid having server-side code, the Resource API doesn't have a way to
validate complex restrictions like this at compile time. You can either
collapse this into a single attribute of type `Variant[Boolean, String]` or
adding the validation in the provider at the time
`set`/`create`/`update`/`delete` get called. throwing an exception from
those methods will tell puppet that the resource application failed and
present the exception message to the user.


Regards, David

On Wed, 4 Dec 2019 at 16:34, Benjamin Ridley  wrote:

> Hi all,
>
> I'm developing a resource that allows the declaration of keys in the Etcd
> key value store.
>
> My type looks like this:
>
> Puppet::ResourceApi.register_type(
>   name: 'etcd_key',
>   docs: 'This type allows the management of etcd keys as Puppet
> resources.',
>   attributes: {
> ensure: {
>   type: 'Enum[present, absent]',
>   desc: 'Whether the key should be present in the etcd structure.',
>   default: 'present',
> },
> path: {
>   type: 'String',
>   desc: 'The path of the key you want to manage in the etcd
> structure.',
>   behaviour: :namevar,
> },
> directory: {
>   type: 'Boolean',
>   desc: 'Whether this key is a directory or not.',
>   default: false,
> },
> value: {
>   type: 'String',
>   desc: 'The value of the key. Mutually exclusive if with
> is_directory => true.',
> },
>   },
> )
>
>
> What I want to be able to do is make the value/directory parameters
> mutually exclusive as a directory does not have a 'value' in etcd, and
> similarly a key with a value cannot be a directory. Currently though,
> Puppet complains that I'm excluding required parameters when I declare them.
>
> Is this possible with the resource API or do I need to use the low level
> provider implementation?
>
> Thanks! Ben
>
> --
> 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/5bb1535f-0c14-4aee-98f6-91fd7d68c4f7%40googlegroups.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/CALF7fHabirW2qbHF%3DdVWytoyrcvyhNjJXt2jim3d17ndqjqrWw%40mail.gmail.com.

Re: [Puppet Users] service resource running always makes a corrective change

[David Schmitt]

As far as I can tell from here, the process that's supposed to be running
(rpc.nfsd) is not running and systemd therefore says the service is not
running (Active: active (exited)). A running service would be Active:
active (running) and showing the processes in the CGroup section.

On Wed, 6 Nov 2019 at 11:02, Andy Hall  wrote:

> Hey there - we have a server where part of the manifest is as follows:
>
>   service { 'nfs':
> enable  => true,
> ensure  => running,
>   }
>
> Nice and simple however on every puppet run we get the following output
> which is recorded as a change:
>
> [root@server ~]# puppet agent --test
>
>
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Retrieving locales
> Info: Loading facts
> Info: Caching catalog for server
> Info: Applying configuration version '1573029117'
>
>
> Notice: /Stage[main]/Flex::Profiles::Archive::Server/Service[nfs]/ensure:
> ensure changed 'stopped' to 'running' (corrective)
> Info: /Stage[main]/Flex::Profiles::Archive::Server/Service[nfs]:
> Unscheduling refresh on Service[nfs]
>
>
> Notice: Applied catalog in 18.92 seconds
>
>
> Could it be something to do with the fact that it is systemd ? This is
> CentOS 7:
>
> [root@server ~]# service nfs status
> Redirecting to /bin/systemctl status nfs.service
> ● nfs-server.service - NFS server and services
>Loaded: loaded (/usr/lib/systemd/system/nfs-server.service; enabled;
> vendor preset: disabled)
>   Drop-In: /run/systemd/generator/nfs-server.service.d
>└─order-with-mounts.conf
>Active: active (exited) since Fri 2019-11-01 20:31:00 GMT; 4 days ago
>  Main PID: 28173 (code=exited, status=0/SUCCESS)
>CGroup: /system.slice/nfs-server.service
>
>
> Warning: Journal has been rotated since unit was started. Log output is
> incomplete or unavailable.
>
>
> [root@server ~]# systemctl cat nfs
>
> # /usr/lib/systemd/system/nfs-server.service
> [Unit]
> Description=NFS server and services
> DefaultDependencies=no
> Requires= network.target proc-fs-nfsd.mount
> Requires= nfs-mountd.service
> Wants=rpcbind.socket network-online.target
> Wants=rpc-statd.service nfs-idmapd.service
> Wants=rpc-statd-notify.service
>
>
> After= network-online.target local-fs.target
> After= proc-fs-nfsd.mount rpcbind.socket nfs-mountd.service
> After= nfs-idmapd.service rpc-statd.service
> Before= rpc-statd-notify.service
>
>
> # GSS services dependencies and ordering
> Wants=auth-rpcgss-module.service
> After=rpc-gssd.service gssproxy.service
>
>
> Wants=nfs-config.service
> After=nfs-config.service
>
>
> [Service]
> EnvironmentFile=-/run/sysconfig/nfs-utils
>
>
> Type=oneshot
> RemainAfterExit=yes
> ExecStartPre=-/usr/sbin/exportfs -r
> ExecStart=/usr/sbin/rpc.nfsd $RPCNFSDARGS
> ExecStartPost=-/bin/sh -c 'if systemctl -q is-active gssproxy; then
> systemctl reload gssproxy ; fi'
> ExecStop=/usr/sbin/rpc.nfsd 0
> ExecStopPost=/usr/sbin/exportfs -au
> ExecStopPost=/usr/sbin/exportfs -f
>
>
> ExecReload=-/usr/sbin/exportfs -r
>
>
> [Install]
> WantedBy=multi-user.target
>
>
> # /run/systemd/generator/nfs-server.service.d/order-with-mounts.conf
> # Automatically generated by nfs-server-generator
>
>
> [Unit]
> RequiresMountsFor=/export/nfs/sl1-uat-permtest
>
> Any thoughts on how this could be handled more gracefully ? Thanks very
> much.
>
> --
> 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/5b3b2cde-db75-400d-85f9-2e9cbc995dc8%40googlegroups.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/CALF7fHYnVLnsQGk9VwAmrwuPhMVRN0GewdV98e8bo0QHTmcrDQ%40mail.gmail.com.

Re: [Puppet Users] Puppet Resource API - provider get method

[David Schmitt]

Hi Axton,

this is a long-standing issue with how puppet resources are implemented.
Adding path name vars like you did is one of the work arounds with the
least issues. if. you add title patterns, it can be actually quite nice to
use, say, defining for example "/etc/some.conf#key" for the "key" key in
the "/etc/some.conf" file.

I've finally added this to the resource api backlog at

https://github.com/puppetlabs/puppet-resource_api/projects/1#card-28372132

https://github.com/puppetlabs/puppet-resource_api/projects/1#card-26658327 is
another possible way forward, by providing the required data through a
separate resource in the catalogue. This would. Still not work for
instances where no catalogue is available (like the puppet resource
command) and make regular usage a lot more complex.

would love to hear your thoughts.

cheers, David

On Sun, 27 Oct 2019, 22:07 gramsa49,  wrote:

> What is the best way to implement the get method in a new custom provider
> where information from the resource is required when using the Resource API?
>
> Using the management of public or private keys as an example, the get
> method cannot return a list of resources without certain information from
> the resource, like filename.
>
> I have managed to work around this by declaring certain parameters as
> :namevar so they are available in the provider's get method, but this
> doesn't seem like the intended use.  Here is a working example:
>
> class Puppet::Provider::Pkey::Pkey < Puppet::ResourceApi::SimpleProvider
>   def get(context, name)
> context.debug("Getting '#{name.inspect}'")
> result = [{}]
> name.each_index do |x|
>   name[x].each do |key, val|
> result[x][key] = val unless key.to_s.eql? 'path'
> result[x][key] = val if (key.to_s.eql? 'path') &&
> Pathname.new(val.to_s).exist?
>   end
>   result[x][:ensure] = 'present'
> end
> result
>   end
> ...
>
>
> This basically iterates over the :namevar values and returns them in a
> hash if the resource exists.
> This is the complementary type for pkey:
>
> require 'puppet/resource_api'
>
>
> Puppet::ResourceApi.register_type(
>   name: 'pkey',
>   docs: <<-EOS,
> @summary a pkey type
> @example
> pkey { 'localhost.key':
>   ensure=> 'present',
>
>path  => '/etc/ssl/private/localhost.key'
>
>   outform   => pem,
>   algorithm => rsa,
>   keysize   => 2048,
> }
>
> This type provides Puppet with the capabilities to manage private keys
> EOS
>   features: ['simple_get_filter'],
>   attributes: {
> ensure: {
>   type: 'Enum[present, absent]',
>   desc: 'Whether this resource should be present or absent on the
> target system.',
>   default:  'present',
> },
> name: {
>   type: 'String',
>   desc: 'The name of the key',
>   behavior: :namevar,
> },
> path: {
>   type: 'String',
>   desc: 'The absolute path of the key file.',
>   behavior: :namevar,
> },
> ...
>
>
>
> The net effect of the code above is that the key shows to not exist if the
> file is not found, which is the desired behavior, but this seems like a
> misuse of :namevar.
>
> Is there are better way?
>
> This is going to be the case for any provider where state cannot be
> generated without user provided information, such as a filename (ini file,
> private key, certificate).
>
> Thanks,
> Axton
>
> --
> 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/1279a793-5a8b-4e66-83d2-10e821f633b6%40googlegroups.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/CALF7fHYLM8qnnE2syR%3Dd-euUzjgZAJ7Ztr%2BkOKZb2wszmE0c-A%40mail.gmail.com.

Re: [Puppet Users] puppet catalog find --terminus json on puppet master

[David Schmitt]

On Tue, 17 Sep 2019 at 14:13, Matt Zagrabelny  wrote:

> Hey David,
>
> Thanks for the reply!
>
> On Tue, Sep 17, 2019 at 5:58 AM David Schmitt 
> wrote:
>
>> The most recent releases of puppetserver have an API endpoint
>> specifically designed for this usecase:
>> https://puppet.com/docs/puppetserver/latest/puppet-api/v4/catalog.html
>>
>
> Okay. I'm only on puppet 5.5.
>

New features only get added to new versions.


>
>>
>> You'll also need to enable access to that endpoint in auth.conf for the
>> server you want to access that API from.
>>
>> You can experiment with the certless catalog indirector from
>> https://github.com/puppetlabs/ace/blob/master/lib/puppet/indirector/catalog/certless.rbto
>> integrate into the CLI you're asking about, but that'll likely require some
>> work to pass through the required fields.
>>
>
> Hmmm... So for 5.5 using this ruby file is about the only option to
> generate the catalog on the master?
>

This still requires availability of the new API in puppetserver.

Cheers, David


> Thanks for the help!
>
> -m
>
> --
> 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/CAOLfK3WRHRWeWFmpp5sOpdi%2BBcZcHAPQwEoOq_J5ucQAO51nYg%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CAOLfK3WRHRWeWFmpp5sOpdi%2BBcZcHAPQwEoOq_J5ucQAO51nYg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CALF7fHb2oGu4mr3_Wp5Cn6VNQfyWZB8yt%2B%2Bs1GBTvUFmmUYyaQ%40mail.gmail.com.

Re: [Puppet Users] puppet catalog find --terminus json on puppet master

[David Schmitt]

The most recent releases of puppetserver have an API endpoint specifically
designed for this usecase:
https://puppet.com/docs/puppetserver/latest/puppet-api/v4/catalog.html

You'll also need to enable access to that endpoint in auth.conf for the
server you want to access that API from.

You can experiment with the certless catalog indirector from
https://github.com/puppetlabs/ace/blob/master/lib/puppet/indirector/catalog/certless.rbto
integrate into the CLI you're asking about, but that'll likely require some
work to pass through the required fields.

Cheers, David

On Fri, 13 Sep 2019 at 20:09, Matt Zagrabelny  wrote:

> Greetings,
>
> I'm using puppet 5.5.10 (Debian Buster).
>
> From the puppet master system, I'm trying to get all the resources in a
> catalog for a given node.
>
> On a node "foo.example.com" I can with:
>
> foo# puppet catalog find --terminus json | wc -l
> 6271
>
> but on the master I've tried:
>
> puppet# puppet catalog find --terminus json foo.example.com | wc -l
> 0
>
> If I try a rest terminus I get:
>
> puppet# puppet catalog find --terminus rest foo.example.com | wc -l
> Error: Could not call 'find' on 'catalog': Error 403 on SERVER: Not
> Authorized: Forbidden request: /puppet/v3/catalog/git.d.umn.edu [find]
> Error: Could not call 'find' on 'catalog': Error 403 on SERVER: Not
> Authorized: Forbidden request: /puppet/v3/catalog/git.d.umn.edu [find]
> Error: Try 'puppet help catalog find' for usage
>
> Any ideas on how to get a node's catalog from the master?
>
> Thanks,
>
> -m
>
> --
> 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/CAOLfK3Xf8ePFU33PoOv4w55DYnuLOw7qN7RYVjSE20ZUJKAvyw%40mail.gmail.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/CALF7fHZkrAO0NRbuO2aa8-tX%3D1C00xh5Yxpa1Hn8SdmSq5yK9Q%40mail.gmail.com.

Re: [Puppet Users] Bolt needs /opt/puppetlabs, but does not exist on debian buster

[David Schmitt]

"puppet" is the debian-native packaging. to get the puppetlabs packaging,
install `puppet-agent`. You'll also want to use the puppet6 - not the
puppet5 - release train, to get all the new stuff.

Cheers, David

On Tue, 27 Aug 2019 at 11:07, 'Christoph Myself' via Puppet Users <
puppet-users@googlegroups.com> wrote:

> Hi,
>
> I want to use  bolt to run some tasks on a debian 10 buster node
>
> On the buster node I Installed the puppet packages fro puppetlabs.com via
> dpkg -i  puppet5-release-buster.deb and apt install puppet.
>
> But whenever I want to run a task from my bolt directory to that debian
> buster I get an error :
>   bash: /tmp/828ed839-b442-4a25-bfa0-69c74077f40d/patch_server.rb:
> /opt/puppetlabs/puppet/bin/ruby: bad interpreter: No such file or directory
>
> I dont have an /opt/puppetlabs tree.
>
> The buster puppet package from puppetlabs seems to install elsewhere but
> not in /opt/puppetlabs
>
> How can I run bolt tasks in this  situation ?
>
> Thanks
>   Chistoph
>
>
> --
> 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/3f653db0-dbfe-49bb-93a6-d2e8e1ea66fa%40googlegroups.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/CALF7fHbPpPZdNv0y9K%3DcU6M5%3D1W5gCVe-srVU_eQsz6hR8Esqw%40mail.gmail.com.

Re: [Puppet Users] switching from source => "puppet:/// to source => "file:///

[David Schmitt]

On Fri, 14 Jun 2019 at 08:45, Locke Hajo  wrote:

> Hello,
>
> I suspect that you're misunderstanding something about how Puppet works,
>> because as far as I can tell, you're trying to copy
>> /etc/apache2/conf.d/testpuppet.conf to /etc/apache2/conf.d/testpuppet.conf.
>> (The same path)
>>
>> yes i want to mirror a file from the master to my client. For me it seems
> to bo the best way to mirror original files and changes.
> Otherwise i would need a further machine as a master and put changes into
> puppet:/// structur.
>
> For type file source attribut can have values puppet: , file: and http:
> description for file is: file: URIs, which behave the same as local file
> paths.
> Why is it offered, if it should not be used? Do i understand something
> wrong?
>

`file:///` sources are local to the *agent*, not the *puppetserver*.
Puppet's philosophy is to manage nodes based on a controlled source base
(the control repo), not mirroring from a live machine. If you want to have
a guided tour of the what and how, please follow Ben's recommendation of
trying out the learning VM at https://learn.puppet.com


Cheers, David


>
> Thanks,
> Hajo
>
> --
> 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/100af972-b436-4bc9-8c2c-92fc1f96c822%40googlegroups.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/CALF7fHb3h1c3y0GrHQurNg3UQ0AAMa_JkejqVRmoB3%2B45f1%2B2A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] apt::key and basic auth

[David Schmitt]

Hi Douglas,

thanks for identifying the issue! Please submit a PR to the apt repo
, someone from the Modules
Team will pick it up.


Regards, David

On Mon, Apr 1, 2019 at 8:44 PM Douglas K. Rand  wrote:

> On 3/31/19 10:37 AM, Martin Alfke wrote:>> On 29. Mar 2019, at 19:42,
> Douglas
> Rand  wrote:
> >> I have a provider that hosts their APT repository behind a basic auth
> >> protected website, and I cannot work out how to get apt::key to add
> their
> >> key.
>
> > Have you tried using apt_auth.conf file?
> > https://manpages.debian.org/testing/apt/apt_auth.conf.5.en.html
>
> No, I hadn't. And thanks for that, it solved another problem I was having.
> Thanks Martin!
>
> But not the problem with apt::key.  I rand it down to the source_to_file
> method in the apt_key.rb provider from Puppet's APT library. The
> source_to_file method fetches the remote key and drops it in a temporary
> file
> and then uses apt-key to install the key.  So the fetching of the key
> bypasses
> all of the nice apt features with apt/auth.conf.   So no joy there.
>
> But I did find a fix. The problem is that the username I need to provide
> in
> basic auth is my email address, and includes an '@' sign. And since the
> '@'
> sign is already part of the url coding for usernames, you can't have it in
> the
> username. I had been using '%40' to replace the '@' sign in my username,
> but
> the Ruby provider doesn't know that the usernames might be URI encoded.
>
> This simple patch adds that:
>
> ---
> /local-project/tmp/r10k/production/modules/apt/lib/puppet/provider/apt_key/apt_key.rb
>
>2017-10-24 08:45:17.316572536 -0500
> +++ modules/apt/lib/puppet/provider/apt_key/apt_key.rb  2019-04-01
> 13:38:02.026555102 -0500
> @@ -129,6 +129,10 @@
> begin
>   user_pass = parsedValue.userinfo.nil? ? nil :
> parsedValue.userinfo.split(':')
>   parsedValue.userinfo = ''
> +unless user_pass.nil?
> +  user_pass[0] = URI.unescape(user_pass[0])
> +  user_pass[1] = URI.unescape(user_pass[1])
> +end
>   key = open(parsedValue, :http_basic_authentication =>
> user_pass).read
> rescue OpenURI::HTTPError, Net::FTPPermError => e
>   fail("#{e.message} for #{resource[:source]}")
>
> Does anybody have any idea how to get this directed toward the right
> people?
>
> --
> 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/3446ba74-f3f5-a512-f36c-e9f789b82d7a%40iteris.com
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Custom type: Ensure array properties are sorted

[David Schmitt]

On Fri, Mar 15, 2019 at 10:35 AM Dirk Heinrichs 
wrote:

> Am Freitag, den 15.03.2019, 09:47 + schrieb David Schmitt:
>
> If you use the Resource API (official docs:
> https://puppet.com/docs/puppet/6.3/custom_resources.html
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__puppet.com_docs_puppet_6.3_custom-5Fresources.html=DwMFaQ=ZgVRmm3mf2P1-XDAyDsu4A=TsKycyisPP_6FVCeETRooIdY_8hdAsXoxwbvHso_TaI=8gEJHfkK_A8j6ZfFoNN-2I6fEf5P0FMr450yxF6I7VQ=mQMCRXhExpGeJEnuV17X4Xu-nzFV4ylDpGkJiEuIbrs=>,
> github: https://github.com/puppetlabs/puppet-resource_api
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_puppetlabs_puppet-2Dresource-5Fapi=DwMFaQ=ZgVRmm3mf2P1-XDAyDsu4A=TsKycyisPP_6FVCeETRooIdY_8hdAsXoxwbvHso_TaI=8gEJHfkK_A8j6ZfFoNN-2I6fEf5P0FMr450yxF6I7VQ=-oFS_6kmnJGYrspbb3RVehNRmJ6Ea2H5ZODsHjioqPQ=>
> ), adding a canonical internal representation is as easy as adding the
> `canonicalize` feature, and define the required change on the provider:
>
> [...]
>
>
> The resource api also makes a lot of other pain of developing types and
> providers go away, and supports all puppet versions from 4.7
>
>
> Thanks for the hint. Unfortunately that would require me to do a complete
> rewrite. Will have to see when I find some time...
>

I understand that porting over can be a daunting task. After having run a
few projects over the last year with the new API, I have to say that it's
less work than you might expect: you can re-use most of the business logic
code that you already have, and remove a lot of cruft and hacks that are
not necessary anymore.


Cheers, David


> Thanks...
>
> Dirk
>
> --
>
> *Dirk Heinrichs*
> Senior Systems Engineer, Delivery Pipeline
> OpenText ™ Discovery | Recommind
> *Phone*: +49 2226 15966 18 <+49%202226%201596618>
> *Email*: dhein...@opentext.com
> *Website*: www.recommind.de
> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
> <https://maps.google.com/?q=Von-Liebig-Stra%C3%9Fe+1,+53359+Rheinbach=gmail=g>
> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan,
> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail sind nicht gestattet.
>
> --
> 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/61422a877283c88796c10c9af2f16e99c6ae6175.camel%40opentext.com
> <https://groups.google.com/d/msgid/puppet-users/61422a877283c88796c10c9af2f16e99c6ae6175.camel%40opentext.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHbvRsfDdN2u%3DYXrme3FO7fN7%3Dqn%3DAd9x95BCE_bEwMG%3Dg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Custom type: Ensure array properties are sorted

[David Schmitt]

If you use the Resource API (official docs:
https://puppet.com/docs/puppet/6.3/custom_resources.html, github:
https://github.com/puppetlabs/puppet-resource_api ), adding a canonical
internal representation is as easy as adding the `canonicalize` feature,
and define the required change on the provider:

  def canonicalize(context, resources)
resources.each do |r|
  r[:array_prop] = r[:array_prop].sort
end
  end


The resource api also makes a lot of other pain of developing types and
providers go away, and supports all puppet versions from 4.7


Regard, David

On Fri, Mar 15, 2019 at 6:54 AM Dirk Heinrichs 
wrote:

> Hi,
>
> I've written a custom type that has an array property. I quickly found out
> that it isn't idempotent unless the array is sorted. Turned out that it was
> easy to sort the current values in the provider but I couldn't find out how
> to properly sort the input values w/o putting that burden on the user of
> the type. I tried with munge like this:
>
> newproperty(:array_prop, :array_matching => :all) do
> munge do |value|
> value.sort
> end
> end
> but it seems that just gets the first array element as string, which is
> neither obvious nor intuitive.
>
> Is there any other way than having to use
>
> mytype { 'title':
> ...
> array_prop => sort($array),
> ...
> }
>
> ?
>
> Thanks...
>
> Dirk
>
> --
>
> *Dirk Heinrichs*
> Senior Systems Engineer, Delivery Pipeline
> OpenText ™ Discovery | Recommind
> *Phone*: +49 2226 15966 18 <+49%202226%201596618>
> *Email*: dhein...@opentext.com
> *Website*: www.recommind.de
> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
> 
> Vertretungsberechtigte Geschäftsführer Gordon Davies, Madhu Ranganathan,
> Christian Waida, Registergericht Amtsgericht Bonn, Registernummer HRB 10646
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail sind nicht gestattet.
>
> --
> 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/b50e9e0461472e2300db026f567a8ddec77d5cfc.camel%40opentext.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Re: Puppet dumped multiple 1G files into folder after reboot

[David Schmitt]

Stephen,

apologies for the late response - I've been out sick last week.

I've poked around a bit in old bug reports and the only thing I could find
is https://tickets.puppetlabs.com/browse/PDB-1812 , which says that
PuppetDB 3.0.2 fixed an issue with autovaccuming that was not properly
garbage collecting space in postgresql.

If you're on a version even older than that, and can't upgrade, it might
make sense to look into manually configuring some regular database
maintenance. That could possibly limit the growth of the files on disk to
what the database actually needs for it's day-to-day work.

To get off puppet 3 please see the Upgrade Guide at
https://docs.puppet.com/upgrade/upgrade_steps.html .


Good luck, David


On Wed, Feb 20, 2019 at 2:30 PM Stephen S.  wrote:

> Yes, I was able to get into the psql db and poke around. I see legit data
> there so I'm not comfortable removing any files. But, I am still concerned
> with what causes this to happen. At 5G a pop this could quickly fill up a
> partition.
>
> On Sunday, February 17, 2019 at 12:46:17 AM UTC-6, Stephen S. wrote:
>>
>> We have a puppet server running 3.8.7 on RHEL 6.10. It experienced an OOM
>> event this morning then the server recovered without intervention. While
>> looking into this I noticed the server became very slow to respond. I saw
>> that it suddenly had over 3200 processes running and was about to crash. I
>> was able to reboot the box and it came back up fine. Everything now seems
>> normal except for the fact that there are about 5 files now in
>> /var/lib/pgsql/data/base/*/* that are eating up 1G each. These are all
>> timestamped with todays date and were not there until after the reboot.
>> Does anyone know if these files are safe to delete? I am not familar with
>> this particular folder or how it interacts with puppetmaster. We do not
>> have puppetdb installed on this system so I am not sure why it would write
>> to this folder.
>>
>> Files created today.
>>
>> -rw--- 1 postgres postgres 1.0G Feb 16 10:02
>> /var/lib/pgsql/data/base/16385/17240.2
>> -rw--- 1 postgres postgres 1.0G Feb 16 10:05
>> /var/lib/pgsql/data/base/16385/17240.4
>> -rw--- 1 postgres postgres 1.0G Feb 16 10:06
>> /var/lib/pgsql/data/base/16385/17240.3
>> rw---. 1 postgres postgres 1.0G Feb 16 10:07
>> /var/lib/pgsql/data/base/16385/17240
>> -rw--- 1 postgres postgres 1.0G Feb 16 10:04
>> /var/lib/pgsql/data/base/16385/17240.1
>>
>>
>>
>> --
> 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/f68cb873-dae7-4731-b287-332d814902d7%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHZw%3DFfrYGVzJ6s5Qm-3kHdOCGOQMyaykFAGhBX7p20P4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Writing a non-ensurable type/provider

[David Schmitt]

Hi Dirk,

this is possible using the Resource API
, and instead of
using the `set`

method implemented in SimpleProvider (which is the default if you do `pdk
new provider`) create your own simpler version.

The Resource API is part of puppet 6, and available as side-loadable gem
for previous versions. There is a puppet module
 to install it.


Regards, David

On Mon, Feb 25, 2019 at 7:47 AM Dirk Heinrichs 
wrote:

> Hi,
>
> I need to write a custom type to configure a third party tool through REST
> API calls. This means I have to:
>
>
>1. Get the configuration via REST call and provide it as hash
>2. Modify the requested attributes
>3. Upload the modified configuration and request the the tool to
>restart itself (both via REST API).
>
>
> This doesn't sound like a classical ensurable type to me. However, I've
> got some difficulties to understand how to write a type that isn't
> ensurable and how such a type would interact with its provider (in case I
> need one at all), so that it's still idempotent. The resource call should
> then look like this:
>
> myconfig { 'somename':
> option1 => 'value1',
> option2 => 'value2',
> ...,
> require => [Something],
> }
>
> Could someone please point me into the right direction?
>
> Thanks a lot...
>
> Dirk
>
> --
>
> *Dirk Heinrichs*
> Senior Systems Engineer, Delivery Pipeline
> OpenText ™ Discovery | Recommind
> *Phone*: +49 2226 15966 18 <+49%202226%201596618>
> *Email*: dhein...@opentext.com
> *Website*: www.recommind.de
> Recommind GmbH, Von-Liebig-Straße 1, 53359 Rheinbach
> 
> Vertretungsberechtigte Geschäftsführer John Marshall Doolittle, Gordon
> Davies, Christian Waida, Registergericht Amtsgericht Bonn, Registernummer
> HRB 10646
> This e-mail may contain confidential and/or privileged information. If you
> are not the intended recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorized copying, disclosure or distribution of the material in this
> e-mail is strictly forbidden
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte
> Weitergabe dieser Mail sind nicht gestattet.
>
> --
> 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/192ca5b4da8bda73365493c34a48dc85d2c7a2d9.camel%40opentext.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Puppet dumped multiple 1G files into folder after reboot

[David Schmitt]

Hi Stephen,

while I can't say anything about what might have caused your issues in the
first place, I can say with high confidence that the files you're seeing
there *are* part of a postgresql database, and deleting them straight up
will destroy something. To figure out what that "something" is, you'll need
to figure out what databases are running on your system, and who is using
it.


Good Luck,

David


On Sun, Feb 17, 2019 at 6:46 AM Stephen S.  wrote:

> We have a puppet server running 3.8.7 on RHEL 6.10. It experienced an OOM
> event this morning then the server recovered without intervention. While
> looking into this I noticed the server became very slow to respond. I saw
> that it suddenly had over 3200 processes running and was about to crash. I
> was able to reboot the box and it came back up fine. Everything now seems
> normal except for the fact that there are about 5 files now in
> /var/lib/pgsql/data/base/*/* that are eating up 1G each. These are all
> timestamped with todays date and were not there until after the reboot.
> Does anyone know if these files are safe to delete? I am not familar with
> this particular folder or how it interacts with puppetmaster. We do not
> have puppetdb installed on this system so I am not sure why it would write
> to this folder.
>
> Files created today.
>
> -rw--- 1 postgres postgres 1.0G Feb 16 10:02
> /var/lib/pgsql/data/base/16385/17240.2
> -rw--- 1 postgres postgres 1.0G Feb 16 10:05
> /var/lib/pgsql/data/base/16385/17240.4
> -rw--- 1 postgres postgres 1.0G Feb 16 10:06
> /var/lib/pgsql/data/base/16385/17240.3
> rw---. 1 postgres postgres 1.0G Feb 16 10:07
> /var/lib/pgsql/data/base/16385/17240
> -rw--- 1 postgres postgres 1.0G Feb 16 10:04
> /var/lib/pgsql/data/base/16385/17240.1
>
>
>
> --
> 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/476c2298-d121-4d6f-80c2-f17e3508a956%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Run Exec command only if the file changes -puppet 3.8.6

[David Schmitt]

Hi,

look into the "refreshonly" parameter on exec.

Regards, David

On Mon, 11 Feb 2019, 23:34 ,  wrote:

> Hello,
>
> I am relatively new to puppet and i am looking to see if there's any way
> to execute a command if a particular file has been changed on github source
> ?
>
> Thanks !
>
> --
> 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/c1cc1d7d-f855-40f3-8e4b-204f6b85251b%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] PDK on bionic Ubuntu

[David Schmitt]

This Gemfile works on my debian machine, which means we can exclude a whole
bunch of potential problems. As next step, try removing your `Gemfile.lock`
and the `/home/peter/.pdk/cache/ruby/` directory.

I hope that helps.

Cheers, David

unrelated PS: the changes you made to require hiera 3.5.0 in the Gemfile do
not work. It still pulls in version 3.4.5.13. I've created
https://github.com/puppetlabs/pdk-templates/issues/182 to ask for allowing
this to be overridden through the regular channels. At the same time, I'd
also caution against modifying these bits too radically, as the PDK chooses
the versions that we ship in the puppet-agent package, so changing that
around will invalidate your test results.


On Mon, Jan 28, 2019 at 3:21 PM Peter Berghold 
wrote:

> Gemfile
> source ENV['GEM_SOURCE'] || 'https://rubygems.org'
>
> def location_for(place_or_version, fake_version = nil)
>   git_url_regex = %r{\A(?(https?|git)[:@][^#]*)(#(?.*))?}
>   file_url_regex = %r{\Afile:\/\/(?.*)}
>
>   if place_or_version && (git_url = place_or_version.match(git_url_regex))
> [fake_version, { git: git_url[:url], branch: git_url[:branch],
> require: false }].compact
>   elsif place_or_version && (file_url =
> place_or_version.match(file_url_regex))
> ['>= 0', { path: File.expand_path(file_url[:path]), require: false }]
>   else
> [place_or_version, { require: false }]
>   end
> end
>
> ruby_version_segments = Gem::Version.new(RUBY_VERSION.dup).segments
> minor_version = ruby_version_segments[0..1].join('.')
>
> group :development do
>   gem "fast_gettext", '1.1.0', require: false if
> Gem::Version.new(RUBY_VERSION.dup) < Gem::Version.new('2.1.0')
>   gem "fast_gettext",  require: false if
> Gem::Version.new(RUBY_VERSION.dup) >= Gem::Version.new('2.1.0')
>   gem "json_pure", '<= 2.0.1', require: false if
> Gem::Version.new(RUBY_VERSION.dup) < Gem::Version.new('2.0.0')
>   gem "json", '= 1.8.1',   require: false if
> Gem::Version.new(RUBY_VERSION.dup) == Gem::Version.new('2.1.9')
>   gem "json", '<= 2.0.4',  require: false if
> Gem::Version.new(RUBY_VERSION.dup) == Gem::Version.new('2.4.4')
>   gem "puppet-module-posix-default-r#{minor_version}", require: false,
> platforms: [:ruby]
>   gem "puppet-module-posix-dev-r#{minor_version}", require: false,
> platforms: [:ruby]
>   gem "puppet-module-win-default-r#{minor_version}",   require: false,
> platforms: [:mswin, :mingw, :x64_mingw]
>   gem "puppet-module-win-dev-r#{minor_version}",   require: false,
> platforms: [:mswin, :mingw, :x64_mingw]
> end
>
> puppet_version = ENV['PUPPET_GEM_VERSION']
> facter_version = ENV['FACTER_GEM_VERSION']
> hiera_version = ENV['3.5.0']
>
>
> gems = {}
>
> gems['puppet'] = location_for(puppet_version)
>
> # If facter or hiera versions have been specified via the environment
> # variables
>
> gems['facter'] = location_for(facter_version) if facter_version
> gems['hiera'] = location_for('3.5.1') if hiera_version
>
> if Gem.win_platform? && puppet_version =~ %r{^(file:///|git://)}
>   # If we're using a Puppet gem on Windows which handles its own win32-xxx
> gem
>   # dependencies (>= 3.5.0), set the maximum versions (see PUP-6445).
>   gems['win32-dir'] =  ['<= 0.4.9', require: false]
>   gems['win32-eventlog'] = ['<= 0.6.5', require: false]
>   gems['win32-process'] =  ['<= 0.7.5', require: false]
>   gems['win32-security'] = ['<= 0.2.5', require: false]
>   gems['win32-service'] =  ['0.8.8', require: false]
> end
>
> gems.each do |gem_name, gem_params|
>   gem gem_name, *gem_params
> end
>
> # Evaluate Gemfile.local and ~/.gemfile if they exist
> extra_gemfiles = [
>   "#{__FILE__}.local",
>   File.join(Dir.home, '.gemfile'),
> ]
>
> extra_gemfiles.each do |gemfile|
>   if File.file?(gemfile) && File.readable?(gemfile)
> eval(File.read(gemfile), binding)
>   end
> end
> # vim: syntax=ruby
>
>
> On Mon, Jan 28, 2019 at 10:19 AM David Schmitt 
> wrote:
>
>> please also provide the Gemfile as I've asked above. Without that it's
>> impossible to reproduce locally and/or diagnose.
>>
>>
>>
>> On Mon, Jan 28, 2019 at 3:03 PM Peter Berghold 
>> wrote:
>>
>>> Yes that was done in a module created by PDK originally.
>>>
>>> Here is the debug output
>>>
>>> peter@saltycowdawg: mediawiki]:(master): pdk test unit --debug
>>> pdk (INFO): Using Ruby 2.5.1
>>>

Re: [Puppet Users] PDK on bionic Ubuntu

[David Schmitt]

please also provide the Gemfile as I've asked above. Without that it's
impossible to reproduce locally and/or diagnose.



On Mon, Jan 28, 2019 at 3:03 PM Peter Berghold 
wrote:

> Yes that was done in a module created by PDK originally.
>
> Here is the debug output
>
> peter@saltycowdawg: mediawiki]:(master): pdk test unit --debug
> pdk (INFO): Using Ruby 2.5.1
> pdk (INFO): Using Puppet 6.0.2
> pdk (DEBUG): Checking for missing Gemfile dependencies.
> pdk (DEBUG): Using '/opt/puppetlabs/pdk/private/ruby/2.5.1/bin/bundle'
> from PDK package.
> pdk (DEBUG): Executing '/opt/puppetlabs/pdk/private/ruby/2.5.1/bin/bundle
> check --gemfile=/home/peter/prj-src/puppet/mediawiki/Gemfile --dry-run'
> pdk (DEBUG): Command environment:
> pdk (DEBUG):   PUPPET_GEM_VERSION: 6.0.2
> pdk (DEBUG):   BUNDLE_IGNORE_CONFIG: 1
> pdk (DEBUG):   GEM_HOME: /home/peter/.pdk/cache/ruby/2.5.0
> pdk (DEBUG):   GEM_PATH:
> /opt/puppetlabs/pdk/private/ruby/2.5.1/lib/ruby/gems/2.5.0:/opt/puppetlabs/pdk/share/cache/ruby/2.5.0:/opt/puppetlabs/pdk/private/puppet/ruby/2.5.0
> pdk (DEBUG):   PATH:
> /opt/puppetlabs/pdk/private/ruby/2.5.1/bin:/home/peter/.pdk/cache/ruby/2.5.0/bin:/opt/puppetlabs/pdk/private/ruby/2.5.1/lib/ruby/gems/2.5.0/bin:/opt/puppetlabs/pdk/share/cache/ruby/2.5.0/bin:/opt/puppetlabs/pdk/private/puppet/ruby/2.5.0/bin:/opt/puppetlabs/pdk/bin:/home/peter/bin:/home/peter/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/puppetlabs/bin:/opt/puppetlabs/pdk/private/git/bin
> pdk (DEBUG): Execution of
> '/opt/puppetlabs/pdk/private/ruby/2.5.1/bin/bundle check
> --gemfile=/home/peter/prj-src/puppet/mediawiki/Gemfile --dry-run' complete
> (duration: 2.847360904s; exit code: 0)
> pdk (DEBUG): Updating Gemfile dependencies.
> pdk (DEBUG): Using '/opt/puppetlabs/pdk/private/ruby/2.5.1/bin/bundle'
> from PDK package.
> pdk (DEBUG): Executing '/opt/puppetlabs/pdk/private/ruby/2.5.1/bin/bundle
> lock --lockfile=/home/peter/prj-src/puppet/mediawiki/Gemfile.lock --update
> --local'
> pdk (DEBUG): Command environment:
> pdk (DEBUG):   BUNDLE_GEMFILE: /home/peter/prj-src/puppet/mediawiki/Gemfile
> pdk (DEBUG):   PUPPET_GEM_VERSION: 6.0.2
> pdk (DEBUG):   BUNDLE_IGNORE_CONFIG: 1
> pdk (DEBUG):   GEM_HOME: /home/peter/.pdk/cache/ruby/2.5.0
> pdk (DEBUG):   GEM_PATH:
> /opt/puppetlabs/pdk/private/ruby/2.5.1/lib/ruby/gems/2.5.0:/opt/puppetlabs/pdk/share/cache/ruby/2.5.0:/opt/puppetlabs/pdk/private/puppet/ruby/2.5.0
> pdk (DEBUG):   PATH:
> /opt/puppetlabs/pdk/private/ruby/2.5.1/bin:/home/peter/.pdk/cache/ruby/2.5.0/bin:/opt/puppetlabs/pdk/private/ruby/2.5.1/lib/ruby/gems/2.5.0/bin:/opt/puppetlabs/pdk/share/cache/ruby/2.5.0/bin:/opt/puppetlabs/pdk/private/puppet/ruby/2.5.0/bin:/opt/puppetlabs/pdk/bin:/home/peter/bin:/home/peter/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/opt/puppetlabs/bin:/opt/puppetlabs/pdk/private/git/bin
> pdk (DEBUG): Execution of
> '/opt/puppetlabs/pdk/private/ruby/2.5.1/bin/bundle lock
> --lockfile=/home/peter/prj-src/puppet/mediawiki/Gemfile.lock --update
> --local' complete (duration: 0.22216318s; exit code: 1)
> pdk (FATAL):
> /opt/puppetlabs/pdk/private/ruby/2.5.1/lib/ruby/site_ruby/2.5.0/rubygems.rb:289:in
> `find_spec_for_exe': can't find gem bundler (>= 0.a) with executable bundle
> (Gem::GemNotFoundException)
> from
> /opt/puppetlabs/pdk/private/ruby/2.5.1/lib/ruby/site_ruby/2.5.0/rubygems.rb:308:in
> `activate_bin_path'
> from /opt/puppetlabs/pdk/private/ruby/2.5.1/bin/bundle:23:in `'
>
> pdk (FATAL): Unable to resolve Gemfile dependencies.
> pdk (DEBUG):
> /opt/puppetlabs/pdk/private/ruby/2.4.4/lib/ruby/gems/2.4.0/gems/pdk-1.8.0/lib/pdk/util/bundler.rb:185:in
> `update_lock!'
> pdk (DEBUG):
> /opt/puppetlabs/pdk/private/ruby/2.4.4/lib/ruby/gems/2.4.0/gems/pdk-1.8.0/lib/pdk/util/bundler.rb:46:in
> `ensure_bundle!'
> pdk (DEBUG):
> /opt/puppetlabs/pdk/private/ruby/2.4.4/lib/ruby/gems/2.4.0/gems/pdk-1.8.0/lib/pdk/cli/test/unit.rb:76:in
> `block (2 levels) in '
> pdk (DEBUG):
> /opt/puppetlabs/pdk/private/ruby/2.4.4/lib/ruby/gems/2.4.0/gems/cri-2.10.1/lib/cri/command.rb:329:in
> `run_this'
> pdk (DEBUG):
> /opt/puppetlabs/pdk/private/ruby/2.4.4/lib/ruby/gems/2.4.0/gems/cri-2.10.1/lib/cri/command.rb:269:in
> `run'
> pdk (DEBUG):
> /opt/puppetlabs/pdk/private/ruby/2.4.4/lib/ruby/gems/2.4.0/gems/cri-2.10.1/lib/cri/command.rb:287:in
> `run'
> pdk (DEBUG):
> /opt/puppetlabs/pdk/private/ruby/2.4.4/lib/ruby/gems/2.4.0/gems/cri-2.10.1/lib/cri/command.rb:287:in
> `run'
> pdk (DEBUG):
> /opt/puppetlabs/pdk/private/ruby/2.4.4/lib/ruby/gems/2.4.0/gems/pdk-1.8.0/lib/pdk/cli.rb:18:in
> `run'
> pdk (DEBUG):
> /opt/puppetlabs/pdk/private/ruby/2.4.4/lib/ruby/g

Re: [Puppet Users] PDK on bionic Ubuntu

[David Schmitt]

Hi Peter,

is the module compatible to the PDK? That is, have you created the module
with the PDK, and/or ran `pdk convert`/`pdk update` successfully on it?

If no, please do so before trying to run any other PDK commands in a module.

If yes, please capture the full output of the command you're running after
adding `--debug`, and - for this specific case - the Gemfile. With that
information we'll have a better chance of figuring out what's going on
there.


Cheers, David

On Sat, Jan 26, 2019 at 3:43 PM Peter Berghold 
wrote:

> When I run "pdk test unit" I get the following error:
> pdk (INFO): Using Ruby 2.5.1
> pdk (INFO): Using Puppet 6.0.2
> pdk (FATAL):
> /opt/puppetlabs/pdk/private/ruby/2.5.1/lib/ruby/site_ruby/2.5.0/rubygems.rb:289:in
> `find_spec_for_exe': can't find gem bundler (>= 0.a) with executable bundle
> (Gem::GemNotFoundException)
> from
> /opt/puppetlabs/pdk/private/ruby/2.5.1/lib/ruby/site_ruby/2.5.0/rubygems.rb:308:in
> `activate_bin_path'
> from /opt/puppetlabs/pdk/private/ruby/2.5.1/bin/bundle:23:in `'
>
> pdk (FATAL): Unable to resolve Gemfile dependencies.
>
> I did a "gem list" and bundler is installed. What is the magic foo that I
> can do to make this work?
>
>
> --
>
> Peter L. Berghold   salty.cowd...@gmail.com
>
> h ttp://science-fiction.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/CAArvnv1gacMoibL%3DZm9D_icP%2Bse5WvWsiSFMnp69GF2yzSra%3DQ%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] serving per-node private data in puppet 5

[David Schmitt]

Hi Matt,

I've not tried it myself, but
https://puppet.com/docs/puppetserver/5.3/config_file_auth.html#hocon-example
with a `match-request` selecting the hostname and a backreference in the
`allow` section seems the new way to do this.


Cheers, David

On Thu, Nov 15, 2018 at 9:44 PM Matt Zagrabelny  wrote:

> Greetings!
>
> I'm working on migrating my puppet 3.7 environment to puppet 5.5 (Debian
> testing.)
>
> How are folks serving private per-node data in puppet 5? (i.e. ssh keys,
> apache cert and key, etc.)
>
> In both puppet 2.7 and 3.7 I've used:
>
> $ cat /etc/puppet/fileserver.conf
> # This file consists of arbitrarily named sections/modules
> # defining where files are served from and to whom
>
> [private]
> path /etc/puppet/environments/production/private/%H
> allow *
>
> Have things changed since then? Are there better (or more idiomatic) ways
> of serving up private per-node files?
>
> Ideally I would also be able to use the environment to adjust the mount
> point. Hand-wavy magic:
> path /etc/puppet/environments/%E/private/%H
>
> Hiera has support for top level variables. Our ENC exposes the
> environmentt:
> "environments/%{::environment}/node/%{clientcert}"
>
> Thanks for any hints, help, or discussion!
>
> -m
>
> --
> 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/CAOLfK3V1Ff9%3DQo%2BAUO72_UEvJE%2BakR6eKgTmW_PVr021Y8zcvg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHYK%3DvAp19mHN-mcHtCHtw9uQsGsf30EcL1n6YAqRrRQXA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Using variable for user password hash causes password updated each run.

[David Schmitt]

Check if the output of your script actually matches *exactly* the hash that
gets written into the user. Whitespace, even a new line at the end, might
confuse puppet here. If that's the problem, use
https://forge.puppet.com/puppetlabs/stdlib#strip to fix that.

Cheers, DavidS

On Thu, Oct 18, 2018 at 7:23 PM James Perry  wrote:

> I have been asked to set password for a user so it is unique on every
> single host we support. I have a script that generates the password and I
> had pulled it in via a generate call. The scripts takes in two of facter
> values to be used to aid in generating the password.
>
> $myvar = generate("/bin/sh","myscript.sh"."value1","value2")
> user { 'bob':
>  password => "${myvar}",
>  }
>
>
> This value is coming in as expected. When I pass it to the password => block
> it gets set as expected. Cool, but then it isn't.
>
> Each time puppet runs for the host, it keeps changing the user's password
> hash even though the hash from the script is the same as that on the host.
> Even that could be acceptable, except, these hosts are audited for password
> changes. Root being shown as updated every puppet run fails the audit.
>
> When I define it as a static hash aka '$1$salt$ab12k3oa01ksf01810' it
> doesn't keep resetting the password
>
> Notice: Local environment: 'production' doesn't match server specified
> node environment 'passfix', switching agent to 'passfix'.
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Loading facts
> Info: Caching catalog for tlistmrrh511.myhost.net
> Info: Applying configuration version '1539886469'
> *Notice: /Stage[main]/Users::mypassword/User[bob]/password: created
> password*
> Notice: Applied catalog in 4.52 seconds
> [root@tlistmrrh511 ~]#
> [root@tlistmrrh511 ~]# puppet agent -tv
> Notice: Local environment: 'production' doesn't match server specified
> node environment 'passfix', switching agent to 'passfix'.
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Loading facts
> Info: Caching catalog for tlistmrrh511.myhost.net
> Info: Applying configuration version '1539886484'
> *Notice: /Stage[main]/Users::myassword/User[bob]/password: created
> password*
> Notice: Applied catalog in 4.36 seconds
>
> I have tried a number of ways to get this work inside puppet without using
> exec. Searching on this came up with creating custom facts to get the hash
> or hierra, which we don't use, to do this step. Having user hashes
> available as a fact won't pass an audit either. Basically this all needs to
> happen on the Puppet master and be pushed to all clients.
>
> It seems that Puppet has a way to compare the old has with the new one
> when the hash is put between ' ', but I'm passing in a var.
>
> I don't see any indication of why it is failing the comparrison. I have
> even set passwd => generate(... and it behaves the same way.
>
> What am I doing wrong here? It is quite frustrating.
>
> Thanks
>
> --
> 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/4bc322cd-c3bc-44fa-9c6a-1ccd6a778b81%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHaaFtojXTgKCcz_4p0%3DzrAYXivccgh_QCi%2B05t9-Om_aw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] pip package provider on Redhat

[David Schmitt]

To answer your original question: no, there is no way to override the ruby
code without modifying the ruby code.

On Thu, Oct 18, 2018 at 7:41 PM Sergei Gerasenko  wrote:

>
> Yeah, I know we're old. I'm asking in general though (imagining it would
> be happening with the current version for example?), what would be an
> elegant way to fix this?
>
> On Wednesday, October 17, 2018 at 5:22:05 AM UTC-5, Ben Ford wrote:
>
>> Hi Sergei!
>>
>> Puppet 3.x is quite old, and in fact has been end-of-lifed for 655 days
>> as of today! (December 31, 2016). It is no longer receiving security or bug
>> fixes. If you upgrade to a modern version, you'll see that there's are new
>> pip and pip3 providers that use the appropriate commands.
>> https://github.com/puppetlabs/puppet/blob/1707f2ca46867651095e01379bd01dab08076b8b/lib/puppet/provider/package/pip.rb#L55-L65
>>
>>
>> On Wed, Oct 17, 2018 at 11:18 AM Sergei Gerasenko 
>> wrote:
>>
> Hello,
>>>
>>> I'm running puppet 3.5.1 and the pip package provider has this bit:
>>>
>>>   def self.cmd
>>> case Facter.value(:osfamily)
>>>   when "RedHat"
>>> "pip-python"
>>>   else
>>> "pip"
>>> end
>>>   end
>>>
>>> As you can see, when the OS is RedHat, it wants to use the pip-python
>>> command, but it's not available for latest versions of Redhat/CentOS. Is
>>> there an easy way to override the command for that provider without
>>> altering the puppet source code?
>>>
>>> --
>>> 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...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-users/c15b51cd-23fa-4406-ad92-ff3e2b63c839%40googlegroups.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/6351ceeb-5495-4348-bc89-2a74da54ff14%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHb3XGJvz1L%2BEP7sE%3DifvbgST0kqufZ1%2BRMfsF5vuWwhgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Apache module + Ubuntu 18.04 + mpm prefork breaks PHP version

[David Schmitt]

Hi comport3,

would you be interested to contribute this change to the main apache module
 for the benefit of
everyone? If you never have contributed to a public module before check out
David Swan's talk from Puppetize Live:
https://www.youtube.com/watch?v=jIVFq4ZS3_M as a starter.

Cheers, David



On Fri, Oct 19, 2018 at 4:36 AM comport3  wrote:

> OK I have managed to debug this one.
>
> It only seems to apply when using mpm_module: prefork with cgid and/or php
>
> There is a fix to the Apache module as follows:
>  Bump the $php_version in params.pp from 7.0 to 7.2 on line 268
>
> Add this section beneath the preceding logic around line 85/86 in mpm.pp:
>   if $mpm == 'prefork' and $::operatingsystem == 'Ubuntu' and
> $::operatingsystemrelease == '18.04' {
> # workaround
> https://bugs.launchpad.net/ubuntu/+source/mpm-itk/+bug/1286882
> # https://bugs.launchpad.net/ubuntu/+source/php7.2/+bug/1771934
> # https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1782806
> exec {
>   '/usr/sbin/a2dismod mpm_event':
> onlyif  => '/usr/bin/test -e
> /etc/apache2/mods-enabled/mpm_event.load',
> require => Package['httpd'],
> before  => Package['libapache2-mod-php7.2'],
> }
>
> Hopefully this helps someone in the future.
>
> On Thursday, October 18, 2018 at 7:43:55 PM UTC+11, comport3 wrote:
>>
>> Hi All,
>>
>> When testing the latest version of ' puppetlabs-apache', in default mode
>> and settings on Ubuntu 18.04 it works fine.
>>
>> When changing the mpm + php + cgi it all ends in tears when the PHP
>> version mysteriously tries to go from 7.2 (available and default on OS) to
>> 7.0.
>>
>> Ala -
>> ```
>> class { 'apache':
>>   mpm_module => 'prefork'
>> }
>> include ::apache::mod::cgi
>> include ::apache::mod::php
>> ```
>>
>> Any ideas how to override the 7.0 value and get 7.2?
>>
>> If not, how to submit a bug request for the module?
>>
>> Neither of these entries in Hiera did anything useful -
>> apache::params::phpXXX: libapache2-mod-php7.2
>> apache::params::php_version: 7.2
>>
> --
> 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/f3cffaf4-dd68-4c4b-ae87-9398ce0d3d19%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHav6UEVcT1pLiuYws%3DN8J4grPB5-EkB6szdVZ8F6tJA5A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet 6 removed native Nagios provider

[David Schmitt]

Also see https://puppet.com/docs/puppet/6.0/type.html#deprecated-types for
a complete list  and
https://puppet.com/docs/puppet/6.0/release_notes.html#new-features-and-improvements-1
for some background.

Cheers, David

On Fri, Oct 19, 2018 at 6:49 AM Angel L. Mateo  wrote:

>
> El 19/10/18 a las 5:45, comport3 escribió:
> > Hi All,
> >
> > We are testing some Nagios stuff on Puppet 6 and it seems all the
> > previously native functionality was completely removed.
> >
> > Is it available to be re-added via a Module? If not, why was it removed
> > - technical issues, etc??
> >
> https://forge.puppet.com/puppetlabs/nagios_core
>
> --
> Angel L. Mateo Martínez
> Sección de Telemática
> Área de Tecnologías de la Información
> y las Comunicaciones Aplicadas (ATICA)
> http://www.um.es/atica
> Tfo: 868889150
> Fax: 86337
>
> --
> 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/57dee60c-25fa-f855-1ec5-9ba4cea07aa8%40um.es
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

[Puppet Users] [ANN] Resource API v1.6.0 Release

[David Schmitt]

Hi all,

We're pleased to announce that version 1.6.0 of the Resource API is being
released today.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. Using a little bit of ruby, you
can finally get rid of that brittle exec, or manage that one API that
eluded you until now.

It is provided as a Ruby gem to be referenced within modules. Support for
it has been included as an experimental feature in the Puppet Development
Kit (see pdk new provider --help). Use the resource_api module
<https://forge.puppet.com/puppetlabs/resource_api> or the puppet 6 packages
<https://puppet.com/blog/introducing-puppet-6> to deploy it in your
infrastructure.

The new release of the Resource API provides the following enhancements:

   - Allow SimpleProvider to handle composite namevars.
   - Implement allowances for device-specific providers.

The new release also contains the following notable changes:

   - Updates to the README
   - Add testing for supported puppet version branches

See the CHANGELOG
<https://github.com/puppetlabs/puppet-resource_api/blob/master/CHANGELOG.md>
for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. The README
<https://github.com/puppetlabs/puppet-resource_api/blob/master/README.md>
gets you going quickly. To see some example code see this simple Philips
Hue type <https://github.com/da-ar/hue_rsapi> or the Palo Alto firewall
module <https://github.com/puppetlabs/puppetlabs-panos>.

Please let us know of your experiences with the Resource API, either here,
on Slack <https://slack.puppet.com/> (#forge-modules), or on the github repo
<https://github.com/puppetlabs/puppet-resource_api>.

Thanks, David Schmitt
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Custom type and provider

[David Schmitt]

Hi Rafael,

on puppet versions prior to puppet6, you need to install the
puppet-resource_api gem to support the provider. You can use the
puppetlabs-resource_api <https://forge.puppet.com/puppetlabs/resource_api>
module for that.

Cheers, David

On Sun, Sep 23, 2018 at 3:19 AM Rafael Tomelin 
wrote:

> Hi David Schmitt,
>
> I create de new module, class and provider with pdk the according this
> site puppet.  My puppet is version 'puppet --version . 5.5.6'.
>
> But, the return error: *Could not autoload puppet/type/foo: no such file
> to load -- puppet/resource_api *
>
>
> *My type is:*
>
> *cat lib/puppet/type/foo.rb *
>
> require 'puppet/resource_api'
>
>
> Puppet::ResourceApi.register_type(
>
>   name: 'foo',
>
>   docs: <<-EOS,
>
>   This type provides Puppet with the capabilities to manage ...
>
> EOS
>
>   features: [],
>
>   attributes:   {
>
> ensure:  {
>
>   type:'Enum[present, absent]',
>
>   desc:'Whether this resource should be present or absent on the
> target system.',
>
>   default: 'present',
>
> },
>
> name:{
>
>   type:  'String',
>
>   desc:  'The name of the resource you want to manage.',
>
>   behaviour: :namevar,
>
> },
>
>   },
>
> )
>
>
> *My provider:*
>
> *cat lib/puppet/provider/foo/foo.rb *
>
> require 'puppet/resource_api/simple_provider'
>
>
> # Implementation for the foo type using the Resource API.
>
> class Puppet::Provider::Foo::Foo < Puppet::ResourceApi::SimpleProvider
>
>   def get(_context)
>
> [
>
>   {
>
> name: 'foo',
>
> ensure: 'present',
>
>   },
>
>   {
>
> name: 'bar',
>
> ensure: 'present',
>
>   },
>
> ]
>
>   end
>
>
>   def create(context, name, should)
>
> context.notice("Creating '#{name}' with #{should.inspect}")
>
>   end
>
>
>   def update(context, name, should)
>
> context.notice("Updating '#{name}' with #{should.inspect}")
>
>   end
>
>
>   def delete(context, name)
>
> context.notice("Deleting '#{name}'")
>
>   end
>
> end
>
>
> *My init.pp*
>
> *class first_type {*
>
>   foo{ 'my_type':
>
> ensure => present,
>
>   }
>
> }
>
>
> What`s problem : *Could not autoload puppet/type/foo: no such file to
> load -- puppet/resource_api *
>
> The provider write the ruby, is possible create provider with python? If
> yes, is change ruby to python?
>
>
>
> Em sáb, 22 de set de 2018 às 05:29, David Schmitt <
> david.schm...@puppet.com> escreveu:
>
>> Hi Rafael,
>>
>> if you are just starting out with this, I'd highly recommend looking into
>> the Resource API. It makes the development of types much easier, is a
>> supported part of this week's puppet 6 release, and available as a separate
>> download for previous puppet versions. The PDK also has support for getting
>> you started with a ready to go skeleton using 'pdk new provider'.
>>
>> See https://puppet.com/docs/puppet/6.0/custom_resources.html for all the
>> details.
>>
>> Cheers, David
>>
>> On Fri, Sep 21, 2018 at 9:34 PM Rafael Tomelin 
>> wrote:
>>
>>> Hi guys,
>>>
>>> I am creating a type in custom provider, but I am not able to understand
>>> the following question.
>>>
>>> I created a basic type to understand the concept of things, as follows:
>>> Puppet::Type.newtype(:mydir) do
>>> @doc = "First custom type."
>>>
>>> ensurable do
>>> defaultvalues
>>> defaultto :present
>>> end
>>>
>>> newparam(:name, :namevar => true) do
>>> end
>>>
>>> newparam(:install_location) do
>>> end
>>> end
>>>
>>>
>>> After creating the provider, but does not recognize the same and
>>> displays the following error:
>>> Error: Could not find a suitable provider for mydir
>>> Notice: Applied catalog in 0.63 seconds
>>>
>>> Puppet::Type.type(:mydir).provide(:linux) do
>>>
>>> defaultfor :operatingsystem => :linux
>>> confine:operatingsystem => :linux
>>>
>>> commands :mkdir => "mkdir"
>>> commands :rm => "rm"
>>>
>>> def exists?
>>> Puppet.info("checking if is already de

Re: [Puppet Users] Custom type and provider

[David Schmitt]

Hi Rafael,

if you are just starting out with this, I'd highly recommend looking into
the Resource API. It makes the development of types much easier, is a
supported part of this week's puppet 6 release, and available as a separate
download for previous puppet versions. The PDK also has support for getting
you started with a ready to go skeleton using 'pdk new provider'.

See https://puppet.com/docs/puppet/6.0/custom_resources.html for all the
details.

Cheers, David

On Fri, Sep 21, 2018 at 9:34 PM Rafael Tomelin 
wrote:

> Hi guys,
>
> I am creating a type in custom provider, but I am not able to understand
> the following question.
>
> I created a basic type to understand the concept of things, as follows:
> Puppet::Type.newtype(:mydir) do
> @doc = "First custom type."
>
> ensurable do
> defaultvalues
> defaultto :present
> end
>
> newparam(:name, :namevar => true) do
> end
>
> newparam(:install_location) do
> end
> end
>
>
> After creating the provider, but does not recognize the same and displays
> the following error:
> Error: Could not find a suitable provider for mydir
> Notice: Applied catalog in 0.63 seconds
>
> Puppet::Type.type(:mydir).provide(:linux) do
>
> defaultfor :operatingsystem => :linux
> confine:operatingsystem => :linux
>
> commands :mkdir => "mkdir"
> commands :rm => "rm"
>
> def exists?
> Puppet.info("checking if is already deployed")
> deploy_dir = "#{resource[:install_location]}/#{resource[:name]}"
>
> File.directory?(deploy_dir) and Dir.entries(deploy_dir).size > 2
> end
>
> def create
> Puppet.info("Deploying the appliction")
> deploy_dir = "#{resource[:install_location]}/#{resource[:name]}"
>
> mkdir('-p', deploy_dir)
> end
>
> def destroy
> Puppet.info("Removing the appliction")
> deploy_dir = "#{resource[:install_location]}/#{resource[:name]}"
> rm('-rf',deploy_dir)
> end
> end
>
>   What I did not envisage is how Puppet identifies the provider to be used
> in the OS?
> --
>
> Atenciosamente,
>
> Rafael Tomelin
>
> skype: rafael.tomelin
>
> E-mail: rafael.tome...@gmail.com
>
> RHCE  - Red Hat Certified Engineer
> PPT-205 - Puppet Certified Professional 2017
> Zabbix- ZABBIX Certified Specialist
> LPI3
> ITIL v3
>
> --
> 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/CAGEUqbCtgp2bo7CN8STqDxq5L4WZLCJXNT%2Buq7-qzpvVYaL3%2Bg%40mail.gmail.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

[Puppet Users] rake module:push, puppet-blacksmith, and puppet 6

[David Schmitt]

Hi folks,

until tomorrow's PDK and puppetlabs_spec_helper release automated module
release jobs will need to have their puppet pinned to `~> 5.0`, to keep
using the deprecated `puppet module build` command, which was removed in
yesterday's puppet 6.0.0 release.

You can follow along PDK-1100
 for the actual change
required.


Apologies for the additional hiccup along the way,
David
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHZ26Pm5VeAnS1V6JOUOtxubDc8Nqq%3DA2SBHJ2wZ%3Diz3Uw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] [ANN] Resource API v1.5.0 Release

[David Schmitt]

Hi all,

We're pleased to announce that version 1.5.0 of the Resource API has just
been released.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. Using a little bit of ruby, you
can finally get rid of that brittle exec, or manage that one API that
eluded you until now.

It is provided as a Ruby gem that can be installed on all puppet versions
since 4.7, and will be part of puppet6. Support for it has been included as
an experimental feature in the Puppet Development Kit (see pdk new provider
--help). Use the resource_api module
<https://forge.puppet.com/puppetlabs/resource_api> or the puppet 6 nightly
packages
<https://groups.google.com/d/msg/puppet-users/N3LJGhsrqkU/TUEsq7VfDQAJ> to
deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

   - Allow providers to specify a title when there are multiple namevars,
   to make title patterns more usable. PDK-1150
   <https://tickets.puppetlabs.com/browse/PDK-1150> #115
   <https://github.com/puppetlabs/puppet-resource_api/pull/115> (da-ar
   <https://github.com/da-ar>)
   - Sensitive values are now usable like any other puppet4 datatype.
   PDK-1092 <https://tickets.puppetlabs.com/browse/PDK-1091> #117
   <https://github.com/puppetlabs/puppet-resource_api/pull/117> (DavidS
   <https://github.com/DavidS>)
   - The puppetlabs-resource_api module now "supports" puppet 6. With the
   integration of Resource API in puppet 6, the module technically is not
   needed anymore. For backwards compatibility, and to provide a uniform
   experience across all puppet versions, it is still available, and will work
   on puppet6 (doing nothing).

The new release also contains the following notable bugfixes:

   - providers that implement simple_get_filter, are now handled correctly.
   MODULES-7679 #113
   <https://github.com/puppetlabs/puppet-resource_api/pull/113> (da-ar
   <https://github.com/da-ar>)
   - default values are not shared across all resource instances anymore.
   #118 <https://github.com/puppetlabs/puppet-resource_api/pull/118> (DavidS
   <https://github.com/DavidS>)

See the CHANGELOG
<https://github.com/puppetlabs/puppet-resource_api/blob/master/CHANGELOG.md>
for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. The README
<https://github.com/puppetlabs/puppet-resource_api/blob/master/README.md>
gets you going quickly. To see some example code see this simple Philips
Hue type <https://github.com/da-ar/hue_rsapi> or this experimental apt_key
provider
<https://github.com/DavidS/puppetlabs-apt/blob/resource-api-experiments/lib/puppet/provider/apt_key2/apt_key2.rb>
.

Please let us know of your experiences with the Resource API, either here,
on Slack <https://slack.puppet.com/> (#forge-modules), or on the github repo
<https://github.com/puppetlabs/puppet-resource_api>.

Thanks, David Schmitt for the Resource API maintainers.
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHaa50emQ%3DE2r2O6QgkUr6XhtFmOvOcdUs%3DCw-see9t_UQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] [ANN] Resource API v1.4.2 Release

[David Schmitt]

Hi all,

We're pleased to announce that version 1.4.2 of the Resource API is being
released today.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. Using a little bit of ruby, you
can finally get rid of that brittle exec, or manage that one API that
eluded you until now.

It is provided as a Ruby gem to be referenced within modules. Support for
it has been included as an experimental feature in the Puppet Development
Kit (see pdk new provider --help). Use the resource_api module
 or the puppet 6 nightly
packages
 to
deploy it in your infrastructure.

The new release of the Resource API following notable bugfix:

   - Allow an attribute with default boolean value to be set correctly #110
    (da-ar
   )

See the CHANGELOG

for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. The README

gets you going quickly. To see some example code see this simple Philips
Hue type  or this experimental apt_key
provider

.

Please let us know of your experiences with the Resource API, either here,
on Slack  (#forge-modules), or on the github repo
.


Thanks, the other David
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

[Puppet Users] [ANN] Resource API v1.4.1 Release

[David Schmitt]

Hi all,

We're pleased to announce that version 1.4.1 of the Resource API is being
released today.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. Using a little bit of ruby, you
can finally get rid of that brittle exec, or manage that one API that
eluded you until now.

It is provided as a Ruby gem to be referenced within modules. Support for
it has been included as an experimental feature in the Puppet Development
Kit (see pdk new provider --help). Use the resource_api module
 or the puppet 6 nightly
packages
 to
deploy it in your infrastructure.

The new release of the Resource API provides the following notable bugfixes:

   - Fix "undefined method `rs_value'" error with metaparams like require
   and subscribe
   - Improve log_exception output from PuppetContext
   - Minor code changes to allow providers be loaded without puppet

See the CHANGELOG

for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. The README

gets you going quickly. To see some example code see this simple Philips
Hue type  or this experimental apt_key
provider

.

Please let us know of your experiences with the Resource API, either here,
on Slack  (#forge-modules), or on the github repo
.

Thanks, the Davids
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHZSZ0RfcXth9SU_c%3DY7wLgdBiqHpYSi858T91G%3DG95vRg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] [ANN] Resource API v1.4.0 Release

[David Schmitt]

Hi all,

We're pleased to announce that version 1.4.0 of the Resource API is being
released today.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. It is provided as a Ruby gem to
be referenced within modules. Support for it has been included as an
experimental feature in version 1.4 of the Puppet Development Kit (pdk new
provider). Use the resource_api module
<https://forge.puppet.com/puppetlabs/resource_api> or the puppet 6 nightly
packages
<https://groups.google.com/d/msg/puppet-users/N3LJGhsrqkU/TUEsq7VfDQAJ> to
deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

   - Purging with resources { 'your_type': purge => true } works now for
   Resource API types. This allows users of your type to clean up everything
   that is not managed by the current catalog. (PDK-1007)
   - Enhanced validation for developers: the Resource API now checks return
   values from get() against the type's definition. This aids in finding
   bugs in the provider itself earlier and can be turned on and off through
   puppet's --strict setting. (PDK-917)
   - To make device-based code better re-usable, the SimpleDevice class now
   also takes configuration as a Hash. (#96)

The new release also contains the following notable bugfixes:

   - Exception handling during batch operations has been fixed to show all
   stack traces for better debugability (#101)
   - Empty (nil) attribute values are not printed from puppet resource
   (#100)
   - Improved error messages on data type errors in the type definition
   (PDK-996)

See the CHANGELOG
<https://github.com/puppetlabs/puppet-resource_api/blob/master/CHANGELOG.md>
for a full list of changes

We encourage all module developers to review the Resource API and use it
when creating types and providers. For reference, there is an example of
its usage in a branch
<https://github.com/DavidS/puppetlabs-apt/blob/resource-api-experiments/lib/puppet/provider/apt_key2/apt_key2.rb>
of the apt module.

Please let us know of your experiences with the Resource API, either here,
on Slack <https://slack.puppet.com/> (#forge-modules), or on the github repo
<https://github.com/puppetlabs/puppet-resource_api>.

Thanks, David Schmitt & David Armstrong
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] How to get Simplecov to report coverage correctly for puppet manifests

[David Schmitt]

On Mon, Jun 18, 2018 at 11:03 AM Darragh Bailey 
wrote:

>
>
>
>
> On Mon, 18 Jun 2018, 09:19 David Schmitt, 
> wrote:
>
>> Hi Darragh,
>>
>> SimpleCov is a ruby-only solution and the puppet code (*.pp) coverage
>> from rspec-puppet does not integrate into it. As far as I can see there is
>> currently no way to get at the raw data without hacking rspec-puppet
>> itself
>> <https://github.com/rodjek/rspec-puppet/blob/3a053673a32587e3507597a7527e1a90a8425cc4/lib/rspec-puppet/coverage.rb#L72>
>> .
>>
>>
>> Cheers, David
>>
>
> Thanks that's good to know. Is there any coverage solution out there for
> puppet code that would produce something like simplecov, rather than just a
> simple summary of resources covered?
>

Not to my knowledge. From the code linked above it should be
straight-forward for an engaged coder to create the required report file in
simplecov's format to upload to a service like http://codecov.io for
display/evaluation purposes. I'm sure the PDK Team would welcome such an
addition.

Cheers, David


>
> --
>
> Darragh Bailey
> "Nothing is foolproof to a sufficiently talented fool" - unknown
>
>
> --
> 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/CACR765_qGFCWsi7vKSPBGLN8V%2BmkMZuUa14u2i8iQxS%2B_Yzrng%40mail.gmail.com
> <https://groups.google.com/d/msgid/puppet-users/CACR765_qGFCWsi7vKSPBGLN8V%2BmkMZuUa14u2i8iQxS%2B_Yzrng%40mail.gmail.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] How to get Simplecov to report coverage correctly for puppet manifests

[David Schmitt]

Hi Darragh,

SimpleCov is a ruby-only solution and the puppet code (*.pp) coverage from
rspec-puppet does not integrate into it. As far as I can see there is
currently no way to get at the raw data without hacking rspec-puppet itself

.


Cheers, David

On Fri, Jun 15, 2018 at 4:04 PM Darragh Bailey 
wrote:

> Hi,
>
>
> I'm to understand how to get a full coverage for puppet code with spec
> tests to be generated so I can get output like the example from simplecov
> at https://github.com/colszowka/simplecov#example-output.
>
> Ideally I would subsequently try to hook into the coverage repo and do
> some post processing looking at where most of the code churn has been in
> our puppet control code repo and target those areas as important for test
> coverage (and likely refactoring).
>
> However I've stuck on not being able to get output from simplecov that
> shows the manifests that were tested by the spec tests, although the
> summary triggered from running 'RSpec::Puppet::Coverage.report!' suggests
> that something was capable of tracking coverage correctly.
>
> Although we have a different layout than normal, my testing so far
> suggests that the reporting simply doesn't work between puppet and
> simplecov.
>
> Usually when something like this happens, I assume I'm doing something
> blindingly stupid, so I've put together some example code that shows my
> problem should anyone like to run through the spec tests from it.
>
> Doing some simple experiments I've pushed up a repository showing the
> issue https://github.com/electrofelix/puppet-simplecov_bug containing 3
> commits
> - (HEAD commit): convert to match more closely skeleton layout from
> https://github.com/garethr/puppet-module-skeleton/blob/master/skeleton/Gemfile
> - (HEAD~1 commit): try to follow a more standard layout
> - (root commit): Use simple define taken from our codebase and matching
> the layout we have as closely as possible
>
>
> Note we're still stuck on Puppet 3.8 and using ruby 2.1.10 via rvm while I
> was doing the spec tests, plan to upgrade to 5 in the near future, so if
> this problem has been solved via something in the puppet engine (some
> suggestions that the multiple loading by puppet was wiping SimpleCov's
> tracking over coverage) and we just need to hurry up that's great.
>
> But no matter what layout/format I seem to try, the simplecov report
> prints nothing as having been covered, e.g.:
>
>
> ***
> Total resources:   9
> Touched resources: 8
> Resource coverage: 88.89%
> Untouched resources:
>
>   Ssh::Config_entry[example custom-host]
>
> Finished in 2.01 seconds (files took 1.05 seconds to load)
> 12 examples, 0 failures
> Coverage report generated for RSpec to /puppet-simplecov_bug/html. 0
> / 67 LOC (0.0%) covered.
>
> COVERAGE:   0.00% -- 0/67 lines in 2 files
>
>
> +--+---+---++-+
> | coverage | file  | lines | missed |
> missing |
>
> +--+---+---++-+
> |   0.00%  | manifests/server/localuser.pp | 67| 67 | 5-13, 15-19,
> 21-34, 36-44, 46-55, 57-76 |
>
> +--+---+---++-+
> 1 file(s) with 100% coverage not shown
>
> ***
>
> RSpec::Puppet::Coverage.report causes the first part to be printed and
> certainly it shows it's tracking coverage on the files touched, however the
> simplecov report at the end does not appear to be able to correlate the
> tests in 'spec/defines/server_localuser_spec.rb' as having tested
> 'manifests/server/localuser.pp'.
>
> Additionally what is missing from both is all files that are not touched
> at all so far by tests, though I do have some code that appears to be able
> to handle that by passing 'track_files("**/*.pp")' to the SimpleCov object
> configuration.
>
>
>
> Thinking maybe I started from the wrong place, I took
> https://github.com/garethr/puppet-module-skeleton and created a fresh
> module from that and then dropped in both the spec file (
> https://github.com/electrofelix/puppet-simplecov_bug/blob/master/spec/defines/server_localuser_spec.rb)
> and define (
> https://github.com/electrofelix/puppet-simplecov_bug/blob/master/manifests/server/localuser.pp)
> that were being tested and the result remained the same.
>
>
> Rspec::Puppet::Coverage.report! gave:
>
> Total resources:   15
> Touched resources: 14
> Resource coverage: 93.33%
> Untouched resources:
>
>   Ssh::Config_entry[example custom-host]
>
>
> But SimpleCov gave:
>
> Coverage report 

Re: [Puppet Users] Exec type and backgrounded processes

[David Schmitt]

That is not surprising to me. To provide maximal flexibility, puppet does
not do any management or cleanup of processes started. As an exercise, try
to define a parameter to exec that specifies how puppet should cleanup
processes after exec: as soon as the exec returns? when the agent run ends?
everything in the control group, or just non-detached processes?

Better to use a proper/any process manager (systemd, init, runit, upstart)
that was purpose built to solve those problems.

Cheers, David

On Tue, May 22, 2018 at 7:38 AM Thomas Müller  wrote:

> Hi
>
> If I define:
>
> exec { '/bin/sleep 300 &':
>   timeout => 10,
> }
>
> and run it with puppet apply: it happily starts the sleep, backgrounds it
> and finishes - leaving the sleep in the background alive.
>
> Is this behaviour as expected? I personally expected that puppet would
> ensure all started processes are killed if once the exec resource finishes.
>
> - Thomas
>
> --
> 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/61aff915-21a1-4945-b346-dbfbcb699391%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Help on puppet (multiple class in single manifest)

[David Schmitt]

* "puppet module generate" is deprecated and does not provide you with the
full set of tools and practices you could be using. Have a look at the PDK
 instead.

* All the classes in a module need to have the module name as base name.
i.e. when your module is called "test", the classes need to be called
"test::install", and "test::config". `pkd new class` does that
automatically for you.

* Each class needs to go into its own file. e.g. the "test::config" class
goes into "manifests/config.pp". Especially with bigger modules, this
allows for a much better navigation in the source. Again, `pkd new class`
does that automatically for you.

Cheers, David

On Wed, May 9, 2018 at 6:56 PM Alessandro Ciappei 
wrote:

> Hello all,
>
> I'm new on puppet, and i try to create one deployment for my company by
> satellite 6 and puppet.
> I would like to create a module, with single manifest, and inside multiple
> classes.
> I need to choose each class separately, because will be installed in
> different server for same application
>
> then i created module with
>
> puppet module generate
> i fill all metadata.json
>
> Inside in manifest
> i create init.pp and some other files called test-install.pp and
> test-config.pp
>
> #init.pp
>
> class test {
>
>   include redis::install
>
>   include redis::config
>
> }
>
>
> #test-install
>
>
> class redis::install inherits test{
>
>
>
> exec {
>
> "Disable Transparent Huge Pages":
>
> command => '/usr/bin/echo never >
> /sys/kernel/mm/transparent_hugepage/enabled',
>
> onlyif =>  '/usr/bin/test -f
> /sys/kernel/mm/transparent_hugepage/enabled',
>
> }
>
>
>
> package { ['redis','filebeat-5.3.2']:
>
> ensure   => present,
>
> provider => yum,
>
> #install_option => ['--enablerepo=R_EPEL_RHEL7_Yum']
>
> #source   => File['nameofrpm_rpm']['path'],
>
> #require  => File['nameofrpm_rpm'],
>
> }
>
> }
>
>
> #test-config
>
>
> class redis::config inherits test {
>
>
>
> exec {
>
>"Move FILEXXX to right path in PATH":
>
> command => '/usr/bin/mv
> /cs/ecommint/etc/systemd/system/*.service /etc/systemd/system/',
>
> #   onlyif =>  "test -e /cs/ecommint/systemd/system/*.service",
>
> #   require => File["/cs/eccomint/systemd/system/*service"]
>
> }
>
> exec {
>
> "Reload System Control Deamon":
>
> command => '/usr/bin/systemctl deamon-reload',
>
> }
>
> }
>
>
>
>
> But it's not working
>
>
> Some one can help me?
>
> --
> 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/f07dd07c-3fef-410d-99ad-0e7a0c310615%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

[Puppet Users] [ANN] Resource API v1.2 Release

[David Schmitt]

Hi all,

We're pleased to announce that version 1.2 of the Resource API is being
released today.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. It is provided as a Ruby gem to
be referenced within modules. Support for it has been included as an
experimental feature in version 1.4 of the Puppet Development Kit (pdk new
provider). Use the resource_api module
 or the puppet 6 nightly
packages
 to
deploy it in your infrastructure.

The new release of the Resource API provides the following enhancements:

   - Provide access to the type definition from the provider. This can be
   useful in advanced scenarios, e.g. for autogenerating API-passthroughs
   based on the resource type. See puppetlabs/puppet-resource_api#72
    and
puppetlabs/puppet-specifications:
   resource-api/README.md#type-definition
   

   for technical details
   - SimpleProvider now throws a usable error when the type does not have
   an ensure attribute. Previously this would have caused confusing errors,
   which were hard to figure out.
   - The Resource API is now shipped as an integral part of the puppet 6
   nightly packages
   .


The new release also contains the following notable bugfixes:

   - ensure values are now passed to puppet as symbols. While the Enum data
   type is a string, puppet expects symbols for ensure to activate its special
   handling for ensure. This version of the Resource API restores the
   symbolization behaviour on the puppet side, without disturbing providers
   expecting a string.
   - The Resource API no longer validates attribute values on resources
   that should be absent. This matches existing puppet behaviour, and is
   necessary to be able to delete resources without having to specify a
   (otherwise) valid configuration.


See the CHANGELOG

for a full list of changes

We encourage all module developers to review the Resource API and use it
when creating types and providers. For reference, there is an example of
its usage in a branch

of the apt module.

Please let us know of your experiences with the Resource API, either here,
on Slack  (#forge-modules), or on the github repo
.

Thanks, David
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] puppet-rspec - external modules? use vendored instead of download?

[David Schmitt]

You can (temporarily) use symlinks
 to
a manually maintained cache to work around this. For a more complete fix,
see PDK-636 , which is
currently in progress.


Cheers, David

On Sun, May 6, 2018 at 10:02 PM Joaquin Menchaca 
wrote:

> I am getting started with puppet-rspec, and I setup my external modules
> required in the site/$module/.fixtures.yml, with something like
>
> ---
> fixtures:
>   forge_modules:
>  apt: puppetlabs/apt
>  stdlib: puppetlabs/stdlib
>  debconf: stm/debconf
>
> I noticed that these are downloaded each and every time I run my tests
> (and with slow internet, this is not fun).  Could I point these to my
> vendored modules instead in ../../modules?
>
> What is typical configuration?
>
> I'm thinking for local development environment, I really do want to use
> vendored modules, not download these puppies each time (or just download if
> I changed metadata.json).  For CI environment, I can see how that'd make
> sense to download each and every time.
>
>
> --
> 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/f4b910e8-365c-437b-993a-8e31d39fb90c%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHZSmC-OjKvUtf_guddB-%2BPdW2Gc7YbJjSki%2B-sOVvt%2BDA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] [ANN] Resource API v1.1 Release

[David Schmitt]

Hi all,

We're pleased to announce that version 1.1 of the Resource API has been
released yesterday.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. It is provided as a Ruby gem to
be referenced within modules. Support for it has been included as an
experimental feature in version 1.4 of the Puppet Development Kit (pdk new
provider). Use the resource_api module
 to deploy it in your
infrastructure.

The new release of the Resource API provides the following enhancements:

   - Arrays are now fully supported as data types (v1.1.0)
   - Read only and init only attributes have that status now fully enforced
   (v1.0.3)

The new release also contains the following notable bugfixes:

   - PDK-911 : handling of
   ensure values changed to use strings: Previous to v1.0.3, in some cases
   ensure values of 'absent' and 'present' would be transformed to ruby
   symbols before passing it on to the provider. This behavior was
   inconsistent with both puppet and other Enums in the Resource API, that
   would always use strings. Providers now need to return and accept the
   strings 'absent' and 'present' instead of the :absent and :present
   symbols.
   - PDK-919 : Boolean
   attributes now work in all cases: In some cases
    puppet can ignore true
   boolean values. The Resource API now works around the issue in a
   transparent way that requires no change to providers.

See the CHANGELOG

for a full list of changes.

We encourage all module developers to review the Resource API and use it
when creating types and providers. For reference, there is an example of
its usage in a branch

of the apt module.

Please let us know of your experiences with the Resource API, either here,
on Slack  (#forge-modules), or on the github repo
.


Thanks,

David
-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHbTL5U2iU-wcVnULerPvw08%2B%3D%2BxgoKvytNrDRLhpOcRrQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Detection of appropriate 'service' provider

[David Schmitt]

[Apologies for the double post]

The other option is to add Gentoo to the list of defaultfor's at
https://github.com/puppetlabs/puppet/blob/0d5b6618b3a9a376625e5df86c349e1df2d88190/lib/puppet/provider/service/systemd.rb#L21


Cheers, David

On Thu, Mar 29, 2018 at 9:08 AM David Schmitt <david.schm...@puppet.com>
wrote:

> You can find the init provider here
> <https://github.com/puppetlabs/puppet/blob/0d5b6618b3a9a376625e5df86c349e1df2d88190/lib/puppet/provider/service/init.rb#L23-L27>.
> Apparently it is very unconstrained, and therefore puppet prefers it over
> the systemd provider. It should be easy enough to change that to also
> exclude Gentoo, if it has switched to systemd now.
>
>
> Cheers, David
>
> On Wed, Mar 28, 2018 at 4:54 PM Dave F <d.f...@bath.ac.uk> wrote:
>
>> Thanks for the hint David, but still stuck..
>>
>> The relevant output from the gentoo box is:
>>
>> Debug: Puppet::Type::Service::ProviderOpenrc: file /bin/rc-status does
>> not exist
>> Debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-rc.d
>> does not exist
>> Debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does
>> not exist
>> Debug: Puppet::Type::Service::ProviderUpstart: 0 confines (of 4) were true
>> Debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does
>> not exist
>> Debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not
>> exist
>> Debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does
>> not exist
>> Debug: Puppet::Type::Service::ProviderRedhat: file /sbin/chkconfig does
>> not exist
>> Debug: Puppet::Type::Service::ProviderOpenbsd: file /usr/sbin/rcctl does
>> not exist
>> Warning: Found multiple default providers for service: init, systemd;
>> using init
>>
>> So it looks like it only displays the service providers it cannot find
>> - so tried running it on one of the raspbian boxes which don't have init
>> and are detecting systemd properly and i see:
>>
>> Debug: Puppet::Type::Service::ProviderInit: false value when expecting
>> true
>>
>> Which really isn't telling me much about what's attempting to be
>> detected, what's reporting false when the test is expecting true.
>>
>> Searching the github 'puppetlabs/puppet' repository for ProviderInit but
>> found nothing - so I can't workout what part of the source code is doing
>> the tests.
>>
>> Dave
>>
>>
>> --
>> 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/4354faf5-00d0-4033-a34c-57a4034e613f%40googlegroups.com
>> <https://groups.google.com/d/msgid/puppet-users/4354faf5-00d0-4033-a34c-57a4034e613f%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
> --
> Cheers, David
>
> https://twitter.com/dev_el_ops
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Detection of appropriate 'service' provider

[David Schmitt]

You can find the init provider here
.
Apparently it is very unconstrained, and therefore puppet prefers it over
the systemd provider. It should be easy enough to change that to also
exclude Gentoo, if it has switched to systemd now.


Cheers, David

On Wed, Mar 28, 2018 at 4:54 PM Dave F  wrote:

> Thanks for the hint David, but still stuck..
>
> The relevant output from the gentoo box is:
>
> Debug: Puppet::Type::Service::ProviderOpenrc: file /bin/rc-status does not
> exist
> Debug: Puppet::Type::Service::ProviderDebian: file /usr/sbin/update-rc.d
> does not exist
> Debug: Puppet::Type::Service::ProviderDaemontools: file /usr/bin/svc does
> not exist
> Debug: Puppet::Type::Service::ProviderUpstart: 0 confines (of 4) were true
> Debug: Puppet::Type::Service::ProviderGentoo: file /sbin/rc-update does
> not exist
> Debug: Puppet::Type::Service::ProviderRunit: file /usr/bin/sv does not
> exist
> Debug: Puppet::Type::Service::ProviderLaunchd: file /bin/launchctl does
> not exist
> Debug: Puppet::Type::Service::ProviderRedhat: file /sbin/chkconfig does
> not exist
> Debug: Puppet::Type::Service::ProviderOpenbsd: file /usr/sbin/rcctl does
> not exist
> Warning: Found multiple default providers for service: init, systemd;
> using init
>
> So it looks like it only displays the service providers it cannot find
> - so tried running it on one of the raspbian boxes which don't have init
> and are detecting systemd properly and i see:
>
> Debug: Puppet::Type::Service::ProviderInit: false value when expecting true
>
> Which really isn't telling me much about what's attempting to be detected,
> what's reporting false when the test is expecting true.
>
> Searching the github 'puppetlabs/puppet' repository for ProviderInit but
> found nothing - so I can't workout what part of the source code is doing
> the tests.
>
> Dave
>
>
> --
> 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/4354faf5-00d0-4033-a34c-57a4034e613f%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Detection of appropriate 'service' provider

[David Schmitt]

Look at the agent's --debug output. In the preamble there is a section on
how providers get selected.

Cheers, David

On Tue, Mar 27, 2018 at 7:17 PM Dave F  wrote:

> I'm using puppet to look after a mix of raspbian and gentoo OS's.  This is
> going pretty well so far - but I've hit an annoying issue that on the
> Gentoo OS, I'm seeing this:
>
> Warning: Found multiple default providers for service: init, systemd;
> using init
>
> which is annoying because my gentoo box is actually running systemd.
>
> I've had a look through the docs, and know that I can override this -
> possibly by using facts to find the OS version and then setting the
> provider attribute for any service resource I'm using - but this seems an
> overly complicated approach.
>
> What I can't do is find documentation on how/why puppet thinks my gentoo
> system is using init and systemd.  All the docs says is "You will seldom
> need to specify this — Puppet will usually discover the appropriate
> provider for your platform."
>
> And in 5.5 documentation, there isn't even a provider attribute listed for
> services anyway.
>
> Any clue as to how/where puppet gets this from? So I can try and workout
> what's up with my Gentoo box that makes puppet thinks it's using init.
>
> Thanks
> Dave
>
> --
> 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/6285ba22-5e13-458e-8d93-bb123c7939ab%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Updated manifest, now get Failed to apply catalog: "\xF8\xDD" on UTF-16LE on Windows

[David Schmitt]

Hi,

try an advanced text editor like https://code.visualstudio.com/ or
https://notepad-plus-plus.org/ which displays the encoding of the files.
That way you can identify and fix the one that is off (not in UTF-8).
VSCode is also maintained and has a puppet plugin
.

Other than that, 程伟 had it right: try enabling the --debug and --trace
options on either your agent and/or your server to get a hint which file's
encoding is wrong.

Cheers, David


On Mon, Mar 26, 2018 at 8:58 PM jmp242  wrote:

> I'm using puppet 5.3.3 and had been using a previous version of my module
> for a long time. Now I added another package to my management and started
> getting an odd error:
> Failed to apply catalog: "\xF8\xDD" on UTF-16LE
>
> The actual underlying chocolatey packages install correctly. Any ideas
> what this error means? What I need to debug? I use Gepetto to author the
> edits and check into SVN... It almost sounds like a file format issue, but
> I don't know in Gepetto how to change / fix this.
>
> --
> 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/1776d069-6506-4d59-acdf-8309e16af250%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

[Puppet Users] Announcement: Resource API v1.0 release

[David Schmitt]

Hi all,

We're pleased to announce that version 1.0 of the Resource API
 is being launched today.

The Resource API provides a simple way to create new native resources in
the form of types and providers for Puppet. It is provided as a Ruby gem to
be referenced within modules. Support for it has been included as an
experimental feature in version 1.4 of the Puppet Development Kit
 (`pdk new provider`).

The Resource API provides the following functionality:


   -

   Simple type and provider definition.
   -

   Use Puppet 4+ data types.
   -

   Canonicalize, simple_get_filter, and remote_resource features.
   -

   Logging facilities.
   -

   New providers are compatible with all puppet commands:
   -

  puppet apply
  -

  puppet resource
  -

  puppet agent
  -

  puppet device (if applicable)


To ease adoption of the Resource API there is a module
 on the Forge to install
it in your Puppet Server or Puppet Agent. The Resource API gem must be
installed in order to use modules that have types and providers created
using the Resource API. In the future we are planning to bundle the
Resource API with the Puppet platform.

We encourage all module developers to review the Resource API and use it
when creating modules that have types and providers. For reference, there
is an example of its usage in a branch

of the apt module.

Please let us know of your experiences with the Resource API.

Thanks.



-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHZFvvKGWrCgNU-wckrGCei9x%3DLZdCc7Tu18U%2Bu6fene0w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: rspec testing a custom puppet provider that has a parent

[David Schmitt]

On Thu, Mar 22, 2018 at 1:38 PM Bill Sirinek  wrote:

> My *type *file calls Puppet::Type.newtype() as you suggest, but the code
> snippet you were referring to was for my *provider*, so I think
> Puppet::Type.type(:myapp_config).provide
>
> is correct here. The type/provider itself actually works. I have verified
> that by actually using the module. I am in the process of writing tests for
> modules where we did not do so before.
>

Oh yeah, sorry. You're right.


>
> There are two providers for my type. One of them, the one showing this
> error when running tests, manages an ini-style configuration file, so I
> defined Puppet::Type.type(:ini_setting).provider(:ruby) as a parent
> provider. That is part of the puppetlabs/inifile module. My test fails
> because it doesnt seem to be able to find this? From what I can see,
> Puppet::Type.type(:ini_setting).provider(:ruby) is nil when the test runs.
> I included the inifile module in my .fixtures.yml  but apparently that
> doesnt fix it.
>

Hmm. can you provide the module's source, so we can have a look at it? If
you can't publish it, please send it to pdk-maintain...@puppet.com.



>
> As for the facts, the test code I for testing this type/provider started
> out as a copy and paste so I wont be able to deal with the facts until I
> get past this issue, but to answer your question, one big issue I ran into
> with PDK's default handling of facts is that it uses rspec-puppet-facts
> which does not seem to support Solaris 10 anymore, or at least I hadnt
> gotten it to work. So I have been having to keep Solaris 10 out of my
> metadata.json file, even though it probably should be there as Solaris 10
> is supported by Puppet in my version of PE (2017.3.5)
>

I see you already found your way around to adding the facts to facterdb.
Thanks a lot!

Cheers, David


>
> Bill
>
>
> On Wednesday, March 21, 2018 at 9:57:34 AM UTC-4, Bill Sirinek wrote:
>>
>> I am trying to write an rspec test for a custom type and provider I wrote
>> and having issues.
>>
>> The custom type has a provider that manages an ini file. Because I
>> already have puppetlabs/inifile, I made this provider a child provider of
>> ini_setting.  (I don't use the ini_setting type directly in my manifests,
>> because some versions of the application use a command line tool talking to
>> a DB for configuration, rather than a plaintext ini file, and my custom
>> type supports both)   The type/provider code works in puppet, I'm writing
>> tests for our modules after the fact. :\
>>
>> lib/puppet/provider/ini_style_config.rb:
>>
>> Puppet::Type.type(:myapp_config).provide(
>>   :ini_style_config,
>>   :parent => Puppet::Type.type(:ini_setting).provider(:ruby)
>>   ) do
>>   desc "configuration items for version of the app that uses an .ini
>> file"
>>
>>  < ... provider code ... >
>>
>> spec/lib/puppet/provider/ini_style_config_spec.rb:
>>
>> require 'spec_helper'
>>
>>
>> describe Puppet::Type.type(:myapp_config).provider(:ini_style_config) do
>>
>>
>>   on_supported_os.each do |os, facts|
>> context "on #{os}" do
>>   before :each do
>> Facter.clear
>> facts.each do |k, v|
>>   Facter.stubs(:fact).with(k).returns Facter.add(k) { setcode {
>> v } }
>> end
>>   end
>>
>>
>>   describe 'instances' do
>> it 'should have an instance method' do
>>   expect(described_class).to respond_to :instances
>> end
>>   end
>>
>>
>>   describe 'prefetch' do
>> it 'should have a prefetch method' do
>>   expect(described_class).to respond_to :prefetch
>> end
>>   end
>> end
>>   end
>> end
>>
>>
>> When I run the tests I get an error because it can't find the ini_setting
>> type from puppetlabs/inifile:
>>
>>
>>
>> mymacbook:myapp bsirinek$ pdk test unit
>> [✔] Preparing to run the unit tests.
>> [✖] Running unit tests.
>>
>>
>> An error occurred while loading ./spec/unit/puppet/provider/
>> ini_style_config_spec.rb.
>> Failure/Error: :parent => Puppet::Type.type(:ini_setting).provider(:ruby)
>>
>>
>> Puppet::Error:
>>   Could not autoload puppet/type/myapp_config: Could not autoload puppet/
>> provider/myapp_config/ini_style_config: undefined method `provider' for
>> nil:NilClass
>> # ./lib/puppet/provider/myapp_config/ini_style_config.rb:3:in `> required)>'
>> #
>> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:68:in
>> `load'
>> #
>> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:68:in
>> `load_file'
>> #
>> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:83:in
>> `block in loadall'
>> #
>> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:81:in
>> `each'
>> #
>> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:81:in
>> `loadall'
>> #
>> 

Re: [Puppet Users] rspec testing a custom puppet provider that has a parent

[David Schmitt]

Hi Bill,

On Wed, Mar 21, 2018 at 1:57 PM Bill Sirinek  wrote:

> I am trying to write an rspec test for a custom type and provider I wrote
> and having issues.
>
> The custom type has a provider that manages an ini file. Because I already
> have puppetlabs/inifile, I made this provider a child provider of
> ini_setting.  (I don't use the ini_setting type directly in my manifests,
> because some versions of the application use a command line tool talking to
> a DB for configuration, rather than a plaintext ini file, and my custom
> type supports both)   The type/provider code works in puppet, I'm writing
> tests for our modules after the fact. :\
>
> lib/puppet/provider/ini_style_config.rb:
>
> Puppet::Type.type(:myapp_config).provide(
>

this should be `newtype`, not `type`.



>   :ini_style_config,
>   :parent => Puppet::Type.type(:ini_setting).provider(:ruby)
>   ) do
>   desc "configuration items for version of the app that uses an .ini file"
>
>  < ... provider code ... >
>
> spec/lib/puppet/provider/ini_style_config_spec.rb:
>
> require 'spec_helper'
>
>
> describe Puppet::Type.type(:myapp_config).provider(:ini_style_config) do
>
>
>   on_supported_os.each do |os, facts|
> context "on #{os}" do
>   before :each do
> Facter.clear
> facts.each do |k, v|
>   Facter.stubs(:fact).with(k).returns Facter.add(k) { setcode { v
> } }
> end
>   end
>

Did you run into issues with the default fact stubbing ala
https://github.com/puppetlabs/pdk-templates/blob/046d65e6310c68c2209b7c41c73511b9821c1e79/object_templates/class_spec.erb#L6
?


>
>
>   describe 'instances' do
> it 'should have an instance method' do
>   expect(described_class).to respond_to :instances
> end
>   end
>
>
>   describe 'prefetch' do
> it 'should have a prefetch method' do
>   expect(described_class).to respond_to :prefetch
> end
>   end
> end
>   end
> end
>
>
> When I run the tests I get an error because it can't find the ini_setting
> type from puppetlabs/inifile:
>
>
>
> mymacbook:myapp bsirinek$ pdk test unit
> [✔] Preparing to run the unit tests.
> [✖] Running unit tests.
>
>
> An error occurred while loading ./spec/unit/puppet/provider/
> ini_style_config_spec.rb.
> Failure/Error: :parent => Puppet::Type.type(:ini_setting).provider(:ruby)
>
>
> Puppet::Error:
>   Could not autoload puppet/type/myapp_config: Could not autoload puppet/
> provider/myapp_config/ini_style_config: undefined method `provider' for
> nil:NilClass
> # ./lib/puppet/provider/myapp_config/ini_style_config.rb:3:in ` required)>'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:68:in
> `load'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:68:in
> `load_file'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:83:in
> `block in loadall'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:81:in
> `each'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:81:in
> `loadall'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:208:in
> `loadall'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/metatype/manager.rb:126:in
> `newtype'
> # ./lib/puppet/type/myapp_config.rb:1:in `'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:68:in
> `load'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:68:in
> `load_file'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/util/autoload.rb:194:in
> `load'
> #
> /opt/puppetlabs/pdk/share/cache/ruby/2.1.0/gems/puppet-5.3.3/lib/puppet/metatype/manager.rb:171:in
> `type'
> # ./spec/unit/puppet/provider/ini_style_config_spec.rb:3:in ` (required)>'
> # --
> # --- Caused by: ---
> # NoMethodError:
> #   undefined method `provider' for nil:NilClass
> #   ./lib/puppet/provider/myapp_config/ini_style_config.rb:3:in ` (required)>'
>   Evaluated 0 tests in 0.00058 seconds: 0 failures, 0 pending.
> [✔] Cleaning up after running unit tests.
> mymacbook:myapp bsirinek$
>
>
> I have inifile listed in my .fixtures.yml.
>
> ---
> fixtures:
>   symlinks:
> myapp: "#{source_dir}"
>   forge_modules:
> stdlib:
>   repo: "puppetlabs/stdlib"
>   ref: "4.20.0"
> inifile:
>   repo: "puppetlabs/inifile"
>   ref: "2.0.0"
>
>
> Am I missing something?
>
> Thanks
>
> Bill
>
>
> --
> 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
> 

Re: [Puppet Users] unit tests failing on augeas resources in defined type

[David Schmitt]

fraction = 0,
>   Boolean $manage_zfs_arc_cache = true,
>   Hash$kernel_settings = lookup('etc_system::kernel_settings', {
> 'value_type' => Hash, 'merge' => 'hash', 'default_value' => {} })
> ) {
>
>
>   # We only run this on Solaris...
>   if $facts['os']['family'] == 'Solaris' {
>
>
> if $zfs_fraction <= 0 {
>   if $::is_prod {
> $_zfs_fraction = 3
>   }
>   else {
> $_zfs_fraction = 10
>   }
> }
> else {
>   $_zfs_fraction = $zfs_fraction
> }
>
>
> create_resources('etc_system::solaris_kernel_parameter',
> $kernel_settings)
>
>
> # Below we calculate the zfs cache size using the memorysizeinbytes
> fact.
> # If this fact isn't present, then the zfs cache size is not set.
> if $facts['memorysizeinbytes'] and $manage_zfs_arc_cache {
>
>
>   $zfscache = $facts['memorysizeinbytes'] / $_zfs_fraction
>
>
>   etc_system::solaris_kernel_parameter { 'zfs_arc_max':
> module => 'zfs',
> value  => inline_template('0x<%= @zfscache.to_s(16) %>')
>   }
>
>
> }
>   }
>   else {
> fail("The etc_system module is only intended to run on Solaris hosts."
> )
>   }
> }
>
>
> spec/spec_helper.rb:
>
> require 'puppetlabs_spec_helper/module_spec_helper'
> require 'rspec-puppet'
> require 'rspec-puppet-augeas'
> # require 'rspec-puppet-facts'
> # include RspecPuppetFacts
>
>
> default_facts = {
>   puppetversion: Puppet.version,
>   facterversion: Facter.version,
> }
>
>
> default_facts_path = File.expand_path(File.join(File.dirname(__FILE__),
> 'default_facts.yml'))
> default_module_facts_path = File.expand_path(File.join(File.dirname(
> __FILE__), 'default_module_facts.yml'))
>
>
> if File.exist?(default_facts_path) && File.readable?(default_facts_path)
>   default_facts.merge!(YAML.safe_load(File.read(default_facts_path)))
> end
>
>
> if File.exist?(default_module_facts_path) && File.readable?(
> default_module_facts_path)
>   default_facts.merge!(YAML.safe_load(File.read(default_module_facts_path
> )))
> end
>
>
> RSpec.configure do |c|
>   c.default_facts = default_facts
>   c.module_path = File.join(File.dirname(File.expand_path(__FILE__)),
> 'fixtures', 'modules')
>   c.manifest_dir = File.join(File.dirname(File.expand_path(__FILE__)),
> 'fixtures', 'manifests')
>   c.augeas_fixtures = File.join(File.dirname(File.expand_path(__FILE__)),
> 'fixtures', 'augeas')
> end
>
> I commented out the rspec-puppet-facts stuff in my spec file because that
> module does not support Solaris 10.
>
> The spec/default_facts.yml file is the default PDK puts down:
>
> # Use default_module_facts.yml for module specific facts.
> #
> # Facts specified here will override the values provided by
> rspec-puppet-facts.
> ---
> concat_basedir: "/tmp"
> ipaddress: "172.16.254.254"
> is_pe: false
> is_prod: false
> macaddress: "AA:AA:AA:AA:AA:AA"
>
>
> Here is my custom spec/default_module_facts.yml:
>
> ---
> architecture: "i86pc"
> hardwaremodels:
>   - "i86pc"
> kernel: "SunOS"
> kernelmajversion: "Generic_142901-14"
> kernelversion: "Generic_142901-14"
> operatingsystem: "Solaris"
> operatingsystemmajrelease: "10"
> os:
>   architecture: "i86pc"
>   family: "Solaris"
>   hardware: "i86pc"
>   name: "Solaris"
>   release:
> full: "10_u8"
> major: "10"
> minor: "8"
> osfamily: "Solaris"
>
>
>
> Thanks
>
> Bill
>
>
>
>
>
>
> On Monday, February 26, 2018 at 5:59:23 AM UTC-5, David Schmitt wrote:
>
>> Hi Bill,
>>
>> from the code snippets you posted, nothing should be trying to initialize
>> SSL (and thus causing this issue). Can you post the entire module somewhere
>> for inspection? specifically your spec_helper.rb would be of interest. If
>> you can't post it publicly, you can send a copy to pdk-mai...@puppet.com,
>> a private alias.
>>
>> I've tried adding your code to an example module (
>> https://github.com/DavidS/tmp-aug) but didn't get it to work in short
>> order.
>>
>>
>>
>> Cheers, David
>>
>> On Tue, Feb 20, 2018 at 6:05 PM Bill Sirinek <bi...@sirinek.com> wrote:
>>
>
>>> I am continuing to work on unit tests for modules using PDK, and am
>>> having issues with the augeas resources.
>>> I added rspec-puppet-augeas to my Gemfil

Re: [Puppet Users] unit tests failing on augeas resources in defined type

[David Schmitt]

Hi Bill,

from the code snippets you posted, nothing should be trying to initialize
SSL (and thus causing this issue). Can you post the entire module somewhere
for inspection? specifically your spec_helper.rb would be of interest. If
you can't post it publicly, you can send a copy to
pdk-maintain...@puppet.com, a private alias.

I've tried adding your code to an example module (
https://github.com/DavidS/tmp-aug) but didn't get it to work in short order.



Cheers, David

On Tue, Feb 20, 2018 at 6:05 PM Bill Sirinek  wrote:

>
> I am continuing to work on unit tests for modules using PDK, and am having
> issues with the augeas resources.
> I added rspec-puppet-augeas to my Gemfile.local and pdk installed it, so
> that part is fine.
>
> However, when I run the unit tests, the augeas resource fails. I tried
> this on both my laptop running OSX 10.12.6, and on a RHEL 7.3 host, both
> with the same PDK version (1.3.2) and rspec-puppet-augeas gem (0.4.0)
>
> I am doing these tests as myself, and not as root. I get errors because
> something is trying to chown a file's owner to 0. My resource isn't
> managing the owner/group/permissions of the file.
>
> *RHEL output:*
>
> bsirinek@rhelhost $ pdk test unit
> [✔] Preparing to run the unit tests.
> [✖] Running unit tests.
>   Evaluated 12 tests in 1.396288548 seconds: 1 failures, 0 pending.
> [✔] Cleaning up after running unit tests.
> failed: rspec: ./spec/defines/etc_system_solaris_kernel_parameter_spec.rb:
> 24: Got 2 failure(s) while initializing: File[/tmp/d20180220-14426-bbcvri
> ]: change from 'absent' to 'directory' failed: Failed to set owner to '0':
> Operation not permitted @ chown_internal - /tmp/d20180220-14426-bbcvri;
> File[/tmp/d20180220-14426-129ojbn/ssl]: change from 'absent' to
> 'directory' failed: Failed to set owner to '0': Operation not permitted @
> chown_internal - /tmp/d20180220-14426-129ojbn/ssl
>   etc_system::solaris_kernel_parameter Augeas[ip_squeue_enter] should run
>   Failure/Error:
> }
>   }
>   it "should run" do
> is_expected.to compile
> is_expected.to contain_etc_system__solaris_kernel_parameter(
> 'ip_squeue_enter').with('variable' => 'ip_squeue_enter', 'value' => '4',
> 'operator' => '=', 'module' => 'ip')
>
>
>
>
> *OSX output:*
>
> macbook:etc_system bsirinek$ pdk test unit
> [✔] Preparing to run the unit tests.
> [✖] Running unit tests.
>   Evaluated 12 tests in 2.153173 seconds: 1 failures, 0 pending.
> [✔] Cleaning up after running unit tests.
> failed: rspec: ./spec/defines/etc_system_solaris_kernel_parameter_spec.rb:
> 24: Got 2 failure(s) while initializing: File[/var/folders/vh/58bqgt717s1
> _xvljwqs5cz8jf0n1fx/T/d20180220-31763-cbt2p1]: change from 'absent' to
> 'directory' failed: Failed to set owner to '0': Operation not permitted @
> chown_internal - /var/folders/vh/58bqgt717s1_xvljwqs5cz8jf0n1fx/T/
> d20180220-31763-cbt2p1; File[/var/folders/vh/58bqgt717s1
> _xvljwqs5cz8jf0n1fx/T/d20180220-31763-gjico7/ssl]: change from 'absent'
> to 'directory' failed: Failed to set owner to '0': Operation not
> permitted @ chown_internal - /var/folders/vh/58bqgt717s1
> _xvljwqs5cz8jf0n1fx/T/d20180220-31763-gjico7/ssl
>   etc_system::solaris_kernel_parameter Augeas[ip_squeue_enter] should run
>   Failure/Error:
> }
>   }
>   it "should run" do
> is_expected.to compile
>
>
>
>
>
> *Resource:*
>
> define etc_system::solaris_kernel_parameter(
>   $variable = $title,
>   $module = false,
>   $operator = '=',
>   $value = 0
> ) {
>
>
>   augeas { $variable:
> incl=> '/etc/system',
> lens=> 'Solaris_System.lns',
> changes => [
>   "rm set[./variable='${variable}']",
>   "set set[./variable='${variable}']/variable \'${variable}\'",
>   "ins module before set[./variable='${variable}']/variable",
>   "set set[./variable='${variable}']/module \'${module}\'",
>   "set set[./variable='${variable}']/operator \'${operator}\'",
>   "set set[./variable='${variable}']/value \'${value}\'"
> ],
> onlyif  => "get set[./variable='${variable}']/value != \"${value}\"",
>   }
> }
>
>
> *spec/defines/etc_system_solaris_kernel_parameter_spec.rb:*
>
> require 'spec_helper'
>
>
> describe "etc_system::solaris_kernel_parameter" do
> let(:title) { 'ip_squeue_enter' }
> let(:params) {
>   {
> :value => '4',
> :module => 'ip'
>   }
> }
>   it "has an augeas resource" do
>   should contain_augeas("ip_squeue_enter")
>   end
>
>
>   describe_augeas "ip_squeue_enter", :lens => 'Solaris_System', :target =>
> 'etc/system' do
> let(:title) { 'ip_squeue_enter' }
>
>
> let(:params) {
>   {
> :value => '4',
> :module => 'ip'
>   }
> }
> it "should run" do
>   is_expected.to compile
>   is_expected.to contain_etc_system__solaris_kernel_parameter(
> 'ip_squeue_enter').with('variable' => 'ip_squeue_enter', 'value' => '4',
> 'operator' => '=', 'module' => 'ip')

Re: [Puppet Users] Puppet 5 tests of forked module gives errors

[David Schmitt]

Apologies, I linked you to the wrong section in that document. You need to
run puppet generate types --environment  for each of your
environments. For example, to generate metadata for your production
environment, run: puppet generate types --environment production. And you
need to run this every time you deploy new code to your master.

Cheers, David

On Mon, Feb 19, 2018 at 1:36 PM jmp242 <jp10...@gmail.com> wrote:

> I've been on that page, but it doesn't really tell me what to do. I'm not
> using r10k, nor pe. I don't have a .resource_types directory probably
> because I can't get the isolation to do anything.
> On Monday, February 19, 2018 at 7:51:24 AM UTC-5, David Schmitt wrote:
>
>> Have a look at
>> https://puppet.com/docs/puppet/5.3/environment_isolation.html#generate-types
>> and the surrounding docs.
>>
>> On Fri, Feb 16, 2018 at 8:42 PM jmp242 <jp1...@gmail.com> wrote:
>>
> So I originally conflated 2 different issues, and the one was fixed with
>>> the bugfix referenced in my previous thread. So this one is still happening.
>>>
>>> I have an updated module to test (a forked reboot module) which I have
>>> deployed in my dev environment and code to use the new parameter, however
>>> when I try and apply the manifest I get errors - again 500 on server, this
>>> time that the new parameter doesn't exist. I'm wondering if this is also an
>>> issue with pluginsync or something like that so the client doesn't see the
>>> new module?
>>>
>>> So it was suggested that I needed environment isolation per:
>>> https://puppet.com/docs/puppet/5.3/environment_isolation.html
>>>
>>> I tried it and got:
>>> puppet generate types --environment production
>>> Notice: No custom types were found.
>>>
>>>
>>> puppet generate types --environment dev
>>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in 
>>> `get!':
>>> Could not find a directory environment named 'dev' anywhere in the path:
>>> /etc/puppetlabs/code. Does the directory exist?
>>> (Puppet::Environments::EnvironmentNotFound)
>>> from
>>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in
>>> `push_application_context'
>>> from
>>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:346:in
>>> `run'
>>> from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/
>>> command_line.rb:132:in `run'
>>> from
>>> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in
>>> `execute'
>>> from /opt/puppetlabs/puppet/bin/puppet:5:in `'
>>>
>>> So:
>>> ll /etc/puppetlabs/code
>>> total 0
>>> drwxr-xr-x 4 root root 35 Nov  2 04:12 environments
>>> drwxr-xr-x 2 root root  6 Nov  2 04:12 modules
>>> drwxr-xr-x 3 root root 29 Feb 16 15:33 production
>>>
>>> Now all our modules are in what used to be called directory
>>> environments, as sub directories of environments.
>>> ll /etc/puppetlabs/code/production/
>>> total 0
>>>
>>> ll /etc/puppetlabs/code/environments/
>>> total 0
>>> drwxr-xr-x 4 root root 38 Nov 15 15:43 dev
>>> drwxr-xr-x 6 root root 93 Dec 21 11:36 production
>>>
>>>
>>> So I'm pretty confused how to fix all of this.
>>>
>>> --
>>> 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...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-users/553bda68-7d45-447e-b4fd-890af7ce47df%40googlegroups.com
>>> <https://groups.google.com/d/msgid/puppet-users/553bda68-7d45-447e-b4fd-890af7ce47df%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> Cheers, David
>>
>> https://twitter.com/dev_el_ops
>>
> --
> 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/fbe255a3-4830-4b1e-aeee-b4a32fc7c786%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/fbe255a3-4830-4b1e-aeee-b4a32fc7c786%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Rspec-puppet: left match operand must result in a string

[David Schmitt]

Hi Anthony,

the file with the error should be your own `manifests/init.pp`, the path is
just weird because of the additional setup required for the tests.


Cheers, David

On Sat, Feb 3, 2018 at 2:33 AM Anthony Scudese  wrote:

> Hey,
>
> Unfortunately it seems to be a file that is autogenerated when I run
> pdk test unit
>
> . Is there a way I can stop the clean up process that happens? I'm new to
> rspec and pdk in general.
>
> Thanks,
> Anthony
>
>
> On Thursday, February 1, 2018 at 7:09:56 PM UTC-5, Rob Nelson wrote:
>
>> Can you share the contents of that file, or at least line 30 and a few
>> before and after it?
>>
>> On Thu, Feb 1, 2018 at 6:36 PM Anthony Scudese 
>> wrote:
>>
> Hi all,
>>>
>>> I've grown incredibly frustrated. So I'm trying to write some unit tests
>>> for my puppet modules. I've got PDK installed and running. My first test
>>> runs, "without params", but my second test fails due to a compilation
>>> error. Not sure what the real difference is between the two:
>>>
>>> require 'spec_helper'
>>>
>>> describe 'nuke', type: :class do
>>>   let(:facts) do
>>> {
>>>   :userprofilepaths_array => ['C:\Users\foobar']
>>> }
>>>   end
>>>
>>>   context 'with no params' do
>>> it { should_not compile }
>>>   end
>>>
>>>   context 'with nuke product' do
>>> let(:params) do
>>>   {
>>> :products  => {
>>>   'Nuke 9'  => {
>>> 'version'  => '9.0V5',
>>> 'package_source' => '/abs/path/to/nuke_installer.exe'
>>>   }
>>> }
>>>   }
>>> end
>>>
>>> it { should compile }
>>>   end
>>> end
>>>
>>> The error is:
>>>
>>> failed: rspec: ./spec/classes/nuke_spec.rb:26: error during compilation:
 Evaluation Error: Left match operand must result in a String value. Got an
 Undef Value. at
 /Users/anthony/repos/puppetdev/nuke/spec/fixtures/modules/nuke/manifests/init.pp:30:7
 on node anthonymbpro.local
   nuke with nuke product should compile into a catalogue without
 dependency cycles
   Failure/Error:
   end

   it { should compile }
 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...@googlegroups.com.
>>
>>
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-users/582c5017-ef74-4ca8-894b-01ad6dcf5d19%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>> --
>> Rob Nelson
>>
> --
> 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/d0154dac-4b85-4052-a83f-f4df72067694%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] Puppet 5 tests of forked module gives errors

[David Schmitt]

Have a look at
https://puppet.com/docs/puppet/5.3/environment_isolation.html#generate-types
and the surrounding docs.

On Fri, Feb 16, 2018 at 8:42 PM jmp242  wrote:

> So I originally conflated 2 different issues, and the one was fixed with
> the bugfix referenced in my previous thread. So this one is still happening.
>
> I have an updated module to test (a forked reboot module) which I have
> deployed in my dev environment and code to use the new parameter, however
> when I try and apply the manifest I get errors - again 500 on server, this
> time that the new parameter doesn't exist. I'm wondering if this is also an
> issue with pluginsync or something like that so the client doesn't see the
> new module?
>
> So it was suggested that I needed environment isolation per:
> https://puppet.com/docs/puppet/5.3/environment_isolation.html
>
> I tried it and got:
> puppet generate types --environment production
> Notice: No custom types were found.
>
>
> puppet generate types --environment dev
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/environments.rb:38:in 
> `get!':
> Could not find a directory environment named 'dev' anywhere in the path:
> /etc/puppetlabs/code. Does the directory exist?
> (Puppet::Environments::EnvironmentNotFound)
> from
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application_support.rb:29:in
> `push_application_context'
> from
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/application.rb:346:in
> `run'
> from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/
> command_line.rb:132:in `run'
> from
> /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/puppet/util/command_line.rb:72:in
> `execute'
> from /opt/puppetlabs/puppet/bin/puppet:5:in `'
>
> So:
> ll /etc/puppetlabs/code
> total 0
> drwxr-xr-x 4 root root 35 Nov  2 04:12 environments
> drwxr-xr-x 2 root root  6 Nov  2 04:12 modules
> drwxr-xr-x 3 root root 29 Feb 16 15:33 production
>
> Now all our modules are in what used to be called directory environments,
> as sub directories of environments.
> ll /etc/puppetlabs/code/production/
> total 0
>
> ll /etc/puppetlabs/code/environments/
> total 0
> drwxr-xr-x 4 root root 38 Nov 15 15:43 dev
> drwxr-xr-x 6 root root 93 Dec 21 11:36 production
>
>
> So I'm pretty confused how to fix all of this.
>
> --
> 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/553bda68-7d45-447e-b4fd-890af7ce47df%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
-- 
Cheers, David

https://twitter.com/dev_el_ops

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

Re: [Puppet Users] How to access a module fact?

[David Schmitt]

Facts are accessed as either global variables, $appdynamics_installed, or
using the facts hash:
https://puppet.com/docs/puppet/5.3/lang_facts_and_builtin_vars.html#the-factsfactname-hash

Cheers, David

On Tue, Jan 23, 2018 at 6:05 PM dkoleary 
wrote:

> Hi;
>
> I'm trying to use a custom module fact.  From what I can see, the fact is
> actually getting loaded but I can't seem to figure out the syntax for
> accessing it inside a module.
>
> The module I'm working on will end up doing much more than is there
> currently but:
>
> class mpiappdynamics (
>   $install_appdynamics = false,
> ) {
>
> ### appdynamics_installed fact installed via module fact.
>
>   if ($install_appdynamics) {
>
> file { '/opt/app/appdynamics':
>   ensure => directory,
>   owner  => '5082',
>   group  => '5032',
>   mode   => '0755',
> }
>
> case $mpiappdynamics::appdynamics_installed {
>   true: {
> $appdyn_t_source = absent
>   }
>   false: {
> $appdyn_t_source = 'file'
>   }
>   default: {
> $appdyn_t_source = 'nasty message goes here'
>   }
> }
>
> #--
> # notifies
> #--
>
> notify { 'install_appdynamics':
>   message => "install_appdynamics is set to: ${install_appdynamics}"
> }
> notify { 'appdynamics_installed':
>   message => "appdynamics_installed is set to:
> ${appdynamics_installed}"
> }
> notify { 'appdyn_t_source':
>   message => "appdyn_t_source is set to: ${appdyn_t_source}"
> }
> }
>
>
>
> I've loaded the custom fact under ${module}/facts.d and that actually
> seems to be working.  On my test host I can execute:
>
> # find /opt/puppetlabs /etc/puppetlabs -name appdynamics_installed -print
> /opt/puppetlabs/puppet/cache/facts.d/appdynamics_installed
> # facter -p appdynamics_installed
> false
>
> with this set up, I would expect to have appdyn_t_source set to 'file',
> but that's not what's happening:
>
> # puppet agent -t
> Notice: Local environment: 'production' doesn't match server specified
> node environment 'appd', switching agent to 'appd'.
> Info: Retrieving pluginfacts
> Info: Retrieving plugin
> Info: Loading facts
> Info: Caching catalog for myhost.mycompany.com
> Info: Applying configuration version '1516730560'
> Notice: install_appdynamics is set to: true
> Notice: /Stage[main]/Mpiappdynamics/Notify[install_appdynamics]/message:
> defined 'message' as 'install_appdynamics is set to: true'
> Notice: appdynamics_installed is set to: false
> Notice: /Stage[main]/Mpiappdynamics/Notify[appdynamics_installed]/message:
> defined 'message' as 'appdynamics_installed is set to: false'
> Notice: appdyn_t_source is set to: nasty message goes here
> Notice: /Stage[main]/Mpiappdynamics/Notify[appdyn_t_source]/message:
> defined 'message' as 'appdyn_t_source is set to: nasty message goes here'
> Notice: Applied catalog in 3.73 seconds
>
>
> This is my first attempt at using a module based custom fact.  I'm psyched
> that I actually got it to load but.. that only takes me so far.
>
> Thanks for any hints/tips/suggestions.
>
> Doug O'Leary
>
>
>
>
>
> --
> 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/42bd6061-82c0-4c76-a145-6a7f3befa360%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Cheers, David

https://twitter.com/dev_el_ops

-- 
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/CALF7fHbOxW-EOnK1sDTaeL8VWrJByOYEe5m1p2ndtc6FAbR7Eg%40mail.gmail.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 <albert.s...@obspm.fr> wrote:

> Le 14/12/2017 à 08:50:38+0000, 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

Re: [Puppet Users] NoMethodError: undefined method `initialize_for_puppet'

[David Schmitt]

If you really need the no longer maintained puppet 3, you'll have a better
time if you go back to one of the ruby versions supported by it, and make
sure that you get gem versions that were current back then.

On Mon, Dec 18, 2017 at 2:40 PM Steve R  wrote:

> hello,
>
> I'm trying to revive some old code, and I'm getting this error when i run
> the puppet agent
>
> I have never called the initialize_for_puppet in any of my
> manifests/modules, could this be something server side?
>
>
>
>
> on the server side:
>
> [2017-12-17 17:06:12] ERROR NoMethodError: undefined method
> `initialize_for_puppet' for
> #
> Did you mean?  initialize_copy
>
> /var/lib/gems/2.3.0/gems/puppet-3.3.2/lib/puppet/network/http/webrick/rest.rb:13:in
> `initialize'
>/usr/lib/ruby/2.3.0/webrick/httpservlet/abstract.rb:86:in `new'
>/usr/lib/ruby/2.3.0/webrick/httpservlet/abstract.rb:86:in
> `get_instance'
>/usr/lib/ruby/2.3.0/webrick/httpserver.rb:138:in `service'
>/usr/lib/ruby/2.3.0/webrick/httpserver.rb:96:in `run'
>
> /var/lib/gems/2.3.0/gems/puppet-3.3.2/lib/puppet/network/http/webrick.rb:35:in
> `block (3 levels) in listen'
>/usr/lib/ruby/2.3.0/webrick/server.rb:296:in `block in
> start_thread'
> [2017-12-17 17:06:12] 168.235.108.200 - - [17/Dec/2017:17:06:12 EST] "GET
> /production/node/web1.tld?transaction_uuid=95ea04b9-614b-4766-beba-346af94ec8dc_on_404=true
> HTTP/1.1" 500 428
> [2017-12-17 17:06:12] - ->
> /production/node/web1.tld?transaction_uuid=95ea04b9-614b-4766-beba-346af94ec8dc_on_404=true
>
> [2017-12-17 17:06:12] ERROR NoMethodError: undefined method
> `initialize_for_puppet' for
> #
> Did you mean?  initialize_copy
>
> /var/lib/gems/2.3.0/gems/puppet-3.3.2/lib/puppet/network/http/webrick/rest.rb:13:in
> `initialize'
>/usr/lib/ruby/2.3.0/webrick/httpservlet/abstract.rb:86:in `new'
>/usr/lib/ruby/2.3.0/webrick/httpservlet/abstract.rb:86:in
> `get_instance'
>/usr/lib/ruby/2.3.0/webrick/httpserver.rb:138:in `service'
>/usr/lib/ruby/2.3.0/webrick/httpserver.rb:96:in `run'
>
> /var/lib/gems/2.3.0/gems/puppet-3.3.2/lib/puppet/network/http/webrick.rb:35:in
> `block (3 levels) in listen'
>/usr/lib/ruby/2.3.0/webrick/server.rb:296:in `block in
> start_thread'
> [2017-12-17 17:06:12] 168.235.108.200 - - [17/Dec/2017:17:06:12 EST] "GET
> /production/file_metadatas/pluginfacts?links=manage=true=.svn=CVS=.git_type=m
> d5 HTTP/1.1" 500 428
> [2017-12-17 17:06:12] - ->
> /production/file_metadatas/pluginfacts?links=manage=true=.svn=CVS=.git_type=md5
>
> [2017-12-17 17:06:12] ERROR NoMethodError: undefined method
> `initialize_for_puppet' for
> #
> Did you mean?  initialize_copy
>
> /var/lib/gems/2.3.0/gems/puppet-3.3.2/lib/puppet/network/http/webrick/rest.rb:13:in
> `initialize'
>/usr/lib/ruby/2.3.0/webrick/httpservlet/abstract.rb:86:in `new'
>/usr/lib/ruby/2.3.0/webrick/httpservlet/abstract.rb:86:in
> `get_instance'
>/usr/lib/ruby/2.3.0/webrick/httpserver.rb:138:in `service'
>/usr/lib/ruby/2.3.0/webrick/httpserver.rb:96:in `run'
>
> /var/lib/gems/2.3.0/gems/puppet-3.3.2/lib/puppet/network/http/webrick.rb:35:in
> `block (3 levels) in listen'
>/usr/lib/ruby/2.3.0/webrick/server.rb:296:in `block in
> start_thread'
> [2017-12-17 17:06:12] 168.235.108.200 - - [17/Dec/2017:17:06:12 EST] "GET
> /production/file_metadata/pluginfacts?links=manage_permissions=use
> HTTP/1.1" 500 428
> [2017-12-17 17:06:12] - ->
> /production/file_metadata/pluginfacts?links=manage_permissions=use
> [2017-12-17 17:06:12] ERROR NoMethodError: undefined method
> `initialize_for_puppet' for
> #
> Did you mean?  initialize_copy
>
> /var/lib/gems/2.3.0/gems/puppet-3.3.2/lib/puppet/network/http/webrick/rest.rb:13:in
> `initialize'
>/usr/lib/ruby/2.3.0/webrick/httpservlet/abstract.rb:86:in `new'
>/usr/lib/ruby/2.3.0/webrick/httpservlet/abstract.rb:86:in
> `get_instance'
>/usr/lib/ruby/2.3.0/webrick/httpserver.rb:138:in `service'
>/usr/lib/ruby/2.3.0/webrick/httpserver.rb:96:in `run'
>
> /var/lib/gems/2.3.0/gems/puppet-3.3.2/lib/puppet/network/http/webrick.rb:35:in
> `block (3 levels) in listen'
>/usr/lib/ruby/2.3.0/webrick/server.rb:296:in `block in
> start_thread'
> [2017-12-17 17:06:12] 168.235.108.200 - - [17/Dec/2017:17:06:12 EST] "GET
> /production/file_metadatas/plugins?links=manage=true=.svn=CVS=.git_type=md5
> H
> TTP/1.1" 500 428
> [2017-12-17 17:06:12] - ->
> /production/file_metadatas/plugins?links=manage=true=.svn=CVS=.git_type=md5
>
> [2017-12-17 17:06:12] ERROR NoMethodError: undefined method
> `initialize_for_puppet' for
> #
> Did you mean?  initialize_copy
>
> /var/lib/gems/2.3.0/gems/puppet-3.3.2/lib/puppet/network/http/webrick/rest.rb:13:in
> `initialize'
>/usr/lib/ruby/2.3.0/webrick/httpservlet/abstract.rb:86:in `new'
>

Re: [Puppet Users] Managing puppet module

[David Schmitt]

Hi Albert,

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?


Cheers, David

Puppet 3:

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 upgrade puppetlabs-apt they say
>
> Notice: Downloading from https://forgeapi.puppet.com ...
> Error: Could not upgrade module 'puppetlabs-apt' (v2.4.0 -> latest)
>   There are 7 newer versions
> No combination of dependency upgrades would satisfy all dependencies
> Dependencies will not be automatically upgraded across major versions
> Upgrading one or more of these modules may permit the upgrade to
> succeed:
> - puppetlabs-stdlib
> Use `puppet module upgrade --force` to upgrade only this module
>
> but puppetlabs-stdlib is already at the last version (just check).
>
> And if I download the puppetlabs-apt and check inside de metadata.json I
> find out :
>
>   "dependencies": [
> {
>   "name": "puppetlabs/stdlib",
>   "version_requirement": ">= 4.16.0 < 5.0.0"
> }
>   ],
>
> and as I know 4.24.0 match the version_requirement
>
> Regards
> --
> Albert SHIH
> xmpp: j...@obspm.fr
> Heure local/Local time:
> Wed Dec 13 14:21:53 CET 2017
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" 

Re: [Puppet Users] pdk and puppetlabs-ntp Gemfile on non-windows?

[David Schmitt]

Again, the difference from -r2.3 to -r2.1 indicates that your original
Gemfile.lock was not generated using the PDK's ruby and gemset, and
therefore all bets were off.

I'm glad it works now for you!


Cheers, David

On Tue, Oct 31, 2017 at 3:36 PM Christopher Wood <christopher_w...@pobox.com>
wrote:

> Thank you for the pointer, now the module does validate using 1.2.1 from
> the xenial deb. I checked validation against the commit in my gist as well
> as current master (fe01174).
>
> For posterity, a diff of the working Gemfile.lock against the previous
> file from my failed validation shows a few differences in the working
> version.
>
> https://gist.github.com/christopherwood/01aec6a03fa500fcaa02be7e4c83a2fe
>
> At my level of experience I suspect I may have tried the validation with
> an empty $HOME/.pdk right when some gems were being shuffled around.
>
> On Tue, Oct 31, 2017 at 02:22:47PM +, David Schmitt wrote:
> >Hi Christopher,
> >
> >I'm running the xenial packages on Debian testing myself, and have no
> >issues with running the pdk validation of the puppetlabs-ntp module.
> If I
> >use the Gemfile.lock from your log instead of a clean one, I get the
> same
> >error. Please remove the Gemfile.lock and try again.
> >
> >Cheers, David
> >On Thu, Oct 26, 2017 at 5:19 PM Christopher Wood
> ><[1]christopher_w...@pobox.com> wrote:
> >
> >  I'm not sure if this is an issue, or something I'm doing, since I'm
> >  trying to use Ubuntu debs on patched-up Debian 9. The question: Is
> this
> >  PEBKAC or what?
> >
> >  To wit, I get a fatal error when attempting "pdk validate -d" and
> "pdk
> >  test unit -d" at 1215f02 of the puppetlabs-ntp module. This happens
> in
> >  the same manner with the following debs.
> >
> >  pdk_1.2.0.0-1trusty_amd64.deb
> >  pdk_1.2.0.0-1xenial_amd64.deb
> >
> >  These gists are typescript sessions of me reproducing the issue:
> >
> >  [2]
> https://gist.github.com/christopherwood/d2ac5542a3cdbf80cba7eaac6135ef14
> >  [3]
> https://gist.github.com/christopherwood/05f60e9f87465e73730606d8870065e7
> >
> >  I think the issue boils down to these lines:
> >
> >  pdk (FATAL): The dependency puppet-module-win-default-r2.1 (>= 0)
> will
> >  be unused by any of the platforms Bundler is installing for.
> Bundler is
> >  installing for ruby but the dependency is only for x86-mswin32,
> >  x86-mingw32, x64-mingw32. To add those platforms to the bundle, run
> >  `bundle lock --add-platform x86-mswin32 x86-mingw32 x64-mingw32`.
> >  The dependency puppet-module-win-dev-r2.1 (= 0.0.7) will be unused
> by
> >  any of the platforms Bundler is installing for. Bundler is
> installing
> >  for ruby but the dependency is only for x86-mswin32, x86-mingw32,
> >  x64-mingw32. To add those platforms to the bundle, run `bundle lock
> >  --add-platform x86-mswin32 x86-mingw32 x64-mingw32`.
> >  The dependency puppet-module-win-system-r2.1 (>= 0) will be unused
> by
> >  any of the platforms Bundler is installing for. Bundler is
> installing
> >  for ruby but the dependency is only for x86-mswin32, x86-mingw32,
> >  x64-mingw32. To add those platforms to the bundle, run `bundle lock
> >  --add-platform x86-mswin32 x86-mingw32 x64-mingw32`.
> >
> >  When I do "gem install --user-install
> puppet-module-win-default-r2.1" on
> >  my system ruby 2.3.3p222 it installs with no issues. However the
> Gemfile
> >  in the puppetlabs-ntp module specifies
> >
> >  :require => false, :platforms => ["mswin", "mingw", "x64_mingw"]
> >
> >  and for some reason that appears to cause an issue here.
> >
> >  I haven't really used bundler so definitely puzzled.
> >
> >  --
> >  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 [4]puppet-users+unsubscr...@googlegroups.com.
> >  To view this discussion on the web visit
> >  [5]
> https://groups.google.com/d/msgid/puppet-users/20171026161936.27u6hl22k2v5olbi%40iniquitous.heresiarch.ca
> .
> >  For more options, visit [6]https://groups.google.com/d/optout.
> >
> >--
> >You received this message because you are subscribed to 

Re: [Puppet Users] pdk and puppetlabs-ntp Gemfile on non-windows?

[David Schmitt]

Hi Christopher,

I'm running the xenial packages on Debian testing myself, and have no
issues with running the pdk validation of the puppetlabs-ntp module. If I
use the Gemfile.lock from your log instead of a clean one, I get the same
error. Please remove the Gemfile.lock and try again.


Cheers, David

On Thu, Oct 26, 2017 at 5:19 PM Christopher Wood 
wrote:

> I'm not sure if this is an issue, or something I'm doing, since I'm trying
> to use Ubuntu debs on patched-up Debian 9. The question: Is this PEBKAC or
> what?
>
> To wit, I get a fatal error when attempting "pdk validate -d" and "pdk
> test unit -d" at 1215f02 of the puppetlabs-ntp module. This happens in the
> same manner with the following debs.
>
> pdk_1.2.0.0-1trusty_amd64.deb
> pdk_1.2.0.0-1xenial_amd64.deb
>
> These gists are typescript sessions of me reproducing the issue:
>
> https://gist.github.com/christopherwood/d2ac5542a3cdbf80cba7eaac6135ef14
> https://gist.github.com/christopherwood/05f60e9f87465e73730606d8870065e7
>
> I think the issue boils down to these lines:
>
> pdk (FATAL): The dependency puppet-module-win-default-r2.1 (>= 0) will be
> unused by any of the platforms Bundler is installing for. Bundler is
> installing for ruby but the dependency is only for x86-mswin32,
> x86-mingw32, x64-mingw32. To add those platforms to the bundle, run `bundle
> lock --add-platform x86-mswin32 x86-mingw32 x64-mingw32`.
> The dependency puppet-module-win-dev-r2.1 (= 0.0.7) will be unused by any
> of the platforms Bundler is installing for. Bundler is installing for ruby
> but the dependency is only for x86-mswin32, x86-mingw32, x64-mingw32. To
> add those platforms to the bundle, run `bundle lock --add-platform
> x86-mswin32 x86-mingw32 x64-mingw32`.
> The dependency puppet-module-win-system-r2.1 (>= 0) will be unused by any
> of the platforms Bundler is installing for. Bundler is installing for ruby
> but the dependency is only for x86-mswin32, x86-mingw32, x64-mingw32. To
> add those platforms to the bundle, run `bundle lock --add-platform
> x86-mswin32 x86-mingw32 x64-mingw32`.
>
> When I do "gem install --user-install puppet-module-win-default-r2.1" on
> my system ruby 2.3.3p222 it installs with no issues. However the Gemfile in
> the puppetlabs-ntp module specifies
>
> :require => false, :platforms => ["mswin", "mingw", "x64_mingw"]
>
> and for some reason that appears to cause an issue here.
>
> I haven't really used bundler so definitely puzzled.
>
> --
> 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/20171026161936.27u6hl22k2v5olbi%40iniquitous.heresiarch.ca
> .
> 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/CALF7fHZw3AzDv3th%2BQyH7ndBPvbx3ggbQunprYTub5snHubRkA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Forge repository timeout

[David Schmitt]

Hi Raphaël,

please use the API v3 (described at https://forgeapi.puppetlabs.com/) to
programmatically access the forge. Using the pagination parameters (offset
and limit) allows much faster and safer traversing of the results. With the
increasing number of modules on the forge, I'm not sure we'll be able to
keep the generated all-in-one JSON around for much longer.

Cheers, David

On Wed, Oct 11, 2017 at 2:11 PM Raphaël Hoareau 
wrote:

> Hi all,
>
> I'm trying to synchronize the Forge repository (https://forge.puppet.com)
> into my Katello install but it fail with connection errors (it was working
> a few weeks ago).
> When trying to download https://forge.puppet.com/modules.json, a simple
> curl/wget tries multiple times before getting the file (and Katello simply
> fails).
>
> [rhoareau@glados ~]$ wget -S https://forge.puppet.com/modules.json
> --2017-10-11 10:45:00-- https://forge.puppet.com/modules.json
> Résolution de forge.puppet.com (forge.puppet.com)… 52.10.130.237
> Connexion à forge.puppet.com (forge.puppet.com)|52.10.130.237|:443…
> connecté.
> requête HTTP transmise, en attente de la réponse…
> HTTP/1.0 504 Gateway Time-out
> Cache-Control: no-cache
> Connection: close
> Content-Type: text/html
> Nouvel essai.
>
> --2017-10-11 10:46:32-- (essai : 2) https://forge.puppet.com/modules.json
> Connexion à forge.puppet.com (forge.puppet.com)|52.10.130.237|:443…
> connecté.
> requête HTTP transmise, en attente de la réponse…
> HTTP/1.0 504 Gateway Time-out
> Cache-Control: no-cache
> Connection: close
> Content-Type: text/html
> Nouvel essai.
>
> --2017-10-11 10:48:05-- (essai : 3) https://forge.puppet.com/modules.json
> Connexion à forge.puppet.com (forge.puppet.com)|52.10.130.237|:443…
> connecté.
> requête HTTP transmise, en attente de la réponse…
> HTTP/1.1 504 Gateway Time-out
> Server: nginx
> Date: Wed, 11 Oct 2017 08:49:36 GMT
> Content-Type: text/html
> Content-Length: 176
> X-App-Server: forge/
> forge-i-437e8aec_forgenext-app04-prod.ops.puppetlabs.net
> X-Lb-Server: forgenext-lb02-prod.ops.puppetl
> X-UUID: 25AB0F9B:F43F_0AE00633:01BB_59DDDAC6_EF89F2B:01F1
> Nouvel essai.
>
> --2017-10-11 10:49:39-- (essai : 4) https://forge.puppet.com/modules.json
> Réutilisation de la connexion existante à forge.puppet.com:443.
> requête HTTP transmise, en attente de la réponse…
> Taille : non indiqué
> Sauvegarde en : « modules.json.1 »
>
> modules.json.1 [ <=> ] 1,67M --.-KB/s ds 68s
>
> 2017-10-11 10:50:48 (25,0 KB/s) - « modules.json.1 » sauvegardé [1749112]
>
> Any information on that ?
>
> Raphaël.
>
> --
> 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/8b5540ef-5110-40d5-80d7-639006084e2c%40googlegroups.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/CALF7fHYknEN8b_EYaTpYiFSPp5AsH7vk4sQCfBEVUe%3D35Q5Eag%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Confusing error with file resource...

[David Schmitt]

On Tue, Oct 3, 2017 at 5:41 PM Sean  wrote:

> Hi,
>
> I have a strange puppet error (v4.10.1) with a file resource that creates
> a cron job...
>
>   file { '/etc/cron.daily/aide':
> ensure  => $mymodule::ensure_aide,
> owner   => 'root',
> group   => 'root',
> mode=> '0755',
> source  => 'puppet:///modules/mymodule/cron/daily-aide-check.sh',
> require => Package['aide'],
>   }
>
> The error is:
>
> Error: Failed to apply catalog: Validation of File[/etc/cron.daily/aide]
> failed: You cannot specify more than one of content, source, target at  file>:line#
>
>
>
> The ensure param is a Variant - either boolean or enum of true, false,
> present, absent, latest.  The code passes the puppet parser and checking
> puppet lookup for $mymodule::ensure_aide for the test node returns a 'true'
> value from the module's hiera data.
>

File's ensure doesn't take boolean values. If the ensure value is not one
of present, absent, file, directory, or link, the value gets interpreted as
a link target name:

david@davids:~$ puppet apply -e 'file {"/tmp/test_file": ensure => true,
content => "bar" }'
Notice: Compiled catalog for davids.corp.puppetlabs.net in environment
production in 0.07 seconds
Error: Validation of File[/tmp/test_file] failed: You cannot specify more
than one of content, source, target at line 1
david@davids:~$ puppet apply -e 'file {"/tmp/test_file": ensure => true }'
Notice: Compiled catalog for davids.corp.puppetlabs.net in environment
production in 0.07 seconds
Error: Could not set 'link' on ensure: FileSystem implementation expected
Pathname, got: 'TrueClass' at line 1
Error: Could not set 'link' on ensure: FileSystem implementation expected
Pathname, got: 'TrueClass' at line 1
Wrapped exception:
FileSystem implementation expected Pathname, got: 'TrueClass'
Error: /Stage[main]/Main/File[/tmp/test_file]/ensure: change from absent to
link failed: Could not set 'link' on ensure: FileSystem implementation
expected Pathname, got: 'TrueClass' at line 1
Notice: Applied catalog in 0.03 seconds
david@davids:~$

see https://docs.puppet.com/puppet/latest/type.html#file-attribute-ensure
for the long-form.

Cheers, David



>
> Any ideas?
>
> --
> 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/64776827-6fe1-49c0-89b1-fc532faa211a%40googlegroups.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/CALF7fHYoFKBb8YbKTzW8T8U3QBu_apH6%2BAeVEbt7hj-OqeA0CQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Question regarding Puppet4 class params and Hiera5

[David Schmitt]

On Tue, Sep 26, 2017 at 6:30 PM Sean <smalde...@gmail.com> wrote:

> Hi David, thanks for your reply.
>
> I can see where I may have confused the intent of my questions with too
> much information.  If someone using the class were to declare something
> like:
>
> class { 'complex':
>   enable_feature1 => false,
>   class_incl_list  => [ 'complex::redhat::subclass1', ],
> }
>
> Will subclass1 obtain the value of enable_feature1 from the above
> declaration?  Suppose the module default in data/common.yaml for
> enable_feature1 is true.
>

There is always only one $complex::enable_feature1 value, and setting it in
the class{} definition will override what's loaded from hiera.

You can get into troubles, when you do inheritance between the subclass,
and the main class, and then override values at different levels. Which is
why I recommend against it. Especially in the case you're outlining, adding
more complexity doesn't buy you anything.

For example, this here is totally fine:

class complex::redhat::subclass1 {
if $complex::enable_feature1 { ... }
}

and will get the expected value for enable_feature1.

To avoid any surprises I also recommend that you always run using --strict,
so nobody can use the subclass standalone and then be surprised by it not
working as intended.


Cheers, David



>
> On Tuesday, September 26, 2017 at 12:13:42 PM UTC-4, David Schmitt wrote:
>>
>>
>>
>> On Tue, Sep 26, 2017 at 4:01 PM Sean <smal...@gmail.com> wrote:
>>
>>> Greetings,
>>>
>>> I have read searched and read several threads in the list regarding
>>> using hiera, automatic lookup, and class params.  Some of them, I'm
>>> thinking relate to Puppet3 and prior, and I admit I'm struggling a bit with
>>> weeding through the information that's appropriate to my scenario of
>>> versions.  Please bear with me.  I am attempting to build a module that
>>> will use Hiera data layers and get away from the params.pp pattern.  The
>>> hope is that customers can use their environment hiera data if they choose,
>>> global data from an ENC, accept the default module layer data or use
>>> resource definition and supply data directly.  Unfortunately the module is
>>> complex and has many sublcasses, the init.pp looks something like:
>>>
>>> class complex (
>>>   Array $class_incl_list,
>>>   Array $class_excl_list,
>>>   Boolean $enable_feature1,
>>>   ...more params that subclasses might use...
>>> ) {
>>>
>>>   validate_array($class_incl_list)
>>>   validate_array($class_excl_list)
>>>
>>
>> Since you have already specified `Array` on the params, you can skip the
>> `validate_array()` call here.
>>
>>
>>>
>>>   $local_incl_list = array_subtract($class_incl_list, $class_excl_list)
>>>
>>>   include $local_incl_list
>>>
>>> }
>>>
>>> The class arrays are strings of fully qualified subclass names, e.g. [
>>> 'complex::redhat::subclass1', 'complex::redhat::subclass2', ] etc.
>>>
>>> Is there a benefit to actually using class params or declaring all
>>> references to class variables directly as fully qualified in the subclasses?
>>>
>>
>> `include` is necessary to make the class - and its resources - available
>> in the catalog. It has no influence over variable namespacing/scope.
>>
>> If that doesn't answer your question, likely I haven't really understood
>> what you were asking.
>>
>>
>>> Here's a simplified example subclass, and yes the example is silly, if
>>> we enable/disable a feature in puppet code, why not just exclude the
>>> subclass altogether.
>>>
>>
>> If you need to have stuff done to *remove* a feature, this pattern is
>> absolutely fine!
>>
>>
>>
>>> Typically, that is what happens, but I was failing to find any other
>>> simplistic examples to provide.
>>>
>>> class complex::redhat::subclass1 (
>>>   Boolean $enable_feature1,
>>> ) {
>>>
>>>   if $enable_feature1 {
>>> notify("${::osfamily} Feature 1 is enabled")
>>>   } else {
>>> notify("${::osfamily} Feature 1 is disabled")
>>>   }
>>>
>>> }
>>>
>>>
>>> Would I be better off removing the class param and using
>>> $::complex::enable_feature1 in the conditional?
>>>
>>
>> Yes.
>>
>>
>>>   The subclasses aren't really meant to be called by the end-user
>>> direct

Re: [Puppet Users] Question regarding Puppet4 class params and Hiera5

[David Schmitt]

On Tue, Sep 26, 2017 at 4:01 PM Sean  wrote:

> Greetings,
>
> I have read searched and read several threads in the list regarding using
> hiera, automatic lookup, and class params.  Some of them, I'm thinking
> relate to Puppet3 and prior, and I admit I'm struggling a bit with weeding
> through the information that's appropriate to my scenario of versions.
> Please bear with me.  I am attempting to build a module that will use Hiera
> data layers and get away from the params.pp pattern.  The hope is that
> customers can use their environment hiera data if they choose, global data
> from an ENC, accept the default module layer data or use resource
> definition and supply data directly.  Unfortunately the module is complex
> and has many sublcasses, the init.pp looks something like:
>
> class complex (
>   Array $class_incl_list,
>   Array $class_excl_list,
>   Boolean $enable_feature1,
>   ...more params that subclasses might use...
> ) {
>
>   validate_array($class_incl_list)
>   validate_array($class_excl_list)
>

Since you have already specified `Array` on the params, you can skip the
`validate_array()` call here.


>
>   $local_incl_list = array_subtract($class_incl_list, $class_excl_list)
>
>   include $local_incl_list
>
> }
>
> The class arrays are strings of fully qualified subclass names, e.g. [
> 'complex::redhat::subclass1', 'complex::redhat::subclass2', ] etc.
>
> Is there a benefit to actually using class params or declaring all
> references to class variables directly as fully qualified in the subclasses?
>

`include` is necessary to make the class - and its resources - available in
the catalog. It has no influence over variable namespacing/scope.

If that doesn't answer your question, likely I haven't really understood
what you were asking.


> Here's a simplified example subclass, and yes the example is silly, if we
> enable/disable a feature in puppet code, why not just exclude the subclass
> altogether.
>

If you need to have stuff done to *remove* a feature, this pattern is
absolutely fine!



> Typically, that is what happens, but I was failing to find any other
> simplistic examples to provide.
>
> class complex::redhat::subclass1 (
>   Boolean $enable_feature1,
> ) {
>
>   if $enable_feature1 {
> notify("${::osfamily} Feature 1 is enabled")
>   } else {
> notify("${::osfamily} Feature 1 is disabled")
>   }
>
> }
>
>
> Would I be better off removing the class param and using
> $::complex::enable_feature1 in the conditional?
>

Yes.


>   The subclasses aren't really meant to be called by the end-user
> directly, so I would never expect to see someone doing a resource
> declaration of a subclass, but I would expect to see a user doing a
> resource declaration of the main class and supplying the enable_feature1
> boolean with it.
>
> Thanks for your thoughts and input.
>


Cheers, David

> --
> 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/f374a512-e5a1-4933-bc0e-405bbc8b44f9%40googlegroups.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/CALF7fHadtWaMaxmHc%2BSf8bfk10ShQ8aNAv3d3oC_Nc-D8GxBxQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] profile template vs module template

[David Schmitt]

According to
http://www.puppetmodule.info/modules/evenup-sssd/puppet_classes/sssd there
is no way to pass in an override to the content of the file.

You can hack it like this:

include ::sssd
File['/etc/sssd/sssd.conf'] {
content => template('profile/sssd.conf.erb'),
source => undef,
}

Cheers, David

On Sat, Sep 16, 2017 at 1:02 AM Asif Iqbal  wrote:

> I need to use a template from profile module instead of from a component
> module and not sure how.
>
> This is what I have tried so far
>
> # cat /etc/puppet/modules/profile/manifests/sssd.pp
> class profile::sssd (
>   $ldap_default_bind_dn = hiera('ldap_default_bind_dn'),
>   $ldap_base = hiera('ldap_base'),
>   $ldap_uri  = hiera('ldap_uri'),
>   $ldap_access_filter = hiera('ldap_access_filter'),
>   $ldap_tls_cacert = hiera('ldap_tls_cacert'),
> ) {
>include ::sssd
>
>file { '/etc/sssd/sssd.conf':
> ensure  => 'file',
> owner   => 'root',
> group   => 'root',
> mode=> '0600',
> content => template('profile/sssd.conf.erb'),
>   }
> }
>
> # cat sssd.pp
> include profile::sssd
>
> # puppet apply sssd.pp
> Error: Duplicate declaration: File[/etc/sssd/sssd.conf] is already
> declared in file /etc/puppet/modules/sssd/manifests/config.pp:26; cannot
> redeclare at /etc/puppet/modules/profile/manifests/sssd.pp:16 on node
> localhost
> Error: Duplicate declaration: File[/etc/sssd/sssd.conf] is already
> declared in file /etc/puppet/modules/sssd/manifests/config.pp:26; cannot
> redeclare at /etc/puppet/modules/profile/manifests/sssd.pp:16 on node
> localhost
>
> I need to setup the config file sssd.conf based on profile's template file
> since some of the parameters I introduced are missing from the component
> module
>
> My component module is  evenup-sssd
>
> Need help for a recommended way to fix this
>
> Thanks
>
> --
> Asif Iqbal
> PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>
> --
> 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/CAOHBbgWWyndHej7L%3D2Sr9M0CzfYUpAvUFeXLCHhQJzfUsbtrLg%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/CALF7fHYd%3DmzjHu4O5reM5zbRmMA4q0L%2Ba34-AhZUk%3DpbmNWCPQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: [ANN] Puppet Development Kit (pdk) 1.0

[David Schmitt]

On Fri, Aug 25, 2017 at 11:40 AM Pete Brown <rendhal...@gmail.com> wrote:

> Does it have support for puppet 5 and can you use it to test code against
> multiple versions of puppet?
>

This kinda works with v1, using the old pattern of setting environment
variables (see this snippet
<https://github.com/puppetlabs/pdk-module-template/blob/5db7961352cda998578e3abf811b35604abb1505/moduleroot/Gemfile.erb#L98-L101>
for details). Obviously this is not a nice workflow, so we're investigating
the best way to expose these settings on the CLI. Follow along in PDK-414
<https://tickets.puppetlabs.com/browse/PDK-414> if you're interested.


> Could it also be used in the manner to test code under a CI/CD setup like
> Jenkins or Travis?
>

Travis is already pre-configured in the pdk-module-template
<https://github.com/puppetlabs/pdk-module-template> (a copy of it is
shipped with the PDK packages, and used by default), but see PDK-447
<https://tickets.puppetlabs.com/browse/PDK-447> and PDK-448
<https://tickets.puppetlabs.com/browse/PDK-448> for some caveats.

 Cheers, David

On Mon, 21 Aug 2017 at 09:57, David Schmitt <david.schm...@puppet.com>
> wrote:
>
>> Hi Charlie,
>>
>> thanks for trying out the PDK!
>>
>> On Mon, Aug 21, 2017 at 2:22 PM Charlie Derwent <
>> shelltoesupers...@gmail.com> wrote:
>>
>>> Can I use the PDK to validate my Roles and Profiles?
>>>
>>
>> The short answer is: Yes, you can.
>>
>>
>>> Keep getting complaints that I'm not in a valid module (missng
>>> metadata.json)
>>>
>>
>> Personally, I'd recommend putting all puppet code deployed to your puppet
>> installation into modules. This makes the code more mobile, and allows your
>> roles and profiles to integrate fully into your code workflows, without any
>> special casing.
>>
>> With the PDK, you can start with `pdk new module` to create the necessary
>> base structures, and then copy over your manifests to try it out.
>>
>> I'd love to hear how it worked out for you!
>>
>>
>> Cheers, David
>>
>>
>>>
>>> On Tuesday, 15 August 2017 21:51:52 UTC+1, Lindsey Smith wrote:
>>>>
>>>> After a few preview releases, we're happy to announce the availability
>>>> of the Puppet Development Kit
>>>> <https://puppet.com/blog/develop-modules-faster-new-puppet-development-kit>
>>>> v1.0! The open-source PDK facilitates an easy, unified development
>>>> workflow for Puppet modules, and should appeal both to newcomers and
>>>> experienced developers.
>>>>
>>>>
>>>> Get the package for your platforms at the PDK download
>>>> <https://puppet.com/download-puppet-development-kit> page, check out the
>>>> docs <https://docs.puppet.com/pdk/latest/index.html> and the code
>>>> lives at puppetlabs/pdk <https://github.com/puppetlabs/pdk>.
>>>>
>>>>
>>>> The Puppet Development Kit makes it easier than ever to develop and
>>>> test Puppet modules by providing a simple, unified interface to a set of
>>>> helpful tools for anyone who writes or consumes Puppet code. Leveraging the
>>>> Puppet Development Kit, it’s now possible to:
>>>>
>>>>-
>>>>
>>>>Quickly get started developing modules using best practices and new
>>>>tools that enable you to create, test and publish high-quality Puppet
>>>>modules with confidence
>>>>-
>>>>
>>>>Shift quality to the left by catching issues earlier and faster
>>>>before Puppet code is applied to live infrastructure
>>>>-
>>>>
>>>>Unit test modules from your Windows or Linux workstation to ensure
>>>>that Puppet code is creating and managing configuration resources as
>>>>intended
>>>>-
>>>>
>>>>Develop and share even more high-quality content for managing
>>>>Windows environments
>>>>
>>>>
>>>> Join us for a webinar
>>>> <http://info.puppet.com/Puppet-Development-Kit-Webinar-Registration.html>
>>>> on Tuesday 22 Aug 2017 to see how you can leverage the new Puppet
>>>> Development Kit to save time and take advantage of the more than 5,000
>>>> modules of pre-written configuration code for managing an entire
>>>> infrastructure - everything from NTP and DNS to Apache, IIS, WebSphere,
>>>> Microsoft Azure, Splun

Re: [Puppet Users] Re: [ANN] Puppet Development Kit (pdk) 1.0

[David Schmitt]

Hi Charlie,

thanks for trying out the PDK!

On Mon, Aug 21, 2017 at 2:22 PM Charlie Derwent 
wrote:

> Can I use the PDK to validate my Roles and Profiles?
>

The short answer is: Yes, you can.


> Keep getting complaints that I'm not in a valid module (missng
> metadata.json)
>

Personally, I'd recommend putting all puppet code deployed to your puppet
installation into modules. This makes the code more mobile, and allows your
roles and profiles to integrate fully into your code workflows, without any
special casing.

With the PDK, you can start with `pdk new module` to create the necessary
base structures, and then copy over your manifests to try it out.

I'd love to hear how it worked out for you!


Cheers, David


>
> On Tuesday, 15 August 2017 21:51:52 UTC+1, Lindsey Smith wrote:
>>
>> After a few preview releases, we're happy to announce the availability
>> of the Puppet Development Kit
>> 
>> v1.0! The open-source PDK facilitates an easy, unified development
>> workflow for Puppet modules, and should appeal both to newcomers and
>> experienced developers.
>>
>>
>> Get the package for your platforms at the PDK download
>>  page, check out the
>> docs  and the code lives
>> at puppetlabs/pdk .
>>
>>
>> The Puppet Development Kit makes it easier than ever to develop and test
>> Puppet modules by providing a simple, unified interface to a set of helpful
>> tools for anyone who writes or consumes Puppet code. Leveraging the Puppet
>> Development Kit, it’s now possible to:
>>
>>-
>>
>>Quickly get started developing modules using best practices and new
>>tools that enable you to create, test and publish high-quality Puppet
>>modules with confidence
>>-
>>
>>Shift quality to the left by catching issues earlier and faster
>>before Puppet code is applied to live infrastructure
>>-
>>
>>Unit test modules from your Windows or Linux workstation to ensure
>>that Puppet code is creating and managing configuration resources as
>>intended
>>-
>>
>>Develop and share even more high-quality content for managing Windows
>>environments
>>
>>
>> Join us for a webinar
>> 
>> on Tuesday 22 Aug 2017 to see how you can leverage the new Puppet
>> Development Kit to save time and take advantage of the more than 5,000
>> modules of pre-written configuration code for managing an entire
>> infrastructure - everything from NTP and DNS to Apache, IIS, WebSphere,
>> Microsoft Azure, Splunk and Docker already available on the Puppet Forge.
>>
>> Lindsey Smith
>> Puppet
>>
> --
> 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/e974ef70-7572-45ed-9bc6-0bb01bc5e302%40googlegroups.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/CALF7fHbtbp28OTyZKszgs_mL3BCSK%3DTNj5_iV2qQePCKB-NEgw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: [ANN] Puppet Development Kit (pdk) 1.0

[David Schmitt]

A hot fix for this has been released at 
https://pm.puppetlabs.com/cgi-bin/pdk_download.cgi?dist=win=x64=1.0.1.0
 
; and will be available on the download page Really Soon Now.

On Wednesday, August 16, 2017 at 1:41:57 PM UTC+1, David Schmitt wrote:
>
>
>
> On 16 August 2017 at 13:06, Peter Faller <...> wrote:
>
>> Seems to be a hitch with the Windows install on Windows 8.1: I installed 
>> pdk-1.0.0.1-x64.msi; opened a new powershell window, and found that while 
>> pdk works, the PATH is wrong:
>>
>>
>> modules> $env:path
>> C:\Program Files\Puppet Labs\DevelopmentKit\\bin;%PATH%
>>
>> Any tips on how to correct this?
>>
>
> Thank you for reporting this. I'm tracking it now at 
> https://tickets.puppetlabs.com/browse/PDK-425
>
> As a short-term workaround, you can remove the $env:PATH assignment in 
> C:\Program 
> Files\WindowsPowerShell\Modules\PuppetDevelopmentKit\PuppetDevelopmentKit.psm1
>  
> , and re-open the PowerShell Windows.
>
>
>
> Cheers, David
>
>>
>> On Tuesday, 15 August 2017 22:51:52 UTC+2, Lindsey Smith wrote:
>>>
>>> 
>>>
>> -- 
>> 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/0aeb7ba1-48c7-4668-b5d9-d861d9d33fb2%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/puppet-users/0aeb7ba1-48c7-4668-b5d9-d861d9d33fb2%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>> 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/aff98cec-cc6a-4f90-af3d-4bc1ecbb7e91%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PDK 1.0.0.1 on Windows

[David Schmitt]

Oh, that was easier than expected: rspec-puppet does not provide a default
set of facts to your tests. Without any facts, puppet assumes your "host"
OS as test environment. Since your test is targeting a Linux machine, when
running the tests on Windows, this assumption is wrong.

To fix, use rspec-puppet-facts
<https://github.com/mcanevet/rspec-puppet-facts> in your tests to provide
prefab fact sets to your tests. The pdk ships a copy, but you'll have to
add it to your Gemfile (or use the Gemfile from the pdk-module-template
(e.g. copying over from a `pdk new module` run). PDK-428
<https://tickets.puppetlabs.com/browse/PDK-428> will make that easier, soon.

https://github.com/puppetlabs/pdk-module-template/blob/master/object_templates/class_spec.erb
is the default class test, and the rspec-puppet-facts README has more
explanations.


Cheers, David


On 17 August 2017 at 16:14, Peter Faller <pgfal...@gmail.com> wrote:

> Hi David
>
> Reduced example manifest and test attached ...
>
> On Linux:
>
> [root@tstpuppet01 rimcdm]# rspec spec/defines/test_reduced_spec.rb
> .
>
> Finished in 0.79952 seconds (files took 2.66 seconds to load)
> 1 example, 0 failures
>
> On Windows:
>
> PS rimcdm> pdk bundle exec -- rspec .\spec\defines\test_reduced_spec.rb
> F
>
> Failures:
>
>   1) rimcdm::test_reduced Create Test environment should compile into a
> catalogue without dependency cycles
>  Failure/Error: is_expected.to compile
>error during compilation: Parameter path failed on
> File[/var/lib/tftpboot]: File paths must be fully qualified, n
> ot '/var/lib/tftpboot' at line 3
>  # ./spec/defines/test_reduced_spec.rb:18:in `block (3 levels) in
> '
>
> Finished in 8.33 seconds (files took 2.02 seconds to load)
> 1 example, 1 failure
>
> Failed examples:
>
> rspec ./spec/defines/test_reduced_spec.rb:17 # rimcdm::test_reduced
> Create Test environment should compile into a catalo
> gue without dependency cycles
>
>
> On Thursday, 17 August 2017 15:32:49 UTC+2, David Schmitt wrote:
>>
>> ...
>>
> --
> 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/8fad49d4-5efd-44c2-b3c0-49627c21d329%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/8fad49d4-5efd-44c2-b3c0-49627c21d329%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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/CALF7fHaJWpGNVNy3%2BTFAKN32aKMT2Lkm726Ywh9fjP1WQwu9Jw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] PDK 1.0.0.1 on Windows

[David Schmitt]

On 17 August 2017 at 12:11, Peter Faller  wrote:

> Hi David
>
> Thanks for pointing out 'pdk bundle' - it does provide what I was looking
> for. It is however a bit noisy (but that's not a big deal):
>
> PS> pdk bundle exec -- rspec .\spec\classes\apg_base_spec.rb
> .
>
> Finished in 7.81 seconds (files took 1.85 seconds to load)
> 1 example, 0 failures
>
> C:/Program Files/Puppet Labs/DevelopmentKit/share/
> cache/ruby/2.1.0/gems/puppet-5.0.1-x64-mingw32/lib/puppet/util/windows
> /api_types.rb:6: warning: already initialized constant FFI::WIN32_FALSE
> C:/Program Files/Puppet Labs/DevelopmentKit/share/
> cache/ruby/2.1.0/gems/facter-2.5.0-x64-mingw32/lib/facter/util/windows
> /api_types.rb:5: warning: previous definition of WIN32_FALSE was here
> C:/Program Files/Puppet Labs/DevelopmentKit/share/
> cache/ruby/2.1.0/gems/puppet-5.0.1-x64-mingw32/lib/puppet/util/windows
> /api_types.rb:9: warning: already initialized constant FFI::ERROR_SUCCESS
> C:/Program Files/Puppet Labs/DevelopmentKit/share/
> cache/ruby/2.1.0/gems/facter-2.5.0-x64-mingw32/lib/facter/util/windows
> /api_types.rb:8: warning: previous definition of ERROR_SUCCESS was here
> C:/Program Files/Puppet Labs/DevelopmentKit/share/
> cache/ruby/2.1.0/gems/puppet-5.0.1-x64-mingw32/lib/puppet/util/windows
> /api_types.rb:21: warning: already initialized constant
> FFI::Pointer::NULL_HANDLE
> C:/Program Files/Puppet Labs/DevelopmentKit/share/
> cache/ruby/2.1.0/gems/facter-2.5.0-x64-mingw32/lib/facter/util/windows
> /api_types.rb:20: warning: previous definition of NULL_HANDLE was here
> !! spec/fixtures/modules/rimcdm already exists and is not a symlink
>

This is now tracked in https://tickets.puppetlabs.com/browse/FACT-1733, but
the underlying problem is https://tickets.puppetlabs.com/browse/FACT-1542 ,
which will require some time to resolve.


> The things that I use 'rake' and 'rspec' for are:
>
> > rspec spec/classes/some_class_spec.rb # to run a single unit test
> instead of all tests
>

Eventually , `pdk test unit`
will properly expose rspec's selector CLI.


> rake spec_prep # to update fixtures
> > rake spec_standalone # to run tests without updating fixtures
>
> I'm working on refactoring an over-sized module; that's why being able to
> do quick tests is important to me.
>



>
> I'm using the version of rspec-puppet bundled with the PDK - it appears to
> be version 2.6.7:
>
> PS> pdk bundle exec -- rspec --debug
> ...
> # C:/Program Files/Puppet Labs/DevelopmentKit/share/
> cache/ruby/2.1.0/gems/rspec-puppet-2.6.7/lib/rspec-puppet/monkey_patches.rb:273:in
> `require'
> ...
>


That's interesting. In the scientific sense. Is there a way you could share
the module, or a reduced example that repro's the issue?



Cheers, David

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

Re: [Puppet Users] PDK 1.0.0.1 on Windows

[David Schmitt]

On 17 August 2017 at 07:12, Peter Faller  wrote:

> While trying to use the PDK on Windows (instead of using a Linux VM for
> development), I've come across a few hitches:
>
> 1) 'rake' is not available as a command (it is accessible via
> $env:DEVKIT_BASEDIR/private/private\ruby\2.1.9\bin\rake though)
> 2) 'rspec' is not available as a command
> 3) errors related to file paths (seems to be an old Windows-related
> issue): Parameter path failed on File[/tftpboot]: File paths must be fully
> qualified, not '/tftpboot' at line 4
>
> Are there any workarounds for these?
>

The first two are easily addressed by running the commands through `pdk
bundle`. This ensures that you are using the PDK's ruby, and execution
environment. Generally the `pdk bundle` command should support running any
command that you have available through your Gemfile. for example `pdk
bundle exec "rake -T"`. See
https://github.com/puppetlabs/pdk#pdk-bundle-command (or the built-in help)
for details.

Would you mind sharing (even if privately) your use cases, where `pdk test
unit` is not providing enough functionality for you?

Number 3) has been fixed in rspec-puppet 2.6.0. If you are running an
earlier version, please update! If you are running rspec-puppet 2.6, or
newer, would you mind sending in a repro case directly on the rspec-puppet
github repo, so that we can have a poke at it?


> (BTW: Initially I had a standard Ruby 2.1 install in my PATH - that caused
> a lot of trouble too.)
>

This is surprising to me. We took great care that the pdk command is
independent of  existing ruby installations. Can you send me the commands
you were running, and how they failed on you, as well as how you installed
the PDK, and which versions of Windows, and PowerShell you were running?


Thank you for your feedback!


Cheers, David

>
> --
> 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/238147f7-36e6-4a8f-998e-4f2570e68c91%40googlegroups.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/CALF7fHa1MENDQS%3DmHYb9u757%3DCjGg%3DgyVvb6_PQvxvttAwavHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: [ANN] Puppet Development Kit (pdk) 1.0

[David Schmitt]

On 16 August 2017 at 13:06, Peter Faller  wrote:

> Seems to be a hitch with the Windows install on Windows 8.1: I installed
> pdk-1.0.0.1-x64.msi; opened a new powershell window, and found that while
> pdk works, the PATH is wrong:
>
>
> modules> $env:path
> C:\Program Files\Puppet Labs\DevelopmentKit\\bin;%PATH%
>
> Any tips on how to correct this?
>

Thank you for reporting this. I'm tracking it now at
https://tickets.puppetlabs.com/browse/PDK-425

As a short-term workaround, you can remove the $env:PATH assignment in
C:\Program
Files\WindowsPowerShell\Modules\PuppetDevelopmentKit\PuppetDevelopmentKit.psm1
, and re-open the PowerShell Windows.



Cheers, David

>
> On Tuesday, 15 August 2017 22:51:52 UTC+2, Lindsey Smith wrote:
>>
>> 
>>
> --
> 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/0aeb7ba1-48c7-4668-b5d9-d861d9d33fb2%40googlegroups.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/CALF7fHarcaMt%2B-HxVdaaeYbQe4cdhSxBtgCMnyMCvtpTsUkYTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Puppet newbie question about facts and config files

[David Schmitt]

Hi,

On 2 August 2017 at 16:15, RG  wrote:

> I am trying to write my first puppet module.
>
> I need to be able to pull a value from a custom fact and write a value in
> a config file based on a value in the fact.
>
> Can I do and "if-then" statement  like in bash?
>

Yes! See https://docs.puppet.com/puppet/5.0/lang_conditional.html for the
details. The first example on that page even uses facts to decide.


Cheers, David


>
> Thanks for any guidance.
>
>
> --
> 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/45e2fa45-1114-487d-afae-d5b17097045a%40googlegroups.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/CALF7fHadYzzk%2B2cWvrqExDtVkp%2BN2FO6iPwN896uiVHPrFdzTA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: [Puppet-dev] Re: Draft for new type and provider API

[David Schmitt]

[aologies, this got lost in my Drafts folder.]

On 28 February 2017 at 19:35, Erik Dalén 
wrote:

> Overall I think this looks pretty good, but I have some questions and
> comments.
>
> For implementations that can't enumerate all existing resources (at least
> not in any fast way), like for example File, should they fine a get method
> that returns an empty hash, nil or just not define a get method? nil or not
> defining would allow special handling of them, so that would probably be
> preferable.
>
> But shouldn't it really have a way to fetch the state of a single resource
> in for those implementations? How would this otherwise handle something
> like "puppet resource file /path/to/file", traverse the entire file system
> and stat every file?
>

Yup it should. I've added a short discussion of the problem to the "Known
limitations" section. I could add verbiage around the get() method
returning nil (as opposed to []) to signal that there might be instances
available, but it's not possible to enumerate them.


> It seems it would also be handy with some helper method that compared
> current_state & target_state to filter out the changes that actually need
> to happen. I would imagine that sort of code would otherwise be duplicated
> in many implementations.
>

True. Porting the existing types and providers from our supported modules
is high on my list to validate the design, and will expose the patterns.
That'll make it much easier to build a library of helpers.


> logger.attribute_changed could really have a default value for message if
> the implementation provides attribute, old_value & new_value they shouldn't
> all need to supply "Changed #{attribute} from #{old_value} to #{new_value}
> ".
>

That's already specified.


> Will the attribute type fields be able to use type definitions shipped in
> the same module or present on in environment?
>

Currently anywhere "puppet 4 data types" are mentioned, only the built-in
types are usable. This is because the type information is required on the
agent, but puppet doesn't make it available yet. This work is tracked in
[PUP-7197](https://tickets.puppetlabs.com/browse/PUP-7197), but even once
that is implemented, modules will have to wait until the functionality is
widely available, before being able to rely on that.


> Will they be able to inspect the catalog or communicate between
> implementations, like in the concat & concat_fragment case?
>

 My preferred method to solve that would be a new top-level plugin, that
can inspect and change the catalog after it has been built. That plugin
could then collect all the fragments, and build a file resource from them,
before the catalog is even passed to the agent.


> Will they be able to generate resources? That could probably be done with
> something similar to the logger methods, but there is nothing like that in
> the proposal. I assume they won't have a generate method.
>

Adding more discrete functionality and life-cycle methods later seems like
an easy extension, that will not require a major API revision. Also
possibly another use-case for a catalog transform plugin.


> Will there be some requirement that these implementations are thread safe
> so puppet can start managing multiple resources in parallel? Or will they
> run in some subprocess even?
>
>
Theoretically, those implementations could be run in a separate process.
Looking at things like Lutterkort's libral, this might happen quicker than
I think today. As a firm believer of small incremental steps, I only want
to speculate on those things as far as I need to avoid blocking a future
change. Therefore I'm focusing this new API mostly on being small, self
contained, and decoupled.


Thanks for your time and work in reviewing this!

Regards, David

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

[Puppet Users] Re: [Puppet-dev] Re: Draft for new type and provider API

[David Schmitt]

On 27 February 2017 at 18:57, Shawn Ferry <shawn.fe...@oracle.com> wrote:

>
> On Feb 27, 2017, at 9:59 AM, David Schmitt <david.schm...@puppet.com>
> wrote:
>
> Commands
>
> To use CLI commands in a safe and comfortable manner, the implementation
> can use the commands method to access shell commands. You can either use
> a full path, or a bare command name. In the latter case puppet will use the
> system PATH setting to search for the command. If the commands are not
> available, an error will be raised and the resources will fail in this run.
> The commands are aware of whether noop is in effect or not, and will skip
> the actual execution if necessary.
>
> Puppet::ResourceImplementation.register('apt_key') do
>   commands apt_key: '/usr/bin/apt-key'
>   commands gpg: 'gpg'
>
> This will create methods called apt_get, and gpg, which will take CLI
> arguments without any escaping, and run them in a safe environment (clean
> working directory, clean environment). For example to call apt-key to
> delete a specific key by id:
>
> If the goal here is safe execution shouldn’t it escape at least shell
> special characters? My concern is based on some of the providers I work on
> which take free form strings as arguments and any type that doesn’t fully
> validate or munge inputs.
>
> There is a risk that any provider* today can suffer from shell command
> injection. It seems that using shelljoin on the argument array would be
> useful or shellesacpe on each element. However, for a simplified API it
> seems that it could be done more centrally here instead of pushing it to
> each implementation to make sure it is done if needed.
>
> * That can’t exclude shell characters and doesn’t munge input to escape
> them.
>

The trick is to not use system() which calls through the shell, but the
array variant of spawn() or popen() that doesn't go through a shell. Not
only will that be much better performing due to fewer binaries being
loaded, but also eliminates all shell parsing from the call chain. Having
this wrapped up in the API as the primary mechanism to call CLI commands is
intended to help people with that, instead of having them have to find the
right ruby incantation themselves.



Cheers, David

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

[Puppet Users] Re: [Puppet-dev] Re: Draft for new type and provider API

[David Schmitt]

Hi folks,

I've written down the design in README format now. This should make for a
easier to ingest from a module developer's perspective. Meanwhile I've also
had a shot at a hardcoded implementation of this, and it is technically
possible to implement this too.

---
Resource API

A *resource* is the basic thing that is managed by puppet. Each resource
has a set of attributes describing its current state. Some of the
attributes can be changed throughout the life-time of the resource, some
attributes only report back, but cannot be changed (see read_only)others
can only be set once during initial creation (see init_only). To gather
information about those resources, and to enact changes in the real world,
puppet requires a piece of code to *implement* this interaction. The
implementation can have parameters that influence its mode of operation
(see operational_parameters). To describe all these parts to the
infrastructure, and the consumers, the resource *Definition* (f.k.a.
'type') contains definitions for all of them. The *Implementation* (f.k.a.
'provider') contains code to *get* and *set* the system state.
Resource
Definition

Puppet::ResourceDefinition.register(
name: 'apt_key',
docs: <<-EOS,  This type provides Puppet with the capabilities
to manage GPG keys needed  by apt to perform package validation.
Apt has it's own GPG keyring that can  be manipulated through the
`apt-key` command.  apt_key {
'6F6B15509CF8E59E6E469F327F438280EF8D349F':source =>
'http://apt.puppetlabs.com/pubkey.gpg'  }  **Autorequires**:
   If Puppet is given the location of a key file which looks like an
absolute  path this type will autorequire that file.EOS
attributes:   {
ensure:  {
type: 'Enum[present, absent]',
docs: 'Whether this apt key should be present or absent on
the target system.'
},
id:  {
type:'Variant[Pattern[/\A(0x)?[0-9a-fA-F]{8}\Z/],
Pattern[/\A(0x)?[0-9a-fA-F]{16}\Z/],
Pattern[/\A(0x)?[0-9a-fA-F]{40}\Z/]]',
docs:'The ID of the key you want to manage.',
namevar: true,
},
# ...
created: {
type:  'String',
docs:  'Date the key was created, in ISO format.',
read_only: true,
},
},
autorequires: {
file:'$source', # will evaluate to the value of the
`source` attribute
package: 'apt',
},
)

The Puppet::ResourceDefinition.register(options) function takes a Hash with
the following top-level keys:

   - name: the name of the resource. For autoloading to work, the whole
   function call needs to go into lib/puppet/type/.rb.
   - docs: a doc string that describes the overall working of the type,
   gives examples, and explains pre-requisites as well as known issues.
   - attributes: an hash mapping attribute names to their details. Each
   attribute is described by a hash containing the puppet 4 data type, a
   docs string, and whether the attribute is the namevar, read_only, and/or
   init_only.
   - operational_parameters: a hash mapping parameter names to puppet data
   types and docs strings.
   - autorequires, autobefore, autosubscribe, and autonotify: a Hash
   mapping resource types to titles. Currently the titles must either be
   constants, or, if the value starts with a dollar sign, a reference to the
   value of an attribute.

Resource
Implementation

At runtime the current and intended system states for a single resource
instance are always represented as ruby Hashes of the resource's
attributes, and applicable operational parameters.

The two fundamental operations to manage resources are reading and writing
system state. These operations are implemented in the ResourceImplementation
as get and set:

Puppet::ResourceImplementation.register('apt_key') do
  def get
[
  'title': {
name: 'title',
# ...
  },
]
  end

  def set(current_state, target_state, noop: false)
target_state.each do |title, resource|
  # ...
end
  endend

The get method returns a Hash of all resources currently available, keyed
by their title. If the get method raises an exception, the implementation
is marked as unavailable during the current run, and all resources of its
type will fail. The error message will be reported to the user.

The set method updates resources to the state defined in target_state. For
convenience, current_state contains the last available system state from a
prior get call. When noop is set to true, the implementation must not
change the system state, but only report what it would change.
Runtime
Environment

The primary runtime 

[Puppet Users] Re: [Puppet-dev] Re: Draft for new type and provider API

[David Schmitt]

On 7 February 2017 at 17:13, jcbollinger <john.bollin...@stjude.org> wrote:

>
>
> On Tuesday, January 31, 2017 at 10:04:27 AM UTC-6, David Schmitt wrote:
>>
>>
>> The type and provider API has been the bane of my existence since I
>> [started writing native resources](https://github.com/
>> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
>>
>
>
> Honestly, I've never thought the type / provider system was too bad.
> Certainly it works pretty well for simple things.  Now, I'm more of a Dev
> who does Ops than an Op who Devs, but from my perspective, the biggest
> problem with Puppet's types & providers has always been inadequate
> documentation.  The docs in this area are a bit better now than when I
> started with Puppet around eight years ago, but they have always missed
> presenting many relevant details about how the host Puppet instance,
> resource instances, and their associated provider instances interact.
>

What I read here is that the current state is complex enough that a couple
of books and a crack team of tech writers couldn't explain it well.


>   This new effort doesn't seem to be targeting any of that.
>

Looping back to the "lack of documentation", I see this lack grounded
partially in the huge surface area that needs to be covered, since the
existing T API is deeply entangled into the catalog compilation, and the
agent transactions.

This new API has two entry points that take a small number of easily
explained arguments, making a full documentation realistic. From this (and
other's) reaction I do understand now, that I should have started with a
more README-driven approach, to highlight the difference more. Let's try
this again:

The *SimpleResource* (working title) consists of three distinct, but
cooperating parts. The *Definition* describes the shape of a resource, its
attributes, their types, which is the namevar, and the doc strings. The *get
method* returns a list of hashes, each matching the shape of the resource
as defined in the Definition. For example, a list of apt_key resources
(here rendered in JSON) would look like this:

[
  {
"name": "BBCB188AD7B3228BCF05BD554C0BE21B5FF054BD",
"ensure": "present",
"fingerprint": "BBCB188AD7B3228BCF05BD554C0BE21B5FF054BD",
"long": "4C0BE21B5FF054BD",
"short": "5FF054BD",
"size": "2048",
"type": "rsa",
"created": "2013-06-07 23:55:31 +0100",
"expiry": null,
"expired": false
  },
  {
"name": "B71ACDE6B52658D12C3106F44AB781597254279C",
"ensure": "present",
"fingerprint": "B71ACDE6B52658D12C3106F44AB781597254279C",
"long": "4AB781597254279C",
"short": "7254279C",
"size": "1024",
"type": "dsa",
"created": "2007-03-08 20:17:10 +",
"expiry": null,
"expired": false
  },
  ...

The *set method* takes a list of target goals in the same format and is
responsible for enforcing those goals on the target system. When calling
the set method, the caller may provide the current state (as received from
a recent get call) to allow the set method to shortcut reading the existing
state again. The basic pattern for the set method looks like this:

def set(current_state, target_state, noop = false)
  existing_keys = Hash[current_state.collect { |k| [k[:name], k] }]
  target_state.each do |resource|
# additional validation for this resource goes here

current = existing_keys[resource[:name]]
if current && resource[:ensure].to_s == 'absent'
  # delete the resource
elsif current && resource[:ensure].to_s == 'present'
  # update the resource
elsif !current && resource[:ensure].to_s == 'present'
  # create the resource
end
  end
end





> Now, finally, we'll do something about it. I'm currently working on
>> designing a nicer API for types and providers. My primary goals are to
>> provide a smooth and simple ruby developer experience for both scripters
>> and coders. Secondary goals were to eliminate server side code, and make
>> puppet 4 data types available. Currently this is completely aspirational
>> (i.e. no real code has been written), but early private feedback was
>> encouraging.
>>
>>
>
> I'm confused and dubious: how is it that the guiding goals for this effort
> are all about form rather than function?  Surely, if you intend for the
> result to serve any particular function(s) then you need to be guided at
> least in part by which functions those are.  Perhaps for 

[Puppet Users] Re: [Puppet-dev] Re: Draft for new type and provider API

[David Schmitt]

On 7 February 2017 at 10:44, Thomas Hallgren <thomas.hallg...@puppet.com>
wrote:

> Like Martin Afke above, I'm very interested in what could be done using
> the Puppet Language alone. What use cases can be covered entirely that way?
>

As David L pointed out, many of these things can be done today in defines,
or classes, already.

What is not feasible to ever do with PL?
>

Talk to external APIs.


> Would an API that made it possible to write types and providers PL and
> hand over tiny tasks to another language (Ruby, C, Go, etc.) be of
> interest? I.e. a clean cut boundary between the things possible
> (appropriate) to implement with PL and the things that aren't?
>

I do not understand how extending the puppet dsl on the server helps with
resource management on the agent.


> Perhaps this is a first step in that direction?
>

In one possible reading, types are already are a extension point of the
DSL, and this proposal makes that less painful, and easier to reason about.

Cheers, David

PS: If anyone is at ConfigurationManagementCamp in Gent these days, hit me
up to talk about this!



>
> - thomas
>
>
> On Tue, Feb 7, 2017 at 11:31 AM, David Schmitt <david.schm...@puppet.com>
> wrote:
>
>> Hi Corey,
>>
>> thanks for looking into this. I've been travelling so accept my apologies
>> for a late answer.
>>
>>
>> On 5 February 2017 at 20:52, Corey Osman <co...@logicminds.biz> wrote:
>>
>>> One improvement I would like to see with the provider API is around
>>> getting the current state.  I see many beginners including myself trying to
>>> add way more complexity than required in the exists? method.
>>>
>>> One would think that you in order to figure out if the resource exists
>>> that you should just query the system and DIY.  And I'll pick on my own
>>> code as an example: https://github.com/logicminds/
>>> bmclib/blob/0.1.0/lib/puppet/provider/bmc/ipmitool.rb#L34
>>>
>>> However, this is not the case.  This is the exact opposite of what you
>>> need to do. Instead you need to query the API which is hard to understand
>>> and not obvious at first because instinct tells you to get the state
>>> yourself.
>>>
>>> https://github.com/logicminds/bmclib/blob/master/lib/puppet/
>>> provider/bmc/ipmitool.rb#L60
>>>
>>> Another improvement which I hope would get addressed is self.prefetch.
>>> While self.instances is pretty simple to understand the prefetch method
>>> could probably use a better name and an easier way to implement. It was not
>>> obvious at first how to implement. So many people don't implement these two
>>> methods when they should making their provider more useful.
>>>
>>
>> Exactly what this should address. The implementation of `get` is very
>> straightforward (and, currently, required).
>>
>> The type checking looks pretty amazing and simple to understand and
>>> implement in the type code.
>>>
>>
>> Thanks! I hope that a provider author would never have to "implement"
>> this. The SimpleResource will create a proper Type class underneath with
>> all the validation and munging generated.
>>
>>
>>
>>>
>>> Additionally, As Trevor mentioned I also have some projects
>>> (puppet-debugger and puppet-retrospec) that utilize the current Puppet API
>>> to introspec resources and query the catalog please so make sure this new
>>> code doesn't break my projects.   I'll be happy to test out any new API for
>>> third party compatibility.
>>>
>>
>> Thanks for the offer! For the time being, the implementation will sit
>> completely on top of the unmodified puppet code to work on all puppet 4
>> versions out there. I also don't expect existing types to switch
>> immediately, but I do hope that the new API makes implementations so much
>> easier that people will switch quickly.
>>
>> Then it will be a matter of filling in the gaps for the special cases.
>>
>> Cheers, David S
>>
>>
>>
>>>
>>>
>>> Corey  (NWOps)
>>>
>>>
>>>
>>> On Tuesday, January 31, 2017 at 8:04:19 AM UTC-8, David Schmitt wrote:
>>>>
>>>> Hi *,
>>>>
>>>> The type and provider API has been the bane of my existence since I
>>>> [started writing native resources](https://github.com/
>>>> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
>>>> Now, finally, we'll do something about it. I'm currently working on
>

[Puppet Users] Re: [Puppet-dev] Re: Draft for new type and provider API

[David Schmitt]

Hi Corey,

thanks for looking into this. I've been travelling so accept my apologies
for a late answer.


On 5 February 2017 at 20:52, Corey Osman <co...@logicminds.biz> wrote:

> One improvement I would like to see with the provider API is around
> getting the current state.  I see many beginners including myself trying to
> add way more complexity than required in the exists? method.
>
> One would think that you in order to figure out if the resource exists
> that you should just query the system and DIY.  And I'll pick on my own
> code as an example: https://github.com/logicminds/
> bmclib/blob/0.1.0/lib/puppet/provider/bmc/ipmitool.rb#L34
>
> However, this is not the case.  This is the exact opposite of what you
> need to do. Instead you need to query the API which is hard to understand
> and not obvious at first because instinct tells you to get the state
> yourself.
>
> https://github.com/logicminds/bmclib/blob/master/lib/puppet/
> provider/bmc/ipmitool.rb#L60
>
> Another improvement which I hope would get addressed is self.prefetch.
> While self.instances is pretty simple to understand the prefetch method
> could probably use a better name and an easier way to implement. It was not
> obvious at first how to implement. So many people don't implement these two
> methods when they should making their provider more useful.
>

Exactly what this should address. The implementation of `get` is very
straightforward (and, currently, required).

The type checking looks pretty amazing and simple to understand and
> implement in the type code.
>

Thanks! I hope that a provider author would never have to "implement" this.
The SimpleResource will create a proper Type class underneath with all the
validation and munging generated.



>
> Additionally, As Trevor mentioned I also have some projects
> (puppet-debugger and puppet-retrospec) that utilize the current Puppet API
> to introspec resources and query the catalog please so make sure this new
> code doesn't break my projects.   I'll be happy to test out any new API for
> third party compatibility.
>

Thanks for the offer! For the time being, the implementation will sit
completely on top of the unmodified puppet code to work on all puppet 4
versions out there. I also don't expect existing types to switch
immediately, but I do hope that the new API makes implementations so much
easier that people will switch quickly.

Then it will be a matter of filling in the gaps for the special cases.

Cheers, David S



>
>
> Corey  (NWOps)
>
>
>
> On Tuesday, January 31, 2017 at 8:04:19 AM UTC-8, David Schmitt wrote:
>>
>> Hi *,
>>
>> The type and provider API has been the bane of my existence since I
>> [started writing native resources](https://github.com/
>> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
>> Now, finally, we'll do something about it. I'm currently working on
>> designing a nicer API for types and providers. My primary goals are to
>> provide a smooth and simple ruby developer experience for both scripters
>> and coders. Secondary goals were to eliminate server side code, and make
>> puppet 4 data types available. Currently this is completely aspirational
>> (i.e. no real code has been written), but early private feedback was
>> encouraging.
>>
>> To showcase my vision, this [gist](https://gist.github.com
>> /DavidS/430330ae43ba4b51fe34bd27ddbe4bc7) has the [apt_key type](
>> https://github.com/puppetlabs/puppetlabs-apt/blob/
>> master/lib/puppet/type/apt_key.rb) and [provider](https://github.com/
>> puppetlabs/puppetlabs-apt/blob/master/lib/puppet/provider/
>> apt_key/apt_key.rb) ported over to my proposal. The second example there
>> is a more long-term teaser on what would become possible with such an API.
>>
>> The new API, like the existing, has two parts: the implementation that
>> interacts with the actual resources, a.k.a. the provider, and information
>> about what the implementation is all about. Due to the different usage
>> patterns of the two parts, they need to be passed to puppet in two
>> different calls:
>>
>> The `Puppet::SimpleResource.implement()` call receives the
>> `current_state = get()` and `set(current_state, target_state, noop)`
>> methods. `get` returns a list of discovered resources, while `set` takes
>> the target state and enforces those goals on the subject. There is only a
>> single (ruby) object throughout an agent run, that can easily do caching
>> and what ever else is required for a good functioning of the provider. The
>> state descriptions passed around are simple lists of key/value hashes
>> describing resources. This will allow the implementatio

[Puppet Users] Re: [Puppet-dev] Draft for new type and provider API

[David Schmitt]

On 3 February 2017 at 11:12, Martin Alfke  wrote:

> Hi David,
>
> many thanks for sharing your ideas.
>
> As you already know: personally I don’t say that types and providers are
> way to difficult.
> It is more a matter on how to explain them.
> I will dig through your document during weekend. We can have a chat on
> Monday in Ghent.
>
> But besides this:
> is your idea somehow related to the libral project?
> https://github.com/puppetlabs/libral
>
>
>

>
>   * It maps 1:1 to the capabilities of PCore, and is similar to the libral
> interface description (see [libral#1](https://github.com/
> puppetlabs/libral/pull/2)). This ensures future interoperability between
> the different parts of the ecosystem.
>
>
libral is a neighbouring project, with its own set of distinct design
goals. Staying bidirectionally compatible is a necessary requisite for this
proposal here. (Which can be handled on both sides, depending on a wide
variety of things).

Cheers, David

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

[Puppet Users] Re: [Puppet-dev] Draft for new type and provider API

[David Schmitt]

On 2 February 2017 at 02:50, Trevor Vaughan <tvaug...@onyxpoint.com> wrote:

> Hi David,
>
> Most of this looks fine (I still need to digest some of it) but I don't
> know that I'm a huge fan of no munge or validate functionality. This seems
> to fly in the face of a 'fail fast' mentality.
>

With puppet 4 data types much of the trivial stuff munge and validate do
can be handled much easier and consistently than before. Many other checks
will never be possible on the server, because they depend on values only
available on the agent (credential validity, max tablename length dependent
on mysql flavour), or would be error prone duplication of things the target
API does check for us (validity of file mode bit combinations, validity of
AMI references when talking to EC2 instances, etc). There is a bit of stuff
in-between those two (e.g. content specified on a file), which we'd
trade-off for a much simpler server side. Failing on the agent, also means
that independent parts of the catalog can move forward, instead of failing
the whole compilation.


> Also, if everything happens on the client, some of the catalog munging
> that I do on the fly isn't going to work any longer.
>

Those resources will not look anything different than existing types (which
will stay as they are for a considerable while). Since I don't know what
catalog munging you're doing I'm having a hard time following here.

I *do* like the idea of types being pure data but will this bloat the
> catalog even further?
>

The resources in the catalog won't look any different than today. In fact,
the first version will most likely just call Puppet::Type.newtype() under
the hood somewhere.


> I still think that moving toward a heap/stack model would serve the Puppet
> clients best and get past the resource count limitations.
>

Do you have those ideas written up somewhere?


> Fundamentally, I want my clients to do as little work as possible since
> they're meant to be running business processes.
>

Same.


>
> I'll definitely be keeping an eye on this conversation though.
>
> Thanks,
>

Thanks for your time and work you're putting in here.


David


>
> Trevor
>
> On Tue, Jan 31, 2017 at 11:04 AM, David Schmitt <david.schm...@puppet.com>
> wrote:
>
>> Hi *,
>>
>> The type and provider API has been the bane of my existence since I
>> [started writing native resources](https://github.com/
>> DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
>> Now, finally, we'll do something about it. I'm currently working on
>> designing a nicer API for types and providers. My primary goals are to
>> provide a smooth and simple ruby developer experience for both scripters
>> and coders. Secondary goals were to eliminate server side code, and make
>> puppet 4 data types available. Currently this is completely aspirational
>> (i.e. no real code has been written), but early private feedback was
>> encouraging.
>>
>> To showcase my vision, this [gist](https://gist.github.com
>> /DavidS/430330ae43ba4b51fe34bd27ddbe4bc7) has the [apt_key type](
>> https://github.com/puppetlabs/puppetlabs-apt/blob/
>> master/lib/puppet/type/apt_key.rb) and [provider](https://github.com/
>> puppetlabs/puppetlabs-apt/blob/master/lib/puppet/provider/
>> apt_key/apt_key.rb) ported over to my proposal. The second example there
>> is a more long-term teaser on what would become possible with such an API.
>>
>> The new API, like the existing, has two parts: the implementation that
>> interacts with the actual resources, a.k.a. the provider, and information
>> about what the implementation is all about. Due to the different usage
>> patterns of the two parts, they need to be passed to puppet in two
>> different calls:
>>
>> The `Puppet::SimpleResource.implement()` call receives the
>> `current_state = get()` and `set(current_state, target_state, noop)`
>> methods. `get` returns a list of discovered resources, while `set` takes
>> the target state and enforces those goals on the subject. There is only a
>> single (ruby) object throughout an agent run, that can easily do caching
>> and what ever else is required for a good functioning of the provider. The
>> state descriptions passed around are simple lists of key/value hashes
>> describing resources. This will allow the implementation wide latitude in
>> how to organise itself for simplicity and efficiency.
>>
>> The `Puppet::SimpleResource.define()` call provides a data-only
>> description of the Type. This is all that is needed on the server side to
>> compile a manifest. Thanks to puppet 4 data type checking, this will
>> already be much more strict (with less effort) than possibl

[Puppet Users] Draft for new type and provider API

[David Schmitt]

Hi *,

The type and provider API has been the bane of my existence since I
[started writing native resources](
https://github.com/DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2).
Now, finally, we'll do something about it. I'm currently working on
designing a nicer API for types and providers. My primary goals are to
provide a smooth and simple ruby developer experience for both scripters
and coders. Secondary goals were to eliminate server side code, and make
puppet 4 data types available. Currently this is completely aspirational
(i.e. no real code has been written), but early private feedback was
encouraging.

To showcase my vision, this [gist](
https://gist.github.com/DavidS/430330ae43ba4b51fe34bd27ddbe4bc7) has the
[apt_key type](
https://github.com/puppetlabs/puppetlabs-apt/blob/master/lib/puppet/type/apt_key.rb)
and [provider](
https://github.com/puppetlabs/puppetlabs-apt/blob/master/lib/puppet/provider/apt_key/apt_key.rb)
ported over to my proposal. The second example there is a more long-term
teaser on what would become possible with such an API.

The new API, like the existing, has two parts: the implementation that
interacts with the actual resources, a.k.a. the provider, and information
about what the implementation is all about. Due to the different usage
patterns of the two parts, they need to be passed to puppet in two
different calls:

The `Puppet::SimpleResource.implement()` call receives the `current_state =
get()` and `set(current_state, target_state, noop)` methods. `get` returns
a list of discovered resources, while `set` takes the target state and
enforces those goals on the subject. There is only a single (ruby) object
throughout an agent run, that can easily do caching and what ever else is
required for a good functioning of the provider. The state descriptions
passed around are simple lists of key/value hashes describing resources.
This will allow the implementation wide latitude in how to organise itself
for simplicity and efficiency.

The `Puppet::SimpleResource.define()` call provides a data-only description
of the Type. This is all that is needed on the server side to compile a
manifest. Thanks to puppet 4 data type checking, this will already be much
more strict (with less effort) than possible with the current APIs, while
providing more automatically readable documentation about the meaning of
the attributes.


Details in no particular order:

* All of this should fit on any unmodified puppet4 installation. It is
completely additive and optional. Currently.

* The Type definition
  * It is data-only.
  * Refers to puppet data types.
  * No code runs on the server.
  * This information can be re-used in all tooling around
displaying/working with types (e.g. puppet-strings, console, ENC, etc.).
  * autorelations are restricted to unmodified attribute values and
constant values.
  * No more `validate` or `munge`! For the edge cases not covered by data
types, runtime checking can happen in the implementation on the agent.
There it can use local system state (e.g. different mysql versions have
different max table length constraints), and it will only fail the part of
the resource tree, that is dependent on this error. There is already ample
precedent for runtime validation, as most remote resources do not try to
replicate the validation their target is already doing anyways.
  * It maps 1:1 to the capabilities of PCore, and is similar to the libral
interface description (see [libral#1](
https://github.com/puppetlabs/libral/pull/2)). This ensures future
interoperability between the different parts of the ecosystem.
  * Related types can share common attributes by sharing/merging the
attribute hashes.
  * `defaults`, `read_only`, and similar data about attributes in the
definition are mostly aesthetic at the current point in time, but will make
for better documentation, and allow more intelligence built on top of this
later.

* The implementation are two simple functions `current_state = get()`, and
`set(current_state, target_state, noop)`.
  * `get` on its own is already useful for many things, like puppet
resource.
  * `set` receives the current state from `get`. While this is necessary
for proper operation, there is a certain race condition there, if the
system state changes between the calls. This is no different than what
current implementations face, and they are well-equipped to deal with this.
  * `set` is called with a list of resources, and can do batching if it is
beneficial. This is not yet supported by the agent.
  * the `current_state` and `target_state` values are lists of simple data
structures built up of primitives like strings, numbers, hashes and arrays.
They match the schema defined in the type.
  * Calling `r.set(r.get, r.get)` would ensure the current state. This
should run without any changes, proving the idempotency of the
implementation.
  * The ruby instance hosting the `get` and `set` functions is only alive
for the duration of an 

[Puppet Users] Re: Why i cant change my custom types?

[David Schmitt]

Another thing you might want to try is "puppet generate type", a 
experimental feature of puppet 4.6 onwards: 
https://docs.puppet.com/puppet/4.8/reference/environment_isolation.html

Regards, David

On Tuesday, November 8, 2016 at 12:31:07 PM UTC, Akai wrote:
>
> Hello David,
>
> thank you for this explanation. Everything could be so simple. Now i 
> understand :-) ...
>
> Best Regards
>

-- 
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/a6c9b573-bfea-459d-b1b4-5e6e29d4bb2f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Why i cant change my custom types?

[David Schmitt]

On Tuesday, November 8, 2016 at 10:58:58 AM UTC, Akai wrote:

> It cant be the right way, to always reset everythng on a older snapshot 
> or? Why the puppetmaster "rembers" the custom_type definition and does not 
> accept changes? How i handle this?
>

Since custom types are native ruby code, the puppetserver is restricted in 
what it can do with it. Once the code is loaded into the process, it 
remains there. To get rid of it without trashing your whole environment, 
restart the puppetserver service. The newly started puppetserver will read 
the custom type afresh and have the new code then available for your 
testing.


Cheers, David

-- 
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/66f68483-1ecb-451c-b200-efe246ddd7e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Agent installation and status enforcement

[David Schmitt]

Hi Frank,

there are a few ways in which agents can become non-functional (full disk, 
code error, OOM killer, mismatched incentives in the organization, etc), 
none of which can be fixed by the (now dysfunctional) agent. The common 
remediation is monitoring agent reports and investigating nodes that have 
not reported in within their expected timeframe. Without the capability to 
address the underlying structural issues, it will remain a game 
whack-a-mole. 

Good luck, David

On Monday, November 7, 2016 at 2:44:23 PM UTC, Francesco Raimondi wrote:
>
> Greetings everyone,
>
> Real n00b to puppet here. I was wondering if there's a way to enforce the 
> presence and the correct execution status of puppet agents. I've correctly 
> setup a foreman server and added several nodes to it, but I've no control 
> on someone who may uninstall the puppet agent on the node. I know this 
> question expose several other issues (non-trusted users should not have 
> administrative privileges on machines), but these are things beyond my 
> control. Is there any way I can achieve this with puppet? 
>
> Any help would be greatly appreciated,
> Frank
>

-- 
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/abf968ab-ad8e-41e3-a9a5-4aaede3b2f62%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Help unit testing profile with dependency on ntp 5.0 module (module data)

[David Schmitt]

On 2 November 2016 at 18:10, Gavin Williams <fatmc...@gmail.com> wrote:

> Stephen
>
> If you're already using R10k or Librarian-Puppet, as indicated by the
> Puppetfile, then it should be possible to simplify that...
>
> For example, my .fixtures.yml looks like:
> --
> fixtures:
>   symlinks:
> [module_name]: "#{source_dir}"
>
>
>
With the latest puppetlabs_spec_helper versions you can even leave that
out. See the first example at
https://github.com/puppetlabs/puppetlabs_spec_helper#fixtures-examples


> Puppetfile:
> #!/usr/bin/env ruby
>
> forge 'http://forge.puppetlabs.com'
>
> metadata
>
> # mod 'puppet-archive',
> #   :git => 'https://github.com/fatmcgav/puppet-archive.git',
> #   :ref => 'support-1.8.7-puppet4'
>
>
> The Puppetfile above pulls a list of required modules from your
> metadata.json file, and Librarian-Puppet takes care of installing and
> resolving deps...
>
> Rakefile addition:
> # use librarian-puppet to manage fixtures instead of .fixtures.yml
> # offers more possibilities like explicit version management, forge
> downloads,...
> task :librarian_spec_prep do
>   sh "librarian-puppet install --path=spec/fixtures/modules/"
> end
> task :spec_prep => :librarian_spec_prep
> task :librarian_clean do
>   sh "librarian-puppet clean"
> end
>
>
Nifty! I guess the same can be used in the acceptance tests if necessary.
the one gap (that is also not addressed by any other current tooling) is if
you have different testing requirements for different environments (e.g.
validate production, vs. smoke-testing upstream versions pre-upgrade.


Thanks a lot for sharing!

d.

>
>
> HTH
> Gav
>
>
> On Wednesday, 2 November 2016 16:41:03 UTC, Stephen Nesbitt wrote:
>>
>> Garrett - Thanks for the heads up!
>>
>> David - thanks for the comment!
>>
>> I will note that I am now maintaining dependency information in 3
>> locations - Puppetfile, metdata.json and .fixtures, Guess what is going to
>> happen at some point ;-)
>>
>> Maybe I'm not aware of something, but there really should be a single
>> canonical source of dependency requirements.
>>
>> -steve
>>
>> On Wednesday, November 2, 2016 at 6:55:05 AM UTC-7, David Schmitt wrote:
>>>
>>>
>>>
>>> On Tuesday, November 1, 2016 at 7:25:01 PM UTC, Garrett Honeycutt wrote:
>>>
>>>> I noticed that your .fixtures.yml do not include versions. This means
>>>> that they will always test against the latest version. You probably
>>>> want
>>>> to change this to use the version you actually use.
>>>>
>>>
>>> That really depends on the amount of time and the cadence people are
>>> willing to invest in staying up-to-date. Shops with strict version
>>> requirements and a waterfall-y workflow really should do that. Others with
>>> a more fluid/agile/pipeline-oriented workflow are much better suited to
>>> address upcomping changes when they happen, instead of batching it up.
>>>
>>> Cheers, D.
>>>
>>>
>> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/puppet-users/ph6_kdzr0Ec/unsubscribe.
> To unsubscribe from this group and all its topics, 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/e546756d-b24d-417c-9d78-0d8162210edc%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/e546756d-b24d-417c-9d78-0d8162210edc%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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/CALF7fHbr%3DwXRrAHWoYSvPz3Vtx_2SiGzRaxpeKTTr4F5GBEu5w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Help unit testing profile with dependency on ntp 5.0 module (module data)

[David Schmitt]

https://github.com/puppetlabs/puppetlabs_spec_helper/pull/107 and
https://github.com/puppetlabs/puppetlabs_spec_helper/pull/109 have partial
solutions, but never moved forward yet.
https://github.com/rnelson0/puppet-generate-puppetfile is another partial
solution.


d.

On 2 November 2016 at 16:41, Stephen Nesbitt <nesbittmeis...@gmail.com>
wrote:

> Garrett - Thanks for the heads up!
>
> David - thanks for the comment!
>
> I will note that I am now maintaining dependency information in 3
> locations - Puppetfile, metdata.json and .fixtures, Guess what is going to
> happen at some point ;-)
>
> Maybe I'm not aware of something, but there really should be a single
> canonical source of dependency requirements.
>
> -steve
>
> On Wednesday, November 2, 2016 at 6:55:05 AM UTC-7, David Schmitt wrote:
>>
>>
>>
>> On Tuesday, November 1, 2016 at 7:25:01 PM UTC, Garrett Honeycutt wrote:
>>
>>> I noticed that your .fixtures.yml do not include versions. This means
>>> that they will always test against the latest version. You probably want
>>> to change this to use the version you actually use.
>>>
>>
>> That really depends on the amount of time and the cadence people are
>> willing to invest in staying up-to-date. Shops with strict version
>> requirements and a waterfall-y workflow really should do that. Others with
>> a more fluid/agile/pipeline-oriented workflow are much better suited to
>> address upcomping changes when they happen, instead of batching it up.
>>
>> Cheers, D.
>>
>>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Puppet Users" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/puppet-users/ph6_kdzr0Ec/unsubscribe.
> To unsubscribe from this group and all its topics, 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/8df9baef-ea18-4b1f-80f1-184a98566e49%40googlegroups.com
> <https://groups.google.com/d/msgid/puppet-users/8df9baef-ea18-4b1f-80f1-184a98566e49%40googlegroups.com?utm_medium=email_source=footer>
> .
>
> 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/CALF7fHY64QLggrRh%3DcHm-6kfFZSYoEQE%2BdyeK-XUucQs9zgYzQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: Help unit testing profile with dependency on ntp 5.0 module (module data)

[David Schmitt]

On Tuesday, November 1, 2016 at 7:25:01 PM UTC, Garrett Honeycutt wrote:

> I noticed that your .fixtures.yml do not include versions. This means 
> that they will always test against the latest version. You probably want 
> to change this to use the version you actually use. 
>

That really depends on the amount of time and the cadence people are 
willing to invest in staying up-to-date. Shops with strict version 
requirements and a waterfall-y workflow really should do that. Others with 
a more fluid/agile/pipeline-oriented workflow are much better suited to 
address upcomping changes when they happen, instead of batching it up.

Cheers, D.
 

-- 
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/f3dbf427-35c6-4393-8da4-dd136c366f90%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Help unit testing profile with dependency on ntp 5.0 module (module data)

[David Schmitt]

Hi again,

The issue you are seeing is connected to the test not having facts 
available to properly populate the hierarchy used by data-in-modules in the 
NTP module.

I've added

  let :facts do
{
  os: {
name: 'Debian',
family: 'Debian',
release: { major: 'stretch/sid', full: 'stretch/sid' }
  }
}
  end

to the outer-most describe, and with that the test passed. Before you say 
it, yes the error messaging around this is atrocious and needs improvement. 
I've created https://tickets.puppetlabs.com/browse/PUP-6856 to track this.


Thanks for reporting this!
David


On Tuesday, November 1, 2016 at 10:12:21 AM UTC, David Schmitt wrote:
>
> Hi Steve,
>
> I can reproduce this locally, and it looks like some kind of setup issue 
> around how (rspec-)puppet is loading lookup data.
>
> I'll look into it, and keep you posted.
>
> Regards, David
>
> On Monday, October 31, 2016 at 2:39:54 AM UTC, Stephen Nesbitt wrote:
>>
>> All:
>>
>> I'm struggling to unit test a very simple profile with a dependency on 
>> the ntp 5.0.0 module - the ntp version implementing module data. The 
>> problem is that none of the default values for ntp are visible/available to 
>> the unit test as indicated by the failure:
>>   1) profile::ntp::client with default values for all parameters 
>> profile::ntp::client should compile into a catalogue without dependency 
>> cycles
>>  Failure/Error: it { is_expected.to compile.with_all_deps }
>>  
>>   error during compilation: Evaluation Error: Error while evaluating 
>> a Function Call, Class[Ntp]:
>>  expects a value for parameter 'autoupdate'
>>  expects a value for parameter 'broadcastclient'
>>  expects a value for parameter 'config'
>>  ...
>>
>>
>> The profile::ntp::client class is very simple:
>>
>> class profile::ntp::client {
>>  include ::ntp
>> }
>>
>> My spec helper is:
>>
>> require 'puppetlabs_spec_helper/module_spec_helper'
>>
>> RSpec.configure do |c|
>>  c.after(:suite) do
>>  RSpec::Puppet::Coverage.report!(95)
>>  end
>> end
>>
>> My .fixtures.yml
>>
>>
>> fixtures:
>>  forge_modules:
>>  ntp: 'puppetlabs/ntp'
>>  stdlib: 'puppetlabs/stdlib'
>>  symlinks:
>>  profile: "#{source_dir}/../profile"
>>
>>
>> My unit test:
>>
>> require 'spec_helper'
>>
>> describe 'profile::ntp::client' do
>>   context 'with default values for all parameters' do
>> describe 'profile::ntp::client' do
>>   it { is_expected.to compile.with_all_deps }
>>   # it { is_expected.to contain_class('profile::ntp::client') }
>>   # it { is_expected.to contain_class('::ntp') }
>>
>>   end
>>   end
>> end
>>
>>
>> Puppet version is 4.7.0. Host OS is ubuntu 16.04
>>
>>
>> Any help in resolving this would be much appreciated.
>>
>>
>> -steve
>>
>>

-- 
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/a708176a-e8e2-45c3-90ae-7e3148ffa1ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] Re: Help unit testing profile with dependency on ntp 5.0 module (module data)

[David Schmitt]

Hi Steve,

I can reproduce this locally, and it looks like some kind of setup issue 
around how (rspec-)puppet is loading lookup data.

I'll look into it, and keep you posted.

Regards, David

On Monday, October 31, 2016 at 2:39:54 AM UTC, Stephen Nesbitt wrote:
>
> All:
>
> I'm struggling to unit test a very simple profile with a dependency on the 
> ntp 5.0.0 module - the ntp version implementing module data. The problem is 
> that none of the default values for ntp are visible/available to the unit 
> test as indicated by the failure:
>   1) profile::ntp::client with default values for all parameters 
> profile::ntp::client should compile into a catalogue without dependency 
> cycles
>  Failure/Error: it { is_expected.to compile.with_all_deps }
>  
>   error during compilation: Evaluation Error: Error while evaluating 
> a Function Call, Class[Ntp]:
>  expects a value for parameter 'autoupdate'
>  expects a value for parameter 'broadcastclient'
>  expects a value for parameter 'config'
>  ...
>
>
> The profile::ntp::client class is very simple:
>
> class profile::ntp::client {
>  include ::ntp
> }
>
> My spec helper is:
>
> require 'puppetlabs_spec_helper/module_spec_helper'
>
> RSpec.configure do |c|
>  c.after(:suite) do
>  RSpec::Puppet::Coverage.report!(95)
>  end
> end
>
> My .fixtures.yml
>
>
> fixtures:
>  forge_modules:
>  ntp: 'puppetlabs/ntp'
>  stdlib: 'puppetlabs/stdlib'
>  symlinks:
>  profile: "#{source_dir}/../profile"
>
>
> My unit test:
>
> require 'spec_helper'
>
> describe 'profile::ntp::client' do
>   context 'with default values for all parameters' do
> describe 'profile::ntp::client' do
>   it { is_expected.to compile.with_all_deps }
>   # it { is_expected.to contain_class('profile::ntp::client') }
>   # it { is_expected.to contain_class('::ntp') }
>
>   end
>   end
> end
>
>
> Puppet version is 4.7.0. Host OS is ubuntu 16.04
>
>
> Any help in resolving this would be much appreciated.
>
>
> -steve
>
>

-- 
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/7188ddc7-c652-43b7-800a-1b5ee4f32376%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] March in Modules

[David Schmitt]

Dear *,

Here is a short summary of what happened in and around the Puppet Labs'
modules in March.

Releases of Supported Modules

   -

   puppetlabs/dsc  1.0.1: First
   supported release of the dsc module! Manage Windows PowerShell DSC (Desired
   State Configuration) resources within a puppet run. Performance
   improvements, added EmbeddedInstance Classes, update to new upstream
   definitions, updated reboot handling.
   -

   puppetlabs/azure  1.0.2:
   Improved error messages, removed too restrictive name length validation,
   updated docs, support hocon 1.0.1, improve test infrastructure.
   -

   puppetlabs/aws  1.4.0: ELB
   instance sets can now be modified, added ssl_certificate_id for ELBs, even
   more ELB improvements around edge-cases during usage, fix annoying issue
   managing multiple regions at once (GH#260), fix parsing of
   puppetlabs_aws_configuration.ini, improvements to VPC default choices.
   -

   puppetlabs/mysql  3.7.0: Too
   many improvements to list. Check out the Changelog
   !
   -

   puppetlabs/inifile  1.5.0:
   The long-awaited show_diff parameter for diffing the complete file on
   changes (or can also just show the md5 sums). Now cleans up harder when
   removing entries.
   -

   puppetlabs/puppet_agent
    1.1.0: Add a number
   of OS support features and a considerable amount of compatibility and bug
   fixes: SLES 10/11, Solaris 10, AIX, OSX 10.9, offline Windows added. See
   the Changelog
    for details.

Blueshift Releases

There were a number of module releases as part of Project Blueshift
:

   -

   puppetlabs/docker_ucp 
   0.1.1: set up a Docker UCP
   
   controller and join nodes to it.
   -

   puppetlabs/apk  0.1.0: Allows
   for managing system packages with Puppet on Alpine Linux, using the APK
   package manager. Once installed the module works like all other package
   providers.
   -

   puppetlabs/rkt  0.1.0: Installs
   and manages the rkt  container runtime
   and associated tools.
   -

   puppetlabs/rancher  0.1.0:
   Install the Rancher  server and accompanying agents
   on supported operating systems.
   -

   garethr/kubernetes  0.3.0:
   Added an experimental Puppet command (puppet kubernetes convert) which
   converts standard Kubernetes YAML files into Puppet code

Other Releases

   -

   puppetlabs/puppetdb 
   5.1.2: minor bugfix release
   -

   puppetlabs/puppetserver_gem
    0.2.0: adds the
   ability to use install & uninstall options as in the parent provider.
   -

   puppetlabs/hocon  0.9.4:
   bugfixes around changing and adding arrays, handle the case of the base
   library not being installed.
   -

   puppetlabs/mongodb  0.13.0:
   manage mongodb 3.x, mongodb_version fact, handle PID file, SSL support, add
   $maxconns, add SuSE. A host of minor bugfixes.

Notable happenings

   -

   The puppetforge  got a facelift for our new
   name and brand art.
   -

   puppetlabs/strings 
   0.4.0: A Puppet Face and plugin built on the YARD Documentation Tool
    and the Puppet 4 Parser. It is uses YARD and the
   Puppet Parser to generate HTML documentation about Puppet code and Puppet
   extensions written in Ruby. There are already some examples
    out there, showing the
   possibilities.
   -

   rspec-puppet  2.4.0: supports
   testing exported resources in the same way that normal resources in the
   catalog are tested. Access them in your examples using exported_resources.
   See "Testing Exported Resources
   " in
   the README for examples. Please note that this release fixed interop with
   puppetlabs_spec_helper so that setting STRICT_VARIABLES to “yes” now
   actually runs your specs under a correctly configured puppet, leading to
   unexpected - but correct - breakage in unit tests.
   -

   r10k  

[Puppet Users] rspec-puppet 2.4.0 released

[David Schmitt]

Hi *,

I'm very happy to announce a new release of rspec-puppet, the unit test
framework for puppet manifests:

This release now supports testing exported resources in the same way that
normal resources in the catalog are tested. Access them in your examples
using `exported_resources`. See "Testing Exported Resources" in the README
for examples.

### Changed

* This release pulls out much of the version-specific code into separate
classes to reduce complexity and enable easier maintenance going forward.

### Added

* Support colon-separated module_path and environmentpath values.
* Support a threshold for the code coverage test, that can fail the whole
run.
* Ensure a consistent environment for all examples by adding a forced
initialization of puppet before each.

### Credits

Thanks to Adrien Thebo, Arthur Gautier, Brett Gray, and Nicholas Hinds, as
well as all the folks helping out on github for their contributions to this
release.


Cheers, David Schmitt

PS: if you too want to help out, anything you can add to
https://github.com/rodjek/rspec-puppet/tree/gh-pages to improve the online
docs would be of great help!

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

[Puppet Users] rspec-puppet 2.3.2

[David Schmitt]

Hi,

over the weekend there was a situation where the newest puppet versions
(3.8.5 and 4.3.2) would interact badly with the latest version of
rspec-puppet (2.3.0).

Yesterday I uploaded 2.3.1 to fix the issue with 3.8.5 and today there is
2.3.2 to completely fix this across all puppet versions.

If you ran into errors like

NoMethodError: undefined method `resource' for nil:NilClass
>

or

Unsupported data type: 'Symbol' on node ...".
>

please retry with the rspec-puppet 2.3.2.

Apologies for any inconvenience.

David

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

[Puppet Users] rspec-puppet 2.3.0 released

[David Schmitt]

Hi *,

I'm very happy to announce a new release of rspec-puppet, the unit test 
framework for puppet manifests:



Rspec-puppet 2.3.0 now supports testing custom types, `:undef` values in 
params, structured facts, and checks resource dependencies recursively.


The settings in `module_path` and `manifest` are now respected 
throughout the code base. The former default for `module_path` 
(`'/etc/puppet/modules'`) was dropped to avoid accidentally poisoning 
the test environment with unrelated code.


To reduce the maintenance overhead of boilerplate code, rspec-puppet now 
provides some of the code that rspec-puppet-init deployed in helper 
files that you can just `require` instead.


This release also reduces memory usage on bigger testsuites drastically 
by reducing the caching of compiled catalogs.


### Changed
- Limit the catalogue cache to 16 entries. Significant memory savings 
and reduced runtime were observed in testing this.

- Prevent Puppet 3's \_timestamp fact from invalidating cache.
- Extracted catalog cache from RSpec::Puppet::Support.
- Updated README to use the rspec 3 syntax, and additional explanations.
- `contain_file(...).with_content(...)` will now only show the diff and 
not the full contents of the file.


### Added
- Custom type testing example group and matcher.
- before/require/subscribe/notify checking now searches recursively 
through all dependencies. `File[a] -> File[b] -> File[c]` is now matched 
by `contain_file('a').that_comes_before('File[c]')`, whereas earlier 
versions would have missed that.
- `let(:params)` now allows `:undef` to pass a literal undef value 
through to the subject.

- Support structured facts with keys as symbols or strings (\#295).
- rspec-puppet-init now creates smaller files, using rspec-puppet 
helpers, instead of pasting code into the module.

- Added a list of related projects to the README.

### Fixed
- Fix #276: `compile.and_raise_error` now correctly considers successful 
compilation an error
- Puppet's `modulepath` can now contain multiple entries and 
rspec-puppet will configure puppet to load code from all of them

- Support running with rspec 2.99 again
- non-class resources are now covered by the coverage code
- Fix #323/MODULES-2374: autorequires checking doesn't abort on 
"undefined method \`[]' for nil:NilClass"

- improved documentation for hiera integration, added example spec
- document the `scope` property

### Credits

Thanks to Adrien Thebo, Alex Harvey, Brian, Dan Bode, Dominic Cleal, 
Javier Palacios, Jeff McCune, Jordan Moldow, Peter van Zetten, Raphaël 
Pinson, Simon Kohlmeyer, and Tristan Colgate for their contributions to 
this release.


  -- David Schmitt

--
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/567057FF.9020309%40puppetlabs.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Beaker and mock services

[David Schmitt]

On 22/10/2015 08:06, Alex Harvey wrote:



On 21 October 2015 at 23:28, Gareth Rushgrove 
> wrote:


On 20 October 2015 at 08:49, Alex Harvey > wrote:
> Hi all,
>
> I am investigating whether or not I can use Beaker to do
acceptance testing
> on roles and profiles.
>
> I've had a look at Liam Bennett's excellent blog posts -
>

http://tech.opentable.co.uk/blog/2014/09/01/testing-puppet-with-beaker-pt-dot-3-testing-roles/
>
http://www.slideshare.net/liamjbennett/cfgmgmt2015-testing-with-beaker
>
> I need to handle a situation in my tests where, say, a role that
I am
> testing will apply a base class which will cause the node, for
instance, to
> join a FreeIPA domain.  But I don't want Beaker to actually
build a FreeIPA
> box.  And I don't want my short-lived node to join a real
FreeIPA domain.
>
> I would hope that Beaker could either build Mock Services
> https://en.wikipedia.org/wiki/Mock_object
>
> Or better still, tell Beaker to expect the base class to try to
apply the
> FreeIPA class, and just pretend it succeeds.  Just as you can
stub out
> methods in rspec etc.
>
> Has anyone done anything like this before?
>

You can actually do something like that :)

Beaker is going to run you Puppet code on the node(s) it spins up,
probably using apply manifest like so:

apply_manifest(pp, :catch_failures=>true)

If this sees an error while doing so (because your FreeIP class
doesn't apply) then it will throw an error. However...

If you check the API docs you can see:


http://www.rubydoc.info/github/puppetlabs/beaker/Beaker/DSL/Helpers/PuppetHelpers#apply_manifest_on-instance_method

apply_manifest(pp, :accept_all_exit_codes => true)

This will run your puppet code and not throw an error.

Now, whether this works for you really depends on if any other classes
depend on the FreeIPA class. And you can't easily test for idempotent
runs easily with this.

Another approach if you can change the puppet code is to introduce a
switch in the profile, for instance if a fact exists like MOCK_FREEIPA
you could not include the class. And then drop that fact into your
beaker test environment.

Also see the other points about testing at different levels but you
can absolutely do it in your acceptance tests.


Thanks Gareth.

Both of these solutions are a bit messy but it is good to know of all 
the options.  One of the big issues I would encounter immediately I 
used :accept_all_exit_codes is that the FreeIPA code takes several 
minutes to time out if the server can't be contacted.  Or if I moved 
all this logic associated with testing into the code, that would work, 
but it is not really where test logic belongs, and it would rather 
clutter my base classes.


I feel that there is some space here for a new approach to acceptance 
testing.  I am not sure that I agree that acceptance tests should be 
end-to-end tests.  Consider:


  * spinning up a FreeIPA system - not to mention all the other
external services that a base class might depend upon - takes a
long time.  The longer tests take to run, the less likely people
will actually run them.
  * not all developers will have workstations that can run such
resource-intensive tests.
  * I actually don't want to test that every single role can join the
FreeIPA domain - I only want to test that once, and preferably in
tests associated with my FreeIPA modules and classes.

Another approach might be to could create a long-lived acceptance test 
environment that only contains a DNS, FreeIPA, etc, however:


  * this would introduce a management burden - sysadmins needed to
keep them running, clean up junk related to broken tests etc.
  * It would also introduce a cost - we would have to pay Amazon to
always have these instances running.

I actually think deploying into a real UAT environment is the only 
real end-to-end test of the code that matters before it goes to 
production.


Now, if I am testing a web server role, rspec-puppet allows me to do 
very useful testing on catalogs - but if I am testing a front end web 
server role, I only want to know that it builds a properly configured 
Apache.  I suppose, therefore, that I could just test the front end 
web server profile; although it would be good to also test as much of 
the integration as is practical.


What if Beaker was extended to provide a framework for provisioning 
fakes - if it accepted plugins somehow for a mocked up FreeIPA service 
etc.  Would that be unrealistically complicated?  In the development 
world, developers must be mocking up these sorts of fakes all the 
time.  How do they do it - do they just continually reinvent the wheel 
or are there 

Re: [Puppet Users] Re: Confine a custom fact by file existence

[David Schmitt]

On 22/10/2015 13:38, jcbollinger wrote:



On Thursday, October 22, 2015 at 3:00:55 AM UTC-5, Thomas Müller wrote:

Hi

I know it's possible to confine a fact by other facts like
"confine :operatingsystem => :Fedora".

But i have a fact which requires a binary from a rpm package which
is only installed by puppet. For the first puppet run tries to
execute the not-yet installed binary and fails.

is it possible to use something like this to confine based on
existing files?

|
confine File.exists?(/path/to/binary)

|



Why, yes, but the syntax is:

|
confine :exists =>"/path/to/binary"
|

, as documented 
 
among the provider development documentation.




Facter, not providers, John. Those are, sadly, different beasts.


Cheers, David

--
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/5628E1FB.1010004%40dasz.at.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Re: how to write a loop to convert all erb files to regular file?

[David Schmitt]

On 21/10/2015 21:32, yi zhao wrote:

Hi,David,

thank you for the quick reply, I am new to resource type define so may 
need your help to troubleshoot:


mycode:

 $db_setup_home = "${dbnamehome}/dbs/create_${dbname}"

 define rac_script($home, $source) {
   file { "${home}/${name}.txt":
 content => template("${module_name}/${name}.txt.erb",


^^ needs closing bracket


D.


 mode => '0644',
 owner => 1001,
 group => 1000,
   }
 }

   rac_script {
  [ 'create_pre_rac_setup',
'run_this_rac',
'create_catalog',
'create_database_rac',
  ]:
 home => "$db_setup_home",
 source => "$module_name",
}


error:

Debug: Caching connection for https://puppet:8140
Error: Could not retrieve catalog from remote server: Error 400 on 
SERVER: Syntax error at '=>' at 
/etc/puppetlabs/code/environments/production/modules/exadata/manifests/init.pp:152:15 
on node node1.example.com

Warning: Not using cache on failed catalog
Error: Could not retrieve catalog; skipping run



On Tuesday, October 20, 2015 at 5:23:13 PM UTC-7, yi zhao wrote:

Hi,
so we have a few template setup under my_module/templates/
like
create_pre_rac_setup.sh.erb
run_this_rac.sh.erb



and I write someting in init.pp

  $db_setup_home = "$dbnamehome/dbs/create_$dbname"
 file { "$db_setup_home/create_pre_rac_setup_$dbname.sh":
 ensure => 'file',
 content =>
template("${module_name}/create_pre_rac_setup.sh.erb"),
 mode => '0644',
 owner => 1001,
 group => 1000,
   }

file { "$db_setup_home/run_this_rac_$dbname.sh":
 ensure => 'file',
 content => template("${module_name}/run_this_rac.sh.erb"),
 mode => '0644',
 owner => 1001,
 group => 1000,
   }

but if I have 500 templates, I would have to write 500 files which
is against puppet thinking, is there a way to write a loop to read
all template files under my_module/templates/
then just loop to create the files with the same naming standard?


thank you.


--
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/b9b244db-3464-4a17-81b6-aae72e5210ee%40googlegroups.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/5628176B.8030707%40dasz.at.
For more options, visit https://groups.google.com/d/optout.