Re: [Puppet-dev] Puppet 5 release planning

Rather than calling the new package repository "puppet", it might make more sense to call it "puppet5". That way, when Puppet 6 rolls around, it can go into its own repository ("puppet6") and people can change the repository over once they've tested that their code works with the new version. On M

RE: [Puppet-dev] Signal boost on HI-490 - moving hiera.yaml outofcodedir

5:48 PM, Eli Young wrote: One side effect of this change would appear to be the inability to use/test a new hiera, uh, hierarchy or backend in a feature branch without affecting the master branch. But ... you already can't do that because the hierarchy's global. Unless I greatly mis

RE: [Puppet-dev] Signal boost on HI-490 - moving hiera.yaml out ofcodedir

One side effect of this change would appear to be the inability to use/test a new hiera, uh, hierarchy or backend in a feature branch without affecting the master branch. Sent from my Windows 10 phone From: Eric Sorenson Sent: Monday, March 14, 2016 5:43 PM To: Puppet Developers Subject: [Puppe

RE: [Puppet-dev] PUP-5296

My guess, based on similar behavior in Chef, is that, for SysV init scripts, it's trying to use the SysV init system directly either via the service command or by calling the scripts themselves directly. Unfortunately, this doesn’t play super nicely with SysV init scripts that have been started

Re: [Puppet-dev] RFC - A specification for module schemas

On Mon, Feb 1, 2016 at 11:48 AM, Trevor Vaughan wrote: > I would *love* to see something like this hit the core language, but there > are quite a few cases where I have items that can be a Boolean, Number, or > String (I'm still not loving needing to convert Numbers to Strings > everywhere for co

Re: [Puppet-dev] Puppetconf 2015: pre-summit tea party

Oh no! I wish I'd realized this was happening. My flight gets in at 8:35PM and I can't change it unless I want to pay something like $135, which I do not. I'll have to try to make it next year. Have fun! On Tue, Sep 15, 2015 at 11:36 AM, Kara Sowles wrote: > +1 you folks have me in tears laughi

Re: [Puppet-dev] Accessing puppet catalog in provider self.* methods

Oh, gotcha. Sorry, forgot that you had to do this in the class context. On Friday, January 30, 2015 at 2:20:28 PM UTC-8, Nan Liu wrote: > > On Fri, Jan 30, 2015 at 2:34 PM, Eli Young > wrote: > >> On Friday, January 30, 2015 at 12:24:25 PM UTC-8, Nan Liu wrote: >>> &g

Re: [Puppet-dev] Accessing puppet catalog in provider self.* methods

On Friday, January 30, 2015 at 12:24:25 PM UTC-8, Nan Liu wrote: > > I was able to work around this by abusing self.prefetch, since the > transaction layer passes in a subset of resources: > > def self.prefetch(resources) > catalog = resources[resources.keys.first].catalog > # Note: catalo

[Puppet-dev] Re: The host type has unexpected behavior and is not idempotent

On Thursday, January 29, 2015 at 7:27:10 AM UTC-8, John Bollinger wrote: > > > DNS resolvers are irrelevant to the hosts file format. The hosts file is > not a *DNS* data source, even if resolver libraries happen to consult it, > too. In fact, the original objective of DNS was to altogether r

[Puppet-dev] Re: The host type has unexpected behavior and is not idempotent

On Tuesday, January 27, 2015 at 2:53:46 PM UTC-8, John Bollinger wrote: > > > As far as I can tell, it is a design characteristic of the current hosts > file format that it associates each address with exactly one canonical > name, and each canonical name with exactly one address. This is a bit

[Puppet-dev] The host type has unexpected behavior and is not idempotent

As per PUP-3901 , the host type has some serious issues. Major issues with the current design: 1. The namevar: - It's currently the canonical hostname. This means that a hostname can be the canonical representation for at most 1 IP add