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 <erik.gustav.da...@gmail.com> wrote:
On 2 April 2014 16:40, Ken Barber <k...@puppetlabs.com> 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.
