> 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?


OpenStack-dev mailing list

Reply via email to