Open Stack

Hi,

A couple of comments:


>  To be perfectly clear we are not advocating "starting from scratch". If
> it has come out that way then let me be the first to correct that on behalf
> of my team. In reality, defining a brand new API specification is
> irrelevant to implementation.
>
Probably that's what I personally can't agree with: "defining brand new
API". API is the most rigid part of the system. Redefining it completely
renders most of the rest parts obsolete. Btw, there is a code outside LBaaS
(vmware service plugin) that was built using LBaaS API.
Funnily, the problem with current API is that it was initially made similar
to Atlas where single pool per LB is assumed. That's a quite small, but
nasty issue that needs to be fixed to allow to go with most of new
requirements.
It was well-understood that existing API is limiting further development,
but bw-compatible evolution was always kept in mind.
And btw I would not call L7, SSL, operator's part of API a "brand new" even
if these are completely new parts; that is an extension of existing, not a
redefinition.

>   My main concern is that implementing code on top of the current
>> codebase to meet the smorgasbord of new requirements without thinking about
>> overall design (since we know we will eventually want all the requirements
>> satisfied at some point per your words)
>>
> Overall design was thought out long before we started having all these
> discussions.
> And things are not quick in neutron project, that's regardless of amount
> of dev resources lbaas subteam may have.
>
>
>  While overall design may have been thought out long ago it doesn't mean
> that the discussion should be closed. By saying this, you are implying that
> newcomers are not welcome those discussions. At least, that is how your
> statement rubs off on me. I'll give you the benefit of the doubt to correct
> my understanding of that.
>
Well, by saying 'without thinking about overall design' one might
understand that you assume that such thinking was not done so far. So I
just meant that we have been thinking of overall design, so it would be
incorrect to say that existing code base was the blind implementation
swinging towards nowhere.
The opinion of "newcomers" is definitely welcomed, especially about
requirements and use cases.


>
>
>> Then you'll probably spend another month or two trying to discuss these
> issues again with other group of folks.
> We don't have rigid guidelines on how the code should be written;
> understanding of that comes with experience and with discussions on gerrit.
>
>
>  The fact that there are no core developers on Neutron LBaaS is
> concerning to say the least even though there are a large number of
> people/companies now involved. I have other thoughts on this but will leave
> that for another day.
>
It's not exactly that. It's an already formed developer community with
their views and opinions; you can't just say to anyone 'if you don't
discuss lbaas - don't review the lbaas code', right?

  Lastly, in relation to operator requirements I didn't see you comment on
>> whether you are fan of working on an open-source driver together. Just so
>> you know, operator requirements are very important for us and I honestly
>> don't see how we can use any current driver without major modifications.
>> This leads me to want to create a new driver with operator requirements
>> being central to the design.
>>
> The driver itself, IMO, is the most flexible part of the system. If you
> think it needs to be improved or even rewritten (once it does what user
> asks it to do via API) - I'd be glad to discuss that. I think rm_work (is
> that Adam Harwell?) was going to start a thread on this in ML.
>
>  Btw, am my understanding is correct that you (as cloud operator) are
> mostly interested in haproxy as a backend?
>
>
>  Correct. We are mostly interested in using a pure open-source backend.
> HAProxy is definitely where we will be starting.
>
Good. I'm looking forward to see what fundamental issues you see with
haproxy driver.

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