That's awesome. We're not yet up to Puppet 4, but your module is good
inspiration.
Thanks, Martijn
Op donderdag 3 december 2015 22:18:05 UTC+1 schreef David Danzilio:
>
> Let's Encrypt moved to public beta status today; in honor of that here's a
> Puppet module to install the client and request
All,
I recently upgraded my Puppet (open source) install to Puppet 4.3.0.
I'm currently in the process of updating internal documentation and
training the rest of my teams, but I was wondering if anyone had any
patterns or best practices that were specific to puppet 4? Specifically in
cases wh
uppetlabs.com/download-puppet-enterprise-expand>
>
> Want to try Puppet Enterprise 2015.3 on up to 10 nodes for free? Try it!
> <https://puppetlabs.com/download-puppet-enterprisels=email&ccn=ankeny-2015&pub=email&cid=701G000Fl5e&utm_campaign=ankeny-2015&utm_me
I'll be releasing a type/provider generator that creates these files with
basic code and unit tests in the next release of puppet-retrospec. You can
use right now if you want to compile the gem
yourself. https://github.com/nwops/puppet-retrospec/tree/development.
Types and providers are docum
On Monday, December 7, 2015 at 4:51:10 PM UTC-6, Sean wrote:
>
> John,
>
> Thanks for the reply. To answer your first question, no I'm not
> completely sure. What I can say is that I can run the commands in a shell
> by hand and the result is what I hope for. When I run puppet, with this
>
on up to 10 nodes for free? Try it!
<https://puppetlabs.com/download-puppet-enterprisels=email&ccn=ankeny-2015&pub=email&cid=701G000Fl5e&utm_campaign=ankeny-2015&utm_medium=email&utm_source=email-20151208>
If you have any questions, please don’t hesitate to r
On Monday, December 7, 2015 at 4:59:47 PM UTC-6, Dan Mahoney wrote:
>
> Hey all,
>
> Everything I've done thusfar in creating my own custom modules has drilled
> some basics into my head -- these are right from the puppet web docs:
>
> "A module’s classes, defined types, and plugins *should all
On Monday, December 7, 2015 at 7:57:41 PM UTC-6, 韩雨哲 wrote:
>
> In the module, the classes are designed like this:
> A::install{}
>
> class A{
> A::install{}
> }
>
> class A::B{
> A::B::install{
> require -> Class[A]
> }
> }
>
> class A::C{
> A::C::install{
> require -> Class[A]
>
On 2015-08-12 1:46, Adrian Muraru wrote:
With the addition of subkeys lookup, e.g. hiera('a.b.c'), those yaml
configuration files already including top level keys with a "." in the
key name are rendered invalid.
Is there a way to disable subkey lookup support on demand for a given
backend?
Not
