Open Stack

Hi Jorge,

A couple of inline comments:

>
> Now that we have a set of requirements the next question to ask is, "How
> doe we prioritize requirements so that we can start designing and
> implementing them"?

Prioritization basically means that we want to support everything and only
choose what is
more important right now and what is less important and can be implemented
later.

Assuming requirements are prioritized (which as of today we have a pretty
> good idea of these priorities) the next step is to design before laying
> down any actual code.

That's true. I'd only would like to notice that there were actually a road
map and requirements
with design before the code was written, that's both for the features that
are already implemented,
and those which now are hanging in limbo.

I agree with Samuel that pushing the cart before the
> horse is a bad idea in this case (and it usually is the case in software
> development), especially since we have a pretty clear idea on what we need
> to be designing for. I understand that the current code base has been
> worked on by many individuals and the work done thus far is the reason why
> so many new faces are getting involved. However, we now have a completely
> updated set of requirements that the community has put together and trying
> to fit the requirements to existing code may or may not work.



> In my experience, I would argue that 99% of the time duct-taping existing
> code
>
I really don't like the term "duct-taping" here.
Here's the problem: you'll never will be able to implement everything at
once, you have to do it incrementally.
That's how ecosystem works.
Each step can be then considered as 'duct-taping' because each state you're
getting to
is not accounting for everything what was planned.
And for sure, there will be design mistakes that need to be fixed.
In the end there will be another cloud provider with another set of
requirements...

So in order to deal with that in a productive way there are a few
guidelines:
1) follow the style of ecosystem. Consistency is important. Keeping the
style helps both developers, reviewers and users of the product.
2) Preserve backward compatibility whenever possible.
That's a very important point which however can be 'relaxed' if existing
code base is completely unable to evolve to support new requirements.


> to fit in new requirements results in buggy software. That being said, I
> usually don't like to rebuild a project from scratch. If I can I try to
> refactor as much as possible first. However, in this case we have a
> particular set of requirements that changes the game. Particularly,
> operator requirements have not been given the attention they deserve.
>
Operator requirements really don't change the game here.
You're right that operator requirements were not given the attention.
It's not because developers of lbaas have not thought about it, it's
because we were limited in dev and core reviewing
resources, so implement
But what is more important, operator requirements mostly doesn't affect
tenant API that we were discussing.
That's true that almost none of them are addressed by existing code base,
but it only means that it should be implemented.

When talking about existing code base I'd expect the following questions
before any decision is made:

1) how can we do (implement) X with existing code base?
2) if we can't do X, is it possible to fix the code in a simple way and
just implement X on top of existing?

If both answers are "No", and X is really impossible with existing code
base - that could be a reason to deeply revise it.
Looking at operator requirements I don't see a single one that could lead
to that.

Because several of us have been spending large amounts of time on API
> proposals, and because we can safely assume that most operational
> requirements are abstracted into the driver layer I say we continue the
> conversation around the different proposals since this is the area we
> definitely need consensus on. So far there are three proposals--Stephen's,
> Rackspace's and Eugene's.

I'd like to comment that my proposal is actually a small part of Stephen's
that touches the core lbaas API only.
So i would not treat it separately in this context.

Thanks,
Eugene.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140501/cfbfcb40/attachment.html>