Re: [Puppet-dev] Re: Changes to PuppetDB to support proper environments

To be honest, I'm not sure it's a big deal. I'm okay with just re-initializing the database and pushing new puppetdb and modified code on the same day. The use here is to keep test stuff out of production only, not anything more complicated. On Fri, Mar 28, 2014 at 6:52 PM, Ken Barber wrote: >

Re: [Puppet-dev] Re: Changes to PuppetDB to support proper environments

> We've been simply tagging resources with env_${environment} both on export > and collect. Which sounds like a reasonable work-around. In this case only option 2 would guarantee uninterrupted service for you correct? ken. -- You received this message because you are subscribed to the Google Gr

Re: [Puppet-dev] Re: Changes to PuppetDB to support proper environments

We've been simply tagging resources with env_${environment} both on export and collect. On Fri, Mar 28, 2014 at 1:05 PM, Ken Barber wrote: > Thanks for your perspective John, much appreciated. > > On Fri, Mar 28, 2014 at 7:15 PM, John Bollinger > wrote: > > > > > > On Friday, March 28, 2014 12

Re: [Puppet-dev] Re: Changes to PuppetDB to support proper environments

Thanks for your perspective John, much appreciated. On Fri, Mar 28, 2014 at 7:15 PM, John Bollinger wrote: > > > On Friday, March 28, 2014 12:46:41 PM UTC-5, Ken Barber wrote: >> >> Hey all, >> >> TL;DR: We're adding support to environments to PuppetDB but have a >> small migration hassle we want

[Puppet-dev] Re: Changes to PuppetDB to support proper environments

On Friday, March 28, 2014 12:46:41 PM UTC-5, Ken Barber wrote: > > Hey all, > > TL;DR: We're adding support to environments to PuppetDB but have a > small migration hassle we wanted some community opinion on. If you're > interested in PuppetDB and environments read on. > > [...] > > Anyway -

Re: [Puppet-dev] Re: Best practices for ensure property values

On Fri, Mar 28, 2014 at 11:12 AM, Felix Frank < felix.fr...@alumni.tu-berlin.de> wrote: > We're getting side-tracked ;) but here's why those should really be the > same to Puppet: What the catalog refers to as a 'file' is actually a > file system entry. > True, but that is not how you think about

[Puppet-dev] Announce: Facter 2.0.1-rc4 Now Available

Facter 2.0.1-rc4 Pre-release - RC4: March 28, 2014 - RC3: March 25, 2014 - RC2: March 12, 2014 - RC1: February 28, 2014 Facter 2.0.1-rc4 Downloads Source: https://downloads.puppetlabs.com/facter/facter-2.0.1-rc4.tar.gz

Re: [Puppet-dev] Re: Best practices for ensure property values

On Thu, Mar 27, 2014 at 12:22 PM, Daniele Sluijters < daniele.sluijt...@gmail.com> wrote: > Hey, > > As far as package is concerned I prefer Adrien's suggestion of ensure => > held, version => 0.4. This is entirely personal but I think ensure is a > good place to model the 'state' of a package and

Re: [Puppet-dev] rspec-puppet and local variable values

Yep, but I need the value of $bar to figure out what the later resource name is! A better example: class foo { $bar = interesting_function('baz') file { "/some/path/$bar": content => 'whatever' } } So, given that I don't necessarily know what interesting_function is going to generate,

[Puppet-dev] Changes to PuppetDB to support proper environments

Hey all, TL;DR: We're adding support to environments to PuppetDB but have a small migration hassle we wanted some community opinion on. If you're interested in PuppetDB and environments read on. So we're looking at adding first class support to PuppetDB for environments. In the past we would happ

[Puppet-dev] Re: Best practices for ensure property values

My commments on the topic of ensure property values are not specific to any of the particular previous comments, so I am top posting. The boundary between which part of the resource's life-cycle that should be described by the ensure parameter, and other parameters/properties is very blurry. T

Re: [Puppet-dev] rspec-puppet and local variable values

Hmm...so you're saying that I would mock the variable result with the real function to get the real result? That's doesn't make me super happy but if it works, I'll take it! Trevor On Fri, Mar 28, 2014 at 11:26 AM, Johan De Wit wrote: > I stumbled against this text : > > you can write a mock

Re: [Puppet-dev] rspec-puppet and local variable values

I could be way off here, but shouldn't you be testing the resource $bar ends up in, rather than the value of $bar itself? On Fri, Mar 28, 2014 at 11:15 AM, Trevor Vaughan wrote: > Hmm...so you're saying that I would mock the variable result with the real > function to get the real result? > > Th

Re: [Puppet-dev] Re: Best practices for ensure property values

On 03/28/2014 04:01 PM, Jesse Hathaway wrote: > Thanks for pointing out this definition. I think asking whether an > ensure parameter models a fundamental aspect of a resource is a > helpful litmus test for what values an ensure parameter should have > for a resource. Nitpick: Ensure is universall

Re: [Puppet-dev] rspec-puppet and local variable values

I stumbled against this text : you can write a mock function my_mock_function.rb and put it under {module name}/spec / fixtures / modules / {module name}/ lib / puppet / parser / If you put the real function(s) so there ? On 28/03/14 15:39, Trevor Vaughan wrote: Hopefully I didn't just

Re: [Puppet-dev] Re: Best practices for ensure property values

> > The language reference describes 'ensure' as managing "the most > fundamental aspect of the resource on the target system." For many types, > simple presence or absence fits that description, but I don't necessarily > call it abuse to support finer gradations of "present", as File does. On >

[Puppet-dev] rspec-puppet and local variable values

Hopefully I didn't just overlook this in the docs but, in rspec-puppet, how would you go about getting the value of $bar from the following? class foo { $bar = interesting_function('baz') } I've inspected everything that I think is obvious and I don't want to try and stub what 'interesting_func