On Oct 1, 2010, at 5:41 PM, Jeff McCune wrote: > On Oct 1, 2010, at 4:01 PM, Luke Kanies wrote: > >> On Oct 1, 2010, at 10:19 AM, Jeff McCune wrote: >> >>> On Tue, Sep 28, 2010 at 6:08 AM, R.I.Pienaar <[email protected]> wrote: >>>> Why do you consider REST preferable? We were talking about this last night >>>> and I don't really see the advantage, we'd still have a REST server option >>>> for smaller clients but I think for a big setup just avoid the HTTP. >>> >>> There are tons advantages I see to REST. >>> >>> We don't have to re-invent the wheel with REST. It's proven to work >>> and to scale at a transport level. We get a lot of things "for free" >>> with HTTP and REST including our choice of server, load balancers, SSL >>> terminators, rewrite engines, inspection tools, testing tools, etc... >>> >>> We should also avoid having two different transport protocols for >>> smaller clients and big setups. It's just more stuff to maintain. >>> >>> The puppet audience largely understands and has faith in HTTP. If >>> need be, they don't need to learn another protocol to dive in and >>> debug things with tcpdump and wireshark. >> >> 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 think so. Anything that is inter process communication would provide the > value I mentioned above to the end users if the IPC calls are implemented > over REST. > > Particularly when it comes to debugging, keeping track of state, scaling the > service, and leveraging existing HTTP tooling and infrastructure. There's > also widespread SSL support and well understood architecture designs that > allow SSL offloading while passing through authentication tokens, much like > we currently do with the certificate DN and verification status.
I think you'd find that a bus would actually be *far* easier to debug than HTTP, because it can track both ends of the conversation much more easily. Ask RI about the auditing capabilities of mcollective, and compare that to what we have now, especially as you get a pool of HTTP responders behind a load balancer - you have to audit the client, load balancer, and every server. This might seem easy because you're used to it, but I think it's actually a big stumbling block for people. > I think SSL and REST has been a huge win in puppet and there should be a very > compelling argument to switch the primary communication mechanism to > something else. At this point, the compellin argument is that you could get one drop-in technology that would (at least, according to what I've seen, but not yet tested) scale pretty easily both up and out - it could handle the largest network I've seen, but also handle multiple locations very easily. These are both very difficult in the existing HTTP infrastructure, and message buses were essentially invented to solve this problem and they do it well. > I don't think using REST as the primary communication mechanism is mutually > exclusive with employing a bus, though perhaps I misunderstand the design. > If we implement a bus, couldn't all of the puppet processes involved talk to > that bus over REST? Essentially, no - the bus protocols are very different from HTTP. I mean, you could have a listener that translated HTTP calls and responses to the bus and back, but then the client's still speaking HTTP and only the server-side uses the bus. I still don't have enough clarity on what the trade-offs are here, but at the least, it would limit us to existing Puppet functionality and we couldn't add any of the capabilities that mcollective, for example, has, such as real-time introspection and triggering fact uploads. It also means that anyone employing a bus needs both a scalable HTTP infrastructure (although one that doesn't need to scale nearly as well) and a scalable messaging infrastructure, which seems a bit silly. -- Never regret. If it's good, it's wonderful. If it's bad, it's experience. -- Victoria Holt --------------------------------------------------------------------- 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.
