So, we ran across this one today and I dug up the thread where Felix Frank,
John Bolinger, and I all agreed (https://goo.gl/LQ20bj) that there were
solid use cases for keeping the Webrick version of Puppet around.
We were all fine with losing Rack support but, as of right now, I do not
know how
On 2015-15-07 12:22, Peter Huene wrote:
On Wed, Jul 15, 2015 at 12:18 PM, Trevor Vaughan tvaug...@onyxpoint.com
mailto:tvaug...@onyxpoint.com wrote:
Indeed, I did change it to that but it would still be nice to know
what's going on so that I can stuff it into rspec and check for it.
Fedora 20 reached end of life on 2015-06-23 [1], so we are no
longer building new packages for it and will remove it from our yum
repository on Monday, August 10.
[1] -
https://lists.fedoraproject.org/pipermail/devel-announce/2015-May/001586.html
--
Melissa Stone
Release Engineer, Puppet Labs
Indeed, I did change it to that but it would still be nice to know what's
going on so that I can stuff it into rspec and check for it.
Thanks,
Trevor
On Wed, Jul 15, 2015 at 2:59 PM, R.I.Pienaar r...@devco.net wrote:
- Original Message -
From: Trevor Vaughan tvaug...@onyxpoint.com
It looks like we do:
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/parser/scope.rb#L652-L654
On Wed, Jul 15, 2015 at 12:39 PM Trevor Vaughan tvaug...@onyxpoint.com
wrote:
Fair enough, and we usually do that. I just wanted to know what was frozen
so that we could properly
Move along, nothing to see here.
Thanks Adrien.
Trevor
On Wed, Jul 15, 2015 at 3:50 PM, Adrien Thebo adr...@puppetlabs.com wrote:
This not only became the default, but was removed as a tunable in Puppet
4: (
In this case, it was a custom function that was tripping things up.
Looking through the code, I *think* this was the scenario:
1) Fact = trusted['certname']
2) Function call to parse_host($trusted['certname'])
3) Parse host:
host = args.first
host.strip! # Here's the offender
I also tried
Fair enough, and we usually do that. I just wanted to know what was frozen
so that we could properly duplicate it in our spec tests.
Out of curiosity, why not freeze all strings from Facter?
On Wed, Jul 15, 2015 at 3:22 PM, Peter Huene peter.hu...@puppetlabs.com
wrote:
On Wed, Jul 15, 2015 at
And it looks like _I_ was too hasty; this is done when immutable_node_data
is set. (
https://github.com/puppetlabs/puppet/commit/8ccb3923b7ddd22e53d53dd193edc618b218a2a6
)
On Wed, Jul 15, 2015 at 12:40 PM Adrien Thebo adr...@puppetlabs.com wrote:
It looks like we do:
- Original Message -
From: Trevor Vaughan tvaug...@onyxpoint.com
To: puppet-dev puppet-dev@googlegroups.com
Sent: Wednesday, July 15, 2015 7:50:36 PM
Subject: Re: [Puppet-dev] How do you know what variables are frozen?
In this case, it was a custom function that was tripping things
On Wed, Jul 15, 2015 at 12:18 PM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:
Indeed, I did change it to that but it would still be nice to know what's
going on so that I can stuff it into rspec and check for it.
Puppet's compiler intentionally freezes $trusted and its values. If you
intend
Ah, we use trusted_node_data so that's probably why I'm hitting this (and
glad that I am so we caught that bug prior to release).
Why wouldn't this be the default?
Thanks,
Trevor
On Wed, Jul 15, 2015 at 3:41 PM, Adrien Thebo adr...@puppetlabs.com wrote:
And it looks like _I_ was too hasty;
This not only became the default, but was removed as a tunable in Puppet 4:
(
https://github.com/puppetlabs/puppet/commit/19f223f2e2b20b19701472babfa66b0ceea59bae
)
On Wed, Jul 15, 2015 at 12:44 PM Trevor Vaughan tvaug...@onyxpoint.com
wrote:
Ah, we use trusted_node_data so that's probably why
In this release:
- Add environment variable to expose --no-color
* use BEAKER_color or RS_COLOR = no to disable coloring log output
Details here:
https://github.com/puppetlabs/beaker-rspec/blob/master/HISTORY.md#LATEST
High Fives!
alice.
--
You received this message because you are
Awesome. Thanks! Been wanting this feature for a while.
--
Spencer Krum
n...@spencerkrum.com
On Wed, Jul 15, 2015, at 02:01 PM, Alice Nodelman wrote:
In this release:
- Add environment variable to expose --no-color
* use BEAKER_color or RS_COLOR = no to disable coloring log
I *think* I've just run into a case where I was trying to run strip! on a
frozen Facter variable.
1) How do we know what variables are frozen coming from Facter?
2) What is the best way to ensure that our tests check for this case?
Thanks,
Trevor
--
Trevor Vaughan
Vice President, Onyx Point,
Hi Eric,
#2 does happen with the unless_uid param but #1 and #3 are my 80% use case.
I.e. I want to purge the crontabs for 'root', 'joe', and 'bob' and If
someone did things by hand, please don't break it but purge everyone that
we're managing because we want to manage them.
These shouldn't be
On Wed, Jul 15, 2015 at 8:59 AM, Trevor Vaughan tvaug...@onyxpoint.com
wrote:
I *think* I've just run into a case where I was trying to run strip! on a
frozen Facter variable.
1) How do we know what variables are frozen coming from Facter?
Facter shouldn't be freezing resolved fact values,
- Original Message -
From: Peter Huene peter.hu...@puppetlabs.com
To: puppet-dev puppet-dev@googlegroups.com
Sent: Wednesday, July 15, 2015 5:18:29 PM
Subject: Re: [Puppet-dev] How do you know what variables are frozen?
On Wed, Jul 15, 2015 at 8:59 AM, Trevor Vaughan
19 matches
Mail list logo
