On 09/01/15 08:06, Maru Newby wrote: > >> On Jan 8, 2015, at 3:54 PM, Sean Dague <s...@dague.net> wrote: >> >> On 01/08/2015 06:41 PM, Maru Newby wrote: >>> As per a recent exchange on #openstack-neutron, I’ve been asked to present >>> my views on this effort. What follows is in no way intended to detract >>> from the hard work and dedication of those undertaking it, but I think that >>> their energy could be better spent. >>> >>> At nova’s juno mid-cycle in July, there was a discussion about deprecating >>> nova-network. Most of the work-items on the TC’s gap analysis [1] had been >>> covered off, with one notable exception: Gap 6, the requirement to provide >>> a migration plan between nova-network and neutron, had stalled over >>> questions of implementation strategy. >>> >>> In my recollection of the conversation that followed, broad consensus was >>> reached that the costs of automating a reliable and fault-tolerant >>> migration strategy would be considerable. The technical complexity of >>> targeting a fixed deployment scenario would be challenging enough, and >>> targeting heterogenous scenarios would magnify that complexity many-fold. >>> Given the cost and high risks associated with implementing an automated >>> solution, everyone seemed to agree that it was not worth pursuing. Our >>> understanding was that not pursuing an automated solution could still be in >>> keeping with the TC’s requirements for deprecation, which required that a >>> migration plan be formulated but not that it be automated. Documentation >>> was deemed sufficient, and that was to be the path forward in covering Gap >>> 6. The documentation would allow deployers and operators to devise >>> migration strategies to suit their individual requirements. >>> >>> Then, when the Kilo summit schedule was announced, there was a session >>> scheduled in the nova track for discussing how to implement an automated >>> migration. I only managed to catch the tail end of the session, but the >>> etherpad [2] makes no mention of the rationale for requiring an automated >>> migration in the first place. It was like the discussion at the mid-cycle, >>> and all the talk of the risks outweighing the potential benefits of such an >>> effort, had simply not occurred. >>> >>> So, in the interests of a full and open discussion on this matter, can >>> someone please explain to me why the risks discussed at the mid-cycle were >>> suddenly deemed justifiable, seemingly against all technical rationale? >>> Criticism has been leveled at the neutron project for our supposed inaction >>> in implementing an automated solution, and I don’t think I’m the only one >>> who is concerned that this is an unreasonable requirement imposed without >>> due consideration to the risks involved. Yes, most of us want to see >>> nova-network deprecated, but why is the lack of migration automation >>> blocking that? An automated migration was not a requirement in the TC’s >>> original assessment of the preconditions for deprecation. I think that if >>> neutron is deemed to be of sufficiently high quality that it can serve as >>> an effective replacement for nova-network, and we can document a migration >>> plan between them, then deprecation should proceed. >>> >>> >>> Maru >> >> The crux of it comes from the fact that the operator voice (especially >> those folks with large nova-network deploys) wasn't represented there. >> Once we got back from the mid-cycle and brought it to the list, there >> was some very understandable push back on deprecating without a >> migration plan. > > I think it’s clear that a migration plan is required. An automated > migration, not so much. > >> >> I believe we landed at the need for the common case, flat multi host >> networking, to be migrated to something equivalent in neutron land >> (dvr?). And it needs to be something that Metacloud and CERN can get >> behind, as they represent 2 very large nova-network deploys (and have >> reasonably well defined down time allowances for this). >> >> This doesn't have to be automation for all cases, but we need to support >> a happy path from one to the other that's repeatable, reasonably >> automatic (as much as possible), and provides minimum down time for >> guests running on the environment. > > The fact that operators running nova-network would like the upstream > community to pay for implementing an automated migration solution for them is > hardly surprising. It is less clear to me that implementing such a solution, > with all the attendant cost and risks, should take priority over efforts that > benefit a broader swath of the community. Are the operators in question so > strapped for resources that they are not able to automate their migrations > themselves, provided a sufficiently detailed plan to do so?
Maru, This effort does benefit a broad swath of the community. Regards, Tom _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
