Luke Kanies wrote:
> On Mar 19, 2009, at 9:52 PM, Sam Rowe wrote:
> 
>> On Wed, Mar 18, 2009 at 1:16 PM, Luke Kanies <l...@madstop.com> wrote:
>>> Hi all,
>>>
>>> As mentioned in an email yesterday, I'm working with someone to add a
>>> queueing service to Puppet so that some server-side operations are
>>> queued and executed as cpu time is available - generally those that
>>> aren't on the critical path but particularly the storeconfigs save
>>> operation.
>>>
>>> The goal here is that the client wouldn't have to wait for the server
>>> to finish storing the catalog before it got its copy of the catalog;
>>> instead, the server would just put the catalog into the queue, and a
>>> queue reader would come behind and process as time was available.   
>>> The
>>> only other operation I can think of where this makes sense right now
>>> is reporting, but I expect we'll have others over time.
>> Would this help with the splay problem we discussed recently?
> 
> The queueing would only help with reducing client contention when the  
> contention was caused by StoreConfigs, unfortunately.
> 
> Although...
> 
> I could see having a ping-back model, where a client sends a request  
> for a compilation but then just sleeps, and when the config is  
> compiled the server pushes the configuration to the client.
> 
> This is obviously a far cry from the current architecture, but it's  
> mostly a reconfiguration, once you have the queueing, rather than a  
> fundamental shift.

I'm a newcomer, so feel free to ignore me.  But, if RESTful design has
become an increasingly important consideration in interactions between
client and server (and it's my impression that it has), I think you
might find that it fits better in this case to:
* have the server issue a 202 Accepted response, with an response entity
containing: possibly a URL to periodically check for results; possibly
an estimate of time before the new resource is available
* have the client periodically consult the relevant URL until the data
is available

It's somewhat annoying to consider the possibility of having a client
repeatedly, possibly fruitlessly, checking in with a server.  But it may
be easier to scale that approach and fit it within the current
architecture than having bidirectional data flow of the sort described.

Thanks.
- Ethan
-- 
Ethan Rowe
End Point Corporation
et...@endpoint.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Puppet Developers" group.
To post to this group, send email to puppet-dev@googlegroups.com
To unsubscribe from this group, send email to 
puppet-dev+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/puppet-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to