On Jul 7, 2009, at 11:37 AM, Brice Figureau wrote:
>
> On 5/07/09 3:16, Luke Kanies wrote:
>> On Jul 4, 2009, at 9:48 AM, Brice Figureau wrote:
>>
>>> The issue is that when we convert Puppet::Parser::Resource catalog
>>> to a Puppet::Resource catalog before storing it to the database,
>>> we don't allow virtual resource to be converted.
>>> Unfortunately exported resources are virtual by design, and as
>>> such aren't converted, and we lose them, so it isn't possible
>>> to store them in the database.
>>> Unfortunately, the client will get the exported resources too.
>>> So we filter out them when this catalog is converted to the RAL
>>> catalog, client-side.
>>
>> It feels kind of like we're peeling an onion here, like exported
>> resources and the Indirector model are incompatible.
>>
>> It's even worse with the queueing thrown in, because we could
>> otherwise filter out at serialization (although that would only work
>> with client/server).
>
> I don't see how we could filter at serialization without violating the
> responsibility of each classes (the only way I see this is to add a
> filter method in the indirector which the serialization layer could
> call, but that feel kludgey).
>
> And if we serialize in the return of Catalog::Compiler#find then we're
> back to square 0, because we'll save the catalog without any exported
> resources.
Yep.
>
>> In other words, this is a bit ugly, but no uglier than the system
>> already was.
>>
>> The only way I can see better than this, and that's questionable, is
>> to have the whole system support virtual resources, and have the
>> transaction skip them. The client's already getting those exported/
>> virtual resources, so you might as well keep them through the whole
>> chain, and then at least the model's clean and data's not getting
>> destroyed at weird, arbitrary times.
>
> That's what I tried, filtering at Transaction#apply. This works, of
> course, but it doesn't feel any better than my first version :-)
There's even a 'skip?' method you can use for this; just add the bit
that skips virtual resources.
>
> The question is that until now we weren't sending virtual resources,
> because for a reason there is really no need to do that, and we never
> store them in the database. But you seem to say that for
> generalization
> we should?
Well, more 'might have to' than 'should'.
>
> On 6/07/09 19:08, Luke Kanies privately wrote to me:
>> If we're concerned about the client getting data it shouldn't, we can
>> add trimming to the catalog rest terminus and the xmlrpc master
>> handler to remove virtual or exported resources, but standalone
>> puppet
>> will still need the transaction to skip them.
>
>
> I'm concerned with two things:
> * sending unneeded material to the client
> * the client seeing this unneeded material
>
> Filtering out at the REST terminus would solve only the second case,
> because if I got it correctly the REST terminus is client side. Or
> maybe
> you meant something else?
>
> Really the only solution I can think of is:
> * filter out at the transaction (which would be the ultimate
> safeguard)
> * add a filter indirection model method, which would be routed for
> the
> catalog to Catalog#filter which would remove the exported resources.
>
> And catalog filter is not much more than a special catalog conversion.
You seem to have nailed it, and I don't see a better solution at the
moment. I look forward to seeing what you come up with. :)
--
A Chemical Limerick:
A mosquito cried out in pain:
"A chemist has poisoned my brain!"
The cause of his sorrow
was para-dichloro
diphenyltrichloroethane
-- Dr. D. D. Perrin
---------------------------------------------------------------------
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
-~----------~----~----~----~------~----~------~--~---
