On Mon, Aug 2, 2010 at 4:31 PM, Jorge Williams <jorge.willi...@rackspace.com > wrote:
> Hmm.. Let me see if I understand what you're saying. Correct me if I'm > wrong here. You're still advocating a proxy approach where an HTTP request > is sent from one proxy to another... (Parton my txt drawings) > * > * > ...but you are proposing that individual proxies can make sideways calls to > make additional service requests... > > If so, that's exactly along the lines of what I was thinking. > Yep. I hadn't argued for putting a cache as its own layer, but I think the bigger picture is the same -- a stack of proxies that can call out sideways. > > * [ SSL Term ] * > * | * > * v * > * +------------>[ Cache ]* > * | |* > * | v* > * | [ Auth ]--->[ IDM SERVICE ]* > * | |* > * | v* > * | [ Rate Limit ]* > * (Purge) |* > * | v* > * | [API Endpoint]* > * | |* > * | v* > * | ...* > * | |* > * | |* > * | |* > * | |* > * +-------------------+* > > > For example, say a user issues a command to delete a server. We'll need to > purge every representation (XML, JSON, XML GZip, JSON GZip) of that server > from the front end cache. I suppose we could detect the delete operation at > the caching stage, but that means having a very customized cache, I'd like > to reuse that code for different APIs. What's more certain events may > trigger cache purges from the backend directly, say a server transition > state from "RESIZE" to "ACTIVE". I really don't see how we can avoid > these downstream communications entirely. > If we made the cache a proxy layer then I would agree that communication would loop upstream again. If we made the cache a service, accessible from any proxy via an API, then we avoid that complexity. So I'd definitely argue for the latter approach for caching (as does Eric). As a counterexample, I'd keep rate limiting as its own layer, since it's needed in one place and isn't called regularly by anyone downstream. Michael
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
