openstack team mailing list archive

[Michael Gundlach <michael.gundlach@xxxxxxxxxxxxx>]

On Tue, Aug 3, 2010 at 1:18 PM, Eric Day <eday@xxxxxxxxxxxx> wrote:

> >     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.
>
> I suggest only making it longer when it is necessary, don't require
> components to span multiple layers. Having all services as modules
> will will make it trivial to split layers as we need. I see splitting
> things into a longer chain as a pre-optimization, and in some cases
> not an optimization at all. For example, the overhead of splitting
> out a proxy layer for something like rate limiting may not make
> sense. The overhead of the proxy (two extra sockets, buffer copying,
> ...) is fairly expensive compared to just having the check in the API
> endpoint directly (consulting a shared data store for current limit
> and increment current request type).
>

It's a trade-off -- there is the overhead of extra sockets, copying, network
bandwidth; but there is the benefit of the API endpoint having less code in
it, less complexity, fewer variables in the same scope.  If you need to fix
a rate limiting bug and I need to fix an API endpoint bug, we can work on
completely separate pieces of code.  I think we're just seeing different
sides of the trade-off as more important.  Luckiy, I think you just said in
#openstack that WSGI meets your needs, so this may be a moot point :)


> In the .png, imagine the separate boxes inside the API Endpoint
> box that represents the different steps, not as a single blob. :)
> I understand your concern about keeping the layers separate, and I
> completely agree we don't want any spaghetti code/arch coming out of
> this. I think place where we don't align yet is how these layers talk
> to each other.
>
> Thinking of the request as a state machine and a series of
> transformations, I think we all agree that the states need to
>

Ah hah!  That does help.  Thanks.

be well defined and each state can depend on external services
> (like auth). Where I see our difference is how we go about the
> transformations from one state to the next. I'm advocating we keep
> this generic, and allow for in-process transformations, where the
> multi-layer proxy example is forcing a HTTP proxy layer for each
> transformation.
>

Hooray again for WSGI solving this problem :)  In-process transformations
that can become HTTP proxies as needed!


> Once we get to load testing we should be able to get a good picture
> on what we need to break out, if anything. We'll want to capture some
> stats on out current production API traffic, see the limits of the
> new system, and go from there.
>

Sounds good.


> >    Hope this helped and didn't muddy the waters,
>
> It did, thanks for helping break things down! I think we're about on
> the same page now, I'm going to go look at how WSGI layers can stack
> to see if that is a good fit. :)
>

Great :)

Michael