Re: [Puppet-dev]

[Dominic Cleal]

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 they are enabled and the migration is done.

I prefer this option, it's clean and as Spencer said, other new features
work in the same way.

-- 
Dominic Cleal
Red Hat Engineering

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53426165.7020501%40redhat.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev]

[Erik Dalén]

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 the new system.
> > PE will
> >   have to ensure that they are enabled and the migration is done.
>
> I prefer this option, it's clean and as Spencer said, other new features
> work in the same way.
>

Yes, it seems like the best option to me as well. Can add deprecation
warning if the feature is turned off in 3.6.

-- 
Erik Dalén

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAAAzDLf2rmOi32svxrhcgEAPe4oJMXPpj6sUFXHo47d2QXkn8Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev]

[Andy Parker]

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 action to use the new system.
> > PE will
> >   have to ensure that they are enabled and the migration is done.
>
> I prefer this option, it's clean and as Spencer said, other new features
> work in the same way.
>
>
sigh...yeah that is looking like it might have to be the choice. I was
hoping to avoid it and find a way to slot this new functionality in without
a feature flag. I wanted to make the migration to the new environments much
more seamless than a feature flag so that people could start migrating much
earlier. On reflection this might have been a little too ambitions. As we
were putting together the changes for 3.6, which included deprecating the
existing parts and updating our packages (PUP-1433), it turned out that
automatically creating the directory in the packages would cause problems
for users upgrading. In fact, I think we came up with the same problem that
everyone encountered, but we just didn't put 2 and 2 together.

The code for option 4 that I put together, seems to solve the issue as
well, but it does it at the expense of needing to look for the existence of
the directories in the modulepath. This sounds worse than I think it might
be. Since I changed to order that it searches to be legacy -> directory
instead of directory -> legacy (legacy is what we've been calling the
existing environment configuration mechanisms), and since I suspect that it
is pretty unlikely that a request would be for an environment that has not
module directories, then I think it has only added a few (# of entries in
the modulepath) extra stat calls per request. Not ideal, but maybe ok?

If I were to implement the feature flag, how should it work? I could make
the environmentpath setting the flag and have the default value "", then
anything else would turn them on. 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?


> --
> Dominic Cleal
> Red Hat Engineering
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/53426165.7020501%40redhat.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrew Parker
a...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer

*Join us at PuppetConf 2014, September 23-24 in San Francisco -
**http://puppetconf.com
*

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CANhgQXv6MS%2B-%3DQrH1vrS2nSMevLyxR8Po578LDnKiuWqxwYHVQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev]

[Dustin J. Mitchell]

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 rearranging some directories, perhaps)?
>From my read, no -- in which case, best to only have one way to
implement envs.

Dustin

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAJtE5vQVZrovWuNsQ%3DWCzsOM0O0xMpS_Owp%2BpzM_FtdK-AXXOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev]

[Andy Parker]

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 implemented by legacy that can't be replicated
> by directory (at the cost of rearranging some directories, perhaps)?
> From my read, no -- in which case, best to only have one way to
> implement envs.
>
>
3.5.0 should be able to handle manifests and modules completely. It doesn't
have config_version implemented. 3.6.0 has everything that the directory
environments will support, which ends up making the translation to them
pretty simple in most cases.


> Dustin
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAJtE5vQVZrovWuNsQ%3DWCzsOM0O0xMpS_Owp%2BpzM_FtdK-AXXOA%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrew Parker
a...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer

*Join us at PuppetConf 2014, September 23-24 in San Francisco -
**http://puppetconf.com
*

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CANhgQXtrF0cS8RVU9okEkzk7LFXACpp73SX7d89%2Br%3D%3DZLDYzbQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev]

[Fei Guo]

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 Puppet if there is no 
environments, it's crucial to what we do". Not surprisingly, most of them 
use dynamic environments, so $environment is something critical too. On 
that note, option 7 and 8 are definitely no-go.
Additionally, when we explained what Directory Environments feature is and 
how it works, users have very positive reaction to the feature and they 
believe this is the right path to go.

I think the feature complete directory environments (that you can configure 
modulepath, manifests, config_version) will solve a lot of the problems and 
challenges users run into in the just released 3.5 incomplete version of 
Directory Environments. I'd agree the migration could be challenging to 
take consideration of all edge cases, although the 8 users we talked to 
last week have fairly standard use cases (mostly it's just modulepath and 
manifests being configurable).


On Sunday, April 6, 2014 8:13:24 AM UTC-7, Spencer Krum wrote:
>
> Hi Andy,
>
> Thanks for compiling this list of options. As a user of Puppet and not a 
> dev, here are my reactions: I think options 7 and 8 are non-starters, we 
> need that functionality. Option 9 would be very hard to handle all cases. 
> Option 3 would cause a debugging nightmare for all of us. I think 4 and 5 
> are again going to be very racy. I like directory environments so I don't 
> like 6 either. 
>
> I think option 2 is the way forward. This is in keeping with the other 
> experimental features rolled out in the 3.x line. Power users can turn on 
> directory environments and figure it out, then write blog posts and other 
> documentation on how to use it for the more causal Puppet users. Directory 
> environments can join the growing list of things that are optional in 3.x 
> and will be default in 4.x. I don't particularly hate option 1 but I do 
> think it would be better to force users to use either the old way or the 
> new way, not both at the same time.
>
> Thanks again,
> Spencer
>
>
> On Sun, Apr 6, 2014 at 7:49 AM, 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 of the most common ways of setting up dynamic 
>> environments.
>> Specifically, the original blog post about using "$environment" 
>> interpolation
>> in puppet.conf showed putting the various pieces of the environments in
>> /etc/puppet/environments, which is the same location that I chose as the
>> default environmentpath.
>>
>> Since a number of users had put directories inside that directory, and 
>> these
>>  directories were supposed to represent environments, they appeared to the
>> directory environment implementation to *be* directory environments.
>> Unfortunately the directories where only part of the full environment and 
>> so
>> when the directory environment code took over, it produced environment
>> configurations within puppet that were incomplete, sometimes in very 
>> subtle
>> ways.
>>
>> I've tried to come up with various ways that could resolve the collision 
>> of
>> directory environments and dynamic environemnts:
>>
>>   1 Change the default environmentpath to something else
>> - PRO: This reduces the chance for collision. It can reduce it to 
>> near zero
>>   if we change the default environmentpath to something that is highly
>>   unlikely to be used (/etc/puppet/asdf for example)
>> - CON: The chance isn't completely gone and it leaves us with a
>>   less-than-ideal default when these are enabled by default (unless we
>>   change the default when other environment options are removed)
>>   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 they are enabled and the migration is done.
>>   3 Add heuristics for when a directory that is encountered in the
>> environmentpath truely constitutes a "directory environment"
>> - PRO: the directory environments are enabled by default, they won't
>>   (depending on heuristics chosen) interfere with existing 
>> configurations
>> - CON: using heuristics would remove some valid directory environment
>>   configurations. Heuristics would also fail at times and cause the
>>   diagnosis of the problem to become more complicated.
>>   4 Make directory environments lower priority than $environment-style 
>> dynamic
>> environments
>> - PRO: this would completely preser

Re: [Puppet-dev]

[Per Cederqvist]

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 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 rearranging some directories, perhaps)?
>> From my read, no -- in which case, best to only have one way to
>> implement envs.
>>
>>
> 3.5.0 should be able to handle manifests and modules completely. It 
> doesn't have config_version implemented. 3.6.0 has everything that the 
> directory environments will support, which ends up making the translation 
> to them pretty simple in most cases.
>  
>

Really? I have three directories in my modulepath:

 - modules: this is were I store generic modules
 - services: this is site-specific modules
 - forge: modules I have downloaded from the Puppet Forge

The services area is an idea I got from 
.
It is perhaps not as useful today as it once was, since we have hiera 
today. But I suspect I am not alone in
having several areas of modules.

Personally, I like having modules I got from external sourced separated 
from modules I have
written myself. It makes it easier to know what I need to upgrade and what 
I need to take
full responsibility for myself.

My understanding is that with Directory Environments I'm restricted to a 
single area.
Given that this breaks with a "Puppet Best Practice" document I think this 
is a
severe restriction. (I hope I will be able to use multiple areas in the 
future as well.)

For reference, this is how I set up my modulepath now, after having made 
changes so
that my setup works with Puppet 3.5.0:

[master]

modulepath=/etc/puppet/environs/$environment/modules:/etc/puppet/environs/$environment/services:/etc/puppet/environs/$environment/forge
manifest=/etc/puppet/environs/$environment/manifests/

Yours,
/ceder 

Dustin
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "Puppet Developers" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to puppet-dev+...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/puppet-dev/CAJtE5vQVZrovWuNsQ%3DWCzsOM0O0xMpS_Owp%2BpzM_FtdK-AXXOA%40mail.gmail.com
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Andrew Parker
> a...@puppetlabs.com 
> Freenode: zaphod42
> Twitter: @aparker42
> Software Developer
>
> *Join us at PuppetConf 2014, September 23-24 in San Francisco - 
> **http://puppetconf.com 
> *
>  

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/7db42ac7-fcd6-4e77-8ba0-2fbf911a2ac5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet-dev]

[Andy Parker]

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 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 rearranging some directories, perhaps)?
>>> From my read, no -- in which case, best to only have one way to
>>> implement envs.
>>>
>>>
>> 3.5.0 should be able to handle manifests and modules completely. It
>> doesn't have config_version implemented. 3.6.0 has everything that the
>> directory environments will support, which ends up making the translation
>> to them pretty simple in most cases.
>>
>>
>
> Really? I have three directories in my modulepath:
>
>
Sorry, I should have been more explicit. 3.5.0 can handle manifests and
modules, but not how many people spread them out and also cannot handle
config_version. 3.6.0 will be able to handle all of the various ways that
modules and manifests get spread out (using environment.conf from PUP-1596)
as well as config_version.


>  - modules: this is were I store generic modules
>  - services: this is site-specific modules
>  - forge: modules I have downloaded from the Puppet Forge
>
> The services area is an idea I got from <
> http://projects.puppetlabs.com/projects/1/wiki/Puppet_Best_Practice2>.
> It is perhaps not as useful today as it once was, since we have hiera
> today. But I suspect I am not alone in
> having several areas of modules.
>
> Personally, I like having modules I got from external sourced separated
> from modules I have
> written myself. It makes it easier to know what I need to upgrade and what
> I need to take
> full responsibility for myself.
>
> My understanding is that with Directory Environments I'm restricted to a
> single area.
> Given that this breaks with a "Puppet Best Practice" document I think this
> is a
> severe restriction. (I hope I will be able to use multiple areas in the
> future as well.)
>
> For reference, this is how I set up my modulepath now, after having made
> changes so
> that my setup works with Puppet 3.5.0:
>
> [master]
>
> modulepath=/etc/puppet/environs/$environment/modules:/etc/puppet/environs/$environment/services:/etc/puppet/environs/$environment/forge
> manifest=/etc/puppet/environs/$environment/manifests/
>
> Yours,
> /ceder
>
> Dustin
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Puppet Developers" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to puppet-dev+...@googlegroups.com.
>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/puppet-dev/CAJtE5vQVZrovWuNsQ%3DWCzsOM0O0xMpS_Owp%2BpzM_FtdK-AXXOA%40mail.gmail.com
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>>
>> --
>> Andrew Parker
>> a...@puppetlabs.com
>> Freenode: zaphod42
>> Twitter: @aparker42
>> Software Developer
>>
>> *Join us at PuppetConf 2014, September 23-24 in San Francisco - 
>> **http://puppetconf.com
>> *
>>
>  --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/7db42ac7-fcd6-4e77-8ba0-2fbf911a2ac5%40googlegroups.com
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Andrew Parker
a...@puppetlabs.com
Freenode: zaphod42
Twitter: @aparker42
Software Developer

*Join us at PuppetConf 2014, September 23-24 in San Francisco -
**http://puppetconf.com
*

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CANhgQXuzbCvGzUFJ-zpr7XLbgZz-ssdu3JXs93OYEoqNOR5%2BMg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet-dev] Re:

[John Bollinger]

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 of the most common ways of setting up dynamic 
> environments.
> Specifically, the original blog post about using "$environment" 
> interpolation
> in puppet.conf showed putting the various pieces of the environments in
> /etc/puppet/environments, which is the same location that I chose as the
> default environmentpath.
>
> Since a number of users had put directories inside that directory, and 
> these
> directories were supposed to represent environments, they appeared to the
> directory environment implementation to *be* directory environments.
> Unfortunately the directories where only part of the full environment and 
> so
> when the directory environment code took over, it produced environment
> configurations within puppet that were incomplete, sometimes in very subtle
> ways.
>
>

What are the key criteria?  Is it essential that old-style dynamic 
environments *automatically* continue to work as they did in earlier Puppet 
releases, for all users?  Do directory environments require a base 
directory exclusively for their own use (e.g. to support their 
enumeration)?  Since directory environments are not yet a complete feature, 
it it essential to include them in this release at all?

If the answers to the last three questions are all "yes", then I think I 
favor a variation on options (1 and 2): give the default environmentpath an 
*empty* default value.  That effectively disables the feature unless a 
nonempty environmentpath is specified in Puppet's configuration.  Document 
that the directory(-ies) specified by that setting, if any, must be 
reserved exclusively for directory environments.

That solution saves adding an explicit feature flag, yet still controls the 
feature in a natural way (that defaults to off for existing configurations).


John

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/87d78bab-86ca-4972-b1ca-27fd724b0eff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

[Ken Barber]

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.environment == $$::environment |>>  # implies
that 'catalog' is an object with subparameters
Myresource <<| Environment == $$::environment |>> # ye old
capitalization like other parts of puppet
Myresource <<| same_environment? |>>   #
short-hand for matching the same environment

ken.

On Wed, Apr 2, 2014 at 4:14 PM, Erik Dalén  wrote:
>
> On 2 April 2014 16:40, Ken Barber  wrote:
>>
>> > I quite like the idea of allowing people to restrict collection based
>> > on environment. That requires a slight tweak to the puppetdb terminus
>> > code, but I don't think it'll be too bad. Erik is correct, though,
>> > that we can't really use "environment" as the search term there
>> > because there are some resources that use "environment" as a parameter
>> > name (like "exec"). :/
>>
>> Does anyone have any suggestions for avoiding this conflict?
>>
>
> As I mentioned, in puppetdbquery I've been thinking about using properties
> prefixed with a dot, so .environment for this and just environment for the
> exec parameter. Not sure how well this would work in Puppet itself though,
> but maybe something similar could be done.
>
> But It would be good if both query methods used the same notation to make
> things simple. So I'm up for ideas regarding puppetdbquery as well.
>
> --
> Erik Dalén
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAAAzDLcK7C8czPd0u3t7tAXQvKGOOdByrWQhQ44XA7g30dHQew%40mail.gmail.com.
>
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CAE4bNTkJy7JdXXvY3J9nmm-sLubk0xuj6c0i6XD30hq%3DqmFU8g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Trevor Vaughan]

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 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.environment == $$::environment |>>  # implies
> that 'catalog' is an object with subparameters
> Myresource <<| Environment == $$::environment |>> # ye old
> capitalization like other parts of puppet
> Myresource <<| same_environment? |>>   #
> short-hand for matching the same environment
>
> ken.
>
> On Wed, Apr 2, 2014 at 4:14 PM, Erik Dalén 
> wrote:
> >
> > On 2 April 2014 16:40, Ken Barber  wrote:
> >>
> >> > I quite like the idea of allowing people to restrict collection based
> >> > on environment. That requires a slight tweak to the puppetdb terminus
> >> > code, but I don't think it'll be too bad. Erik is correct, though,
> >> > that we can't really use "environment" as the search term there
> >> > because there are some resources that use "environment" as a parameter
> >> > name (like "exec"). :/
> >>
> >> Does anyone have any suggestions for avoiding this conflict?
> >>
> >
> > As I mentioned, in puppetdbquery I've been thinking about using
> properties
> > prefixed with a dot, so .environment for this and just environment for
> the
> > exec parameter. Not sure how well this would work in Puppet itself
> though,
> > but maybe something similar could be done.
> >
> > But It would be good if both query methods used the same notation to make
> > things simple. So I'm up for ideas regarding puppetdbquery as well.
> >
> > --
> > Erik Dalén
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Puppet Developers" group.
> > To unsubscribe from this group and stop receiving emails from it, send an
> > email to puppet-dev+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> >
> https://groups.google.com/d/msgid/puppet-dev/CAAAzDLcK7C8czPd0u3t7tAXQvKGOOdByrWQhQ44XA7g30dHQew%40mail.gmail.com
> .
> >
> > For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to puppet-dev+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-dev/CAE4bNTkJy7JdXXvY3J9nmm-sLubk0xuj6c0i6XD30hq%3DqmFU8g%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Trevor Vaughan
Vice President, Onyx Point, Inc
(410) 541-6699
tvaug...@onyxpoint.com

-- This account not approved for unencrypted proprietary information --

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoUtfudw5rgn1J-dOPQrXFQ5hYpuZpjwQG365qemFz6b6g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

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

[Henrik Lindberg]

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 queries.



Myresource <<| _environment == $$::environment |>>   #
alternate to dalen's suggestion


Nah, a NAME, cannot start with _


Myresource <<| catalog.environment == $$::environment |>>  # implies
that 'catalog' is an object with subparameters


Better, still has $$.


Myresource <<| Environment == $$::environment |>> # ye old
capitalization like other parts of puppet


Environment would by general rule be a type, and typically would mean
any Environment. Confusing.


Myresource <<| same_environment? |>>   #
short-hand for matching the same environment


Introduces a name that ends with ?, not supported.

Of the proposals above, the one that introduces catalog.environment is 
closest to what is supportable.


If a query of

Resource <<| Q |>>

means resolve against all environments, then

Environment[production, Myresource] <<| Q | >>

could mean, resolve the query in the given environment.

If we like to have resolution of variables that only exist in the query
that is also an option, like the reference to catalog, but I would like 
that to be $catalog. i.e. inside the spaceship, when a query is 
evaluated it can have access to things that we would like a user to be 
able to reference and access details. The details should be obtained 
using the [] operator since this is what is used for this purpose 
everywhere else.


Other options are to use function calls inside the spaceship. They are 
not supported now as valid in a query and would be unambiguous and easy 
to transform into whatever we want them to mean. These are query 
functions, not general puppet functions.


e.g.

# a given environment
Myresource <<| environment(production) |>>

# current environment
Myresource <<| environment($environment) |>>
Myresource <<| environment() |>>
Myresource <<| environment(default) |>>


Remember that the 3x parser has a very brittle grammar, and we do not 
want to introduce something that will clash with the future parser 
grammar. We especially do not want to mess with terminals.


- henrik



ken.

On Wed, Apr 2, 2014 at 4:14 PM, Erik Dalén  wrote:


On 2 April 2014 16:40, Ken Barber  wrote:



I quite like the idea of allowing people to restrict collection based
on environment. That requires a slight tweak to the puppetdb terminus
code, but I don't think it'll be too bad. Erik is correct, though,
that we can't really use "environment" as the search term there
because there are some resources that use "environment" as a parameter
name (like "exec"). :/


Does anyone have any suggestions for avoiding this conflict?



As I mentioned, in puppetdbquery I've been thinking about using properties
prefixed with a dot, so .environment for this and just environment for the
exec parameter. Not sure how well this would work in Puppet itself though,
but maybe something similar could be done.

But It would be good if both query methods used the same notation to make
things simple. So I'm up for ideas regarding puppetdbquery as well.

--
Erik Dalén

--
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-dev/CAAAzDLcK7C8czPd0u3t7tAXQvKGOOdByrWQhQ44XA7g30dHQew%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.




--
You received this message because you are subscribed to the Google Groups "Puppet 
Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/53434B53.2060807%40cloudsmith.com.
For more options, visit https://groups.google.com/d/optout.

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

[Nan Liu]

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 |>>   #
> alternate to dalen's suggestion
> Myresource <<| catalog.environment == $$::environment |>>  # implies
> that 'catalog' is an object with subparameters
> Myresource <<| Environment == $$::environment |>> # ye old
> capitalization like other parts of puppet
> Myresource <<| same_environment? |>>   #
> short-hand for matching the same environment
>

Could we use the current $setting::environment? Also does agent v.s. master
environment throw a wrench in this discussion?

Nan

-- 
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-dev+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-dev/CACqVBqBUR9SSjRN8ryf9WGb1uR5GSSeXKaOEFis%2BoOfMwji2ug%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.