openstack team mailing list archive

[Michael Gundlach <michael.gundlach@xxxxxxxxxxxxx>]

Howdy Eric,

On Mon, Aug 2, 2010 at 6:57 PM, Eric Day <eday@xxxxxxxxxxxx> wrote:

> Hi Jorge,
>
> I think we may not be on the same page here.


But I think we're getting close :)  All three of us have slightly different
approaches in mind, but we're narrowing down the areas where we disagree.
 I've tried listing our agreements and disagreements below -- we'll see if
this style is helpful or confusing.


> I can't speak for what
> Michael meant, but this is what I had in mind:
>
> http://oddments.org/tmp/os_module_arch.png
>
> This removes the intermediate proxies and instead relies on the
> scaling out of API endpoint and the services it uses. Different
> services or different parts of the same service could consume the
> same API/service. See my original email for my reasoning, but the
> main ones are to keep the APIs consistent across different parts of
> a service and to reduce the number of hops a request must go through.
>


OK, I think we all agree that it is good that

   - code in the request chain can call out sideways to services
   - we provide language bindings to those services
   - the language bindings talk to services using their normal wire
   protocol, or REST if we write the service ourselves
   - the language bindings allow dropping in different implementations of
   the service, including local mocks for testing
   - it's undesirable to have a lower layer in the request chain have to
   call up to a higher layer to service a request.

Here's where I think we disagree (pardon if I put words in your mouths
incorrectly):

   1. Jorge suggests putting some specific things in the request chain (e.g.
   caching) which you and I would suggest making into services.
   2. Jorge and I would suggest making the request chain longer when
   possible to simplify each part, while you would suggest collapsing it to
   reduce the number of hops.

Let me suggest that #1 isn't really something we need to settle right now:
whether auth, or caching, or rate limiting, or SSL termination is
implemented as a layer in the request chain or as a sideways-called service
can be individually argued when we get to that piece.  I think we're looking
to settle the higher-level shape of the architecture.  #2 is below:


> If we find we do need an extra proxy layer because caching or SSL
> termination becomes too expensive within the endpoints, we can
> easily write a new service layer utilizing the same APIs to provide
> this. It would be nice to keep these proxies optional though, as some
> installations will not require them.


What makes me uncomfortable about http://oddments.org/tmp/os_module_arch.png is
that the "API Endpoint" server is a single rectangle that does multiple
things, when we could instead have it be a chain of 2 or 3 rectangles that
each do a simpler thing.  For example, if there does exist some basic auth*
that can be done on the incoming HTTP request, I would want that teased out
of the API Endpoint and put in front of it as a layer that calls sideways to
the Auth Service.  Now API Endpoint is a little simpler, and we know that
any requests to it have already passed basic auth* checks.  API Endpoint can
of course call out to Auth Service again to do more fine grained auth if
necessary.  As another example, I haven't looked at the code for "Compute
Worker" yet so I really have no idea what it does -- but if it were a stack
of named layers I would be able to grok a piece at a time.

You want to avoid extra hops and extra layers for simpler installations to
have to think about... maybe WSGI is the solution to this that lets us all
meet in the middle.  Build API Endpoint as a stack of as many WSGI servers
as possible, so that each one is as simple as possible.  If it turns out we
never need to scale an individual piece, we have at least broken a larger
problem into smaller ones.  If we do need to scale an individual piece, we
can turn the WSGI app into its own layer and scale independently.  What do
you (Jorge and Eric) think?

Summarized as bullet points, can we agree that

   - large problems should be broken into small problems
   - if a layer of the request chain can have a piece broken into a WSGI
   app, let's do that unless there's a good reason not to
   - by the time we release 1.0, we should figure out which WSGI apps, if
   any, need to become independent proxies for scaling reasons

?  If not, please push back :)

Hope this helped and didn't muddy the waters,
Michael