On 06/04/14 15:49, Andy Parker wrote:
> 2 Put directory environments behind a feature flag (disabled by default)
> - PRO: completely removes the possibility of unwanted collisions
> - CON: users will have to take extra action to use the new system.
> PE will
> have to ensure that th
On 7 April 2014 10:27, Dominic Cleal wrote:
> On 06/04/14 15:49, Andy Parker wrote:
> > 2 Put directory environments behind a feature flag (disabled by
> default)
> > - PRO: completely removes the possibility of unwanted collisions
> > - CON: users will have to take extra action to use
On Mon, Apr 7, 2014 at 1:27 AM, Dominic Cleal wrote:
> On 06/04/14 15:49, Andy Parker wrote:
> > 2 Put directory environments behind a feature flag (disabled by
> default)
> > - PRO: completely removes the possibility of unwanted collisions
> > - CON: users will have to take extra actio
On Mon, Apr 7, 2014 at 5:17 AM, Andy Parker wrote:
> Once they are on should it be the behavior that showed up in 3.5.0
> (directory -> legacy) or should it have directory envs replace legacy envs?
Is there functionality implemented by legacy that can't be replicated
by directory (at the cost of
On Mon, Apr 7, 2014 at 5:53 AM, Dustin J. Mitchell wrote:
> On Mon, Apr 7, 2014 at 5:17 AM, Andy Parker wrote:
> > Once they are on should it be the behavior that showed up in 3.5.0
> > (directory -> legacy) or should it have directory envs replace legacy
> envs?
>
> Is there functionality implem
I'd second what Spencer said.
We (user experience research and eric0) talked to 8 Puppet users the past
week to learn how they use Environments and their opinions on Directory
Environments, and every single one is making heavy use of Puppet
Environments, in their original words "I won't use Pup
On Monday, April 7, 2014 3:03:34 PM UTC+2, Andy Parker wrote:
>
> On Mon, Apr 7, 2014 at 5:53 AM, Dustin J. Mitchell
>
> > wrote:
>
>> On Mon, Apr 7, 2014 at 5:17 AM, Andy Parker
>> >
>> wrote:
>> > Once they are on should it be the behavior that showed up in 3.5.0
>> > (directory -> legacy) or
On Mon, Apr 7, 2014 at 7:12 AM, Per Cederqvist wrote:
> On Monday, April 7, 2014 3:03:34 PM UTC+2, Andy Parker wrote:
>>
>> On Mon, Apr 7, 2014 at 5:53 AM, Dustin J. Mitchell wrote:
>>
>> On Mon, Apr 7, 2014 at 5:17 AM, Andy Parker wrote:
>>> > Once they are on should it be the behavior that sho
On Sunday, April 6, 2014 9:49:55 AM UTC-5, Andy Parker wrote:
>
> If the follow doesn't make sense, I'm sorry. I just got off a plane from
> Seattle to Paris and am still a little sleep deprived.
>
> After release of 3.5.0 it turned out that the new directory environments
> interfered with one o
Hmm. Lots of things are possible, just need to avoid collision with
the parameter naming.
Myresource <<| .environment == $$::environment |>>#
dalen's suggestion
Myresource <<| _environment == $$::environment |>> #
alternate to dalen's suggestion
Myresource <<| catalog.environ
I like this one:
Myresource <<| Environment == $$::environment |>> # ye old
capitalization like other parts of puppet
It's easy to read and makes me think "a think that's defined somewhere
else".
Trevor
On Mon, Apr 7, 2014 at 11:04 AM, Ken Barber wrote:
> Hmm. Lots of things are
On 2014-07-04 17:04, Ken Barber wrote:
Hmm. Lots of things are possible, just need to avoid collision with
the parameter naming.
Myresource <<| .environment == $$::environment |>>#
dalen's suggestion
Nah, that goes down the path of using different syntax and even
terminals in quer
On Mon, Apr 7, 2014 at 8:04 AM, Ken Barber wrote:
> Hmm. Lots of things are possible, just need to avoid collision with
> the parameter naming.
>
> Myresource <<| .environment == $$::environment |>>#
> dalen's suggestion
> Myresource <<| _environment == $$::environment |>> #
13 matches
Mail list logo
