On Mar 19, 2009, at 10:06 PM, Ethan Rowe wrote:
>
> 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.
You're right - that's much simpler, doesn't require the ability to
contact the client, and is low-cost.
Good point; thanks.
--
You don't learn anything the second time you're kicked by a mule.
-- Anonymous Texan
---------------------------------------------------------------------
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 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
-~----------~----~----~----~------~----~------~--~---
