As usual, comments are inline.

Cheers,
--Jorge

From: Eugene Nikanorov <enikano...@mirantis.com<mailto:enikano...@mirantis.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Thursday, May 1, 2014 3:10 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
<openstack-dev@lists.openstack.org<mailto:openstack-dev@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.miramon...@rackspace.com<mailto:jorge.miramon...@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.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to