On Mon, Apr 29, 2013 at 3:10 PM, Rob Sherwood <rob.sherwood@...>
I definitely recognize that there is a lot of pressure (from press, developers, even from ourselves) to show that the daylight community can make progress and produce useful code, but I'm not sure that artificially pushing for a final decision on the controllers (one way or another)---especially in this two weeks time frame---is the right way to do it.
It time frames are the problem, those can be adjusted. As I mentioned it is more important that we make progress in a timely fashion than the actual date of this or that (at least until we get to delivery schedules).
It's my read that the vast majority of people (users, developers, even a number of TSC members) are trying to come up to speed with _what a controller is_ and what is it supposed to do, before even starting on the harder question of "which code base is a better controller". More so, while I agree with the rough characterization of your three options ( (i) let two controllers exist indefinitely, (ii) merge the controllers, (iii) vote to pick one), we don't yet even know enough to answer the technical feasibility of these options or which one will net result in the best code.
What I'm asking people (such as Colin and David (E)) to do to look at just this. As Chris pointed out,
during the process we'll want to generate metrics (loosely defined) that will allow us to more objectively evaluate our options (we need this as a community in any event).
For example, Colin Dixon and I have been talking about potentially merging controllers at the SAL level. This would mean in net-virt's perspective that the SAL would look like an application, and from the 'controller' project prospective the net-virt controller would look like a SAL plugin. I think this approach potentially has legs and would solve a lot of problems (and potentially not even be that much work) but we're going to need some time to investigate it.
Last, if we're concerned about being to produce useful code, I would like to submit that working towards some specific user-facing use-case for Q3 (e.g., a full quantum stack with network virtualization support) is a better goal, both from an impact perspective but also because it's less divisive.
What do other people think about this approach to focus on an user-facing deliverable and run the "which controller" question in parallel?
While having other (user-facing) deliverables is goodness (and IMO ultimately where a lot of value will be created) , the problem that I want to solve is to have a stable controller base for such applications to be built on. So it is critical that we sort that out for all the reasons you mention above (and others), and is the problem I intend to address with the process I outlined. In fact, having a stable controller base (including how ever the NB is done, model driven/BigDB/...) would seem to be an obvious prerequisite for the example you cite.
All of that said, if the time frame isn't reasonable (understanding that I was being intentionally aggressive with the two week time frame), let's settle on a reasonable time frame. As I mentioned, making progress is most important but it is also important that we do so in a timely fashion.