Open Stack

As usual, comments are inline.

Cheers,
--Jorge

From: Eugene Nikanorov <enikanorov at mirantis.com<mailto:enikanorov at mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Thursday, May 1, 2014 3:10 PM
To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Thoughts on current process

Hi,


On Thu, May 1, 2014 at 10:46 PM, Jorge Miramontes <jorge.miramontes at rackspace.com<mailto:jorge.miramontes at rackspace.com>> wrote:
Hey Eugene,

I think there is a misunderstanding on what iterative development means to you and me and I want to make sure we are on the same page. First of all, I'll try not to use the term "duct-taping" even though it's a widely used term in the industry.
I'm not against the term itself.
It was applied several times to existing code base, apparently without ANY real code analysis.
That's especially clearly seen because all API proposals so far are focusing on managing the same set of lb primitives.
Yes, the proposals introduce some new primitives; yes some attributes and relationships differ from what is in the code.
But nothing was proposed so far that would require to completely throw away existing code, not a single requirement.

I understand that writing something from scratch can be more convenient for developers than studying existing code, but that's something we all have to do when working on opensource project.

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. I like to see defining a spec as similar to defining an RFC. The reason why I don't even want to think about implementation is that it does not allow discussion to be open-minded. I agree that a particular API proposal might be easier to mold existing code to than another. However, this goes against the mentality of comparing on equal footing. You, for example, seem biased toward Stephen's proposal because you understand the current code base the best (since you wrote the majority of it) and see his proposal as most inline with said code. However, I ask that you try not to let current implementation cloud your judgement. If Stephen's proposal is what the community agrees upon then great! All I ask is that we compare fairly and without implementation in mind since we are defining what we want, not what we currently have in place. Once an API specification is agreed upon, then and only then, should we figure out how to mold the existing implementation towards the state the spec defines. Does that make sense?


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.


is that some requirement implemented 6 months from now may change code architecture. Since we know we want to meet all requirements eventually, its makes logical sense to design for what we know we need and then figure out how to iteratively implement code over time.
That was initially done on Icehouse summit, and we just had to reiterate the discussion for new subteam members who has joined recently.
I agree that "to design for what we know we need", but the primary option should be to continue existing work and analyse it to find gaps, that what Samuel and me were focusing on. Stephen's proposal also goes along this idea because everything in his doc can be implemented gradually starting from existing code.

That being said, if it makes sense to use existing code first then fine. In fact, I am a fan of trying manipulate as little code as possible unless we absolutely have to. I just want to be a smart developer and design knowing I will eventually have to implement something. Not keeping things in mind can be dangerous.
I fully agree and that's well understood.

In short, I want to avoid having to perform multiple code refactors if possible and design upfront with the list of requirements the community has spent time fleshing out.

Also, it seems like you have some implicit developer requirements that I'd like written somewhere. This may ease confusion as well. For example, you stated "Consistency is important". A clear definition in the form of a developer requirement would be nice so that the community understands your expectations.
It might be a bit difficult to formalize. So you know, we're not the only ones who will make decisions on the implementation.
There is a core team, who mostly out of lbaas discussions right now (and that fact will not change), who have their own views on how neutron API should look like, what is allowed and what is not. To get a sense of it, one really needs to contribute to neutron: push the code through 10-20-50 review iterations, see what other developers are concerned about.
Obviously we can't get everyone to our discussions, but other core dev may (or may not, i don't know for sure) just -1 your implementation because you to /object1/id/object2/id/object3/id instead of flat rest API that neutron has, or something like that.
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.



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.


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