On Oct 17, 2008, at 9:36 AM, Brice Figureau wrote:
>> [...]
>> The first query will make the resource non-virtual, and I think that
>> means the second query will null-op, which means the override
>> wouldn't
>> happen.
>>
>> Right?
>>
>> As expected, I just ran this code in your 1088 branch, and just the
>> first override took affect.
>
> Yes, you're right.
> Is it something I should change?
> But then, when to mark the resource non virtual anymore?
I, um, really don't know, so let's talk a bit about what the querying
really does.
Initially, the querying syntax was envisioned as a way to find
resources in the database -- exported resources existed long before
virtual resources. When a customer came up with the need for virtual
resources (which, in retrospect, based on tools I'd written before
Puppet, I should have created as part of Puppet's initial design), I
modified the support for exported resources to support virtual
resources as a subset.
The querying for exported resources was viewed as a simplified way to
query a database. When the same querying was reused for virtual
resources, it became a means of interacting with a collection of
resources in memory, restricted to those that were marked virtual.
The question becomes, should this querying be viewed as a means of
interacting with all resources or memory, or should it retains its
current focus on virtual and exported resources?
This is obviously a language design question, and it kind of brings up
the question of whether we should step back a bit and view this whole
querying/overriding a bit more holistically. It might be that we can
simplify the available syntaxes into something that can coherently
cover normal resources, virtual resources, and exported resources.
What we need is:
* Something to find exported resources in an external resource
repository and add them to the current catalog
* Something to find virtual resources in the current catalog and mark
them non-virtual
* Something to find resources in the current catalog and apply overrides
At this point, I'm open to completely new syntaxes to cover all three
of these needs, but I don't have any sudden inspiration myself.
My original method for supporting two query types -- add an additional
set of brackets -- clearly won't work in this case, because it would
just be stupid.
The only real I can think of right now (after, admittedly, not much
thinking about it) is:
* Keep the two similar query syntaxes right now, with this behaviour:
* Resource <| |> operates on resources in the catalog. Any found
resources that happen to be marked virtual will be marked non-virtual,
and all overrides will always be applied.
* Resource <<| |>> operates in resources in external resource
repositories (currently only StoreConfigs). Any found resources will
be added to the local catalog, and all overrides will be applied.
I'd kind of like to find a way to reduce to a single query syntax
(rather than the two forms with different numbers of brackets), but
that would require having the ability to indicate a given query should
operate against a resource repository vs. the local catalog. One of
the reasons I'd like this is that I think we're going to need the
ability to specify which repository to operate against. I can see a
day where you'd have resources scattered around different databases
and applications, and you'd want to integrate Puppet with all of
them. It's reasonable to start with the restriction that Puppet can
only be configured to talk to one of those repositories at once, but
it'd be nice to eventually support connecting to multiple repositories.
All I can think of for this is something like:
Resource(source = active_record) <| foo == bar |>
And that's just horrible. Horrible.
Barring any brilliant ideas from others, I'd say just provide the
behaviour change described above (the local resource query operates
against all resources, and marks virtual resources as non-virtual).
Note that the evaluate_generators method in Parser::Compiler should be
evaluated to make sure its behaviour still makes sense with this
change, along with the 'fail_on_unevaluated' method in the same class.
--
To be pleased with one's limits is a wretched state.
-- Johann Wolfgang von Goethe
---------------------------------------------------------------------
Luke Kanies | http://reductivelabs.com | http://madstop.com
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
