On Oct 18, 2008, at 7:40 AM, Brice Figureau wrote:
>
> On 17/10/08 18:18, Luke Kanies wrote:
>>
>>
>> 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.
>
> Oh, I thought virtual resources were invented before exported
> resource.
> I've always seen exported resources as a kind of virtual resources...
They are related, but exported resources came first. Which is to say,
resources in a database came first, so I needed a syntax to both store
and collect them.
>> 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?
>
> If the syntax changes to something different, then the meaning should
> change. If we keep the current syntax, then the meaning should be
> the same.
Always a laudable goal; hopefully it can be met.
[...]
> I didn't think too much about it yet.
> I'm throwing this out of my head without thinking about it, so
> please be
> indulgeant.
>
> Basically right now:
> * Resource[title] is representing a completely determined collection
> of 1 resource from the catalog.
>
> * Resource<| query |> is representing a collection of virtual
> resources
>
> * Resource<<| query |>> is a collection of imported resources
>
> All these syntax can be overriden by adding an "override block".
A succinct summary.
>
> It should be possible to "merge" all this in the same unified syntax.
>
> We could have a syntax that means "collection" as a new puppet type.
> We could even store a collection in a puppet variable.
> If the result of the collection is "not used" (ie a statement
> instead of
> a rvalue), then it means "realize/import/override"
If we store a collection in a variable, does that mean it doesn't get
evaluated? If we do so, does that mean we can do things like:
$variable { foo => bar }
Is there a difference in what the collection does (other than,
obviously, the override) between a collection with and without an
override? I.e., if we wanted to collect virtual resources, realize
them, and override them, would it take two collections (one to
realize, one to override)? I think I know the answer, based on the
text below, but figured I'd ask.
If we have a query with no source (or @ symbols) and no override, what
does it mean? Is it a language warning?
>
> Let's say we have a language structure that "builds" a collection. We
> have to say
> * where this collection comes (catalog, external source of any kind,
> virtual)
> * selecting/filtering query
> * any override
>
> Maybe we can introduce a new keyword?
> collect<Resource>(source)[query] { override }
>
> Or maybe write it simply like this:
> Resource(source)[query] { override }
>
> I always thought the <| |> and <<| |>> syntax was not fitting
> perfectly
> in the puppet language, hence my proposal to have the query in [] to
> match the Resource[title] syntax.
> When the query is a simple string, then it would be expanded as "title
> == string" which maps back to the current "resource selection".
I disagree with the <||> syntax not being awesome, but I'm apparently
the only person who thinks that.
But yes, I've also thought that the Resource["title"] syntax could be
equivalent to Resource[title == "title"].
That would get a bit hard to parse, I think, since I'm pretty sure the
title can be any rvalue, and supporting either an rvalue by itself or
a full query syntax might be a touch hard.
>
> The source can be either:
> * empty -> means catalog, and we're back to the simpler syntax
> * catalog, same as empty
> * virtual
> * any defined external source coming from puppet.conf, with the only
> known type at this stage is active_record or storeconfigs. The
> puppet.conf syntax should be specified too.
>
> Since it might be cumbersome to add the source everywhere, we could
> have
> shorter syntax (see below).
>
> There's no need to change the override syntax which is clear and
> understandable and works fine.
>
> So to summarize, here's how I see it:
>
> * Catalog resources:
>
> Resource[query] { override }
>
> Ex:
> File["/tmp/test"] { mode => 0666 }
> or
> User[ uid == 1000 ] { groups => staff }
> or
> User(catalog)[ uid == 1000 ] { groups => staff }
This seems fine, except maybe that last bit. Puppet's language
doesn't have any concept of keywords like 'catalog', and I'm a bit
uncomfortable with the function-like syntax. I don't know what else
to suggest for it, but those two things make me hesitate.
>
> * Virtual resources
>
> Resource(virtual)[query] { override }
>
> Ex:
> File(virtual)["/tmp/test"] { override }
> or
> File(virtual)[ tag == test ] { override }
>
> We can have a short syntax for virtual:
> @File[ query ] { override }
>
> or in its simplest form:
> @File
Interesting idea -- reusing the @ signs for virtual/exported for the
collections too -- I like that. I'm not totally against the (virtual)
syntax, but...
>
> Used alone, it means "realize"
> It should also be possible to write:
>
> $collection = @File
> realize( $collection )
> to achieve the same thing
Interesting; ok.
>
> * Exported resources
>
> File(storedconfigs)[ tag == test ] { override }
>
> if we one day have more than one external source.
> Let's say, I have an ldap source of resource defined in my
> puppet.conf, ala:
>
> [mysource]
> sourcetype = ldap
> ldaphost= localhost
>
> Then I could use the following in my manifests:
>
> File(mysource)[ tag == test ] { override }
puppet.conf doesn't currently supporting having this kind of named
collection of parameters -- the sections are for environments and
nothing else, at this point. I'm not sure how easily I could add one,
either.
>
> And for storeconfigs, we can have a shorter syntax:
> @@File[ query ] {override}
>
> or, in its simplest form:
> @@File
>
> which means all resources of type File that are exported in
> storeconfigs.
Wouldn't this find all exported resources, and, um, do nothing with
them?
Or are you suggesting that the query syntaxes could be used to export/
virtualize resources?
>
> Comments, and flames accepted :-)
>
>> 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).
>
> OK, so instead of acting only on virtual resources, we scan both
> virtual
> resources and catalog resources, select them, override them
> accordingly
> and if we ever encounter one that is virtual, we realize it.
> Is it right?
Yeah, that's what I was recommending.
>
>> 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.
>
> I'll try to assess this later this week. But I think
> evaluate_generators
> will still be used by storeconfigs resources, right?
Every collection would be evaluated in the evaluate_generators method,
and any overrides would need to end up in the fail_on_unevaluated
method (although I'm not exactly sure if it's even necessary for
overrides related to collections -- I suppose the overrides would
happen when the collections are evaluated).
--
Due to circumstances beyond your control, you are master of your fate
and captain of your soul.
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
