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. 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) 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 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. 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. 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. 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 8:12 AM 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 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.
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
