> 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  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  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 _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev