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. > 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 :-) 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? 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. Let's see if I can come up with something soon, -- Brice Figureau My Blog: http://www.masterzen.fr/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
