On Oct 4, 2010, at 2:24 AM, Aurelien Degremont wrote:
> Luke Kanies a écrit :
>> I completely agree that there should continue to be REST support. My
>> question is whether there's significant value to keeping REST as the primary
>> communication mechanism, and if so, what is it?
>
> I totally agree with Jeff McCune regarding REST.
>
> I can imagine implementing a fileserver only using Apache with url
> redirection and SSL feature (only environment could be a bit tricky) and so
> benefits from Apache features and scalability. This could not be possible if
> Puppet has its own protocol.
Puppet wouldn't really have its own protocol; we'd be running on AMQP, STOMP,
or something similar. I think it would largely be configurable, so if you
wanted to do your file serving over HTTP you still could, but file serving is
kind of the odd man out - of the main conversations between client and server
(uploading facts, downloading catalog, downloading files, uploading report),
it's the only one that really needs to be synchronous. Everything could and
probably should be async (e.g., if report uploading fails, it should keep
trying until it works, but it currently just loses the report).
This could all be done with HTTP, but it's far more complicated, and is
actually built into the protocol for the message buses.
> Moreover Puppet needs stability. I do not imagine that after moving from
> XMLRPC to REST, you will switch again to something else.
I agree this is one of the big challenges. However, the big cost in moving to
REST was not the HTTP portion, it was the infrastructure that allowed network
transparency and pluggability, and I think we've shown internally (and to some
extent discussed in my later posts last week) that the existing Indirector code
can be transparently applied to using message buses.
I'm obviously concerned about stability, but in some ways I'm more concerned
about having a solution that scales in the way our users require. There are
fundamental limitations to the point-to-point RPC model, and Puppet is often
running into them. We can continue to scrape gains out of the system, but I
think directly supporting some kind of async model would pay huge dividends in
scalability, simplicity, auditibility, and much more, without a lot of actual
cost.
However, I don't really know that yet. Paul Berry and Jesse Wolfe are looking
into that this week, and will hopefully have a more fleshed out idea of what
this change will take and how expensive it will be.
--
If you would be a real seeker after truth, it is necessary that at
least once in your life you doubt, as far as possible, all things.
-- Rene Descartes
---------------------------------------------------------------------
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
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.
