Open Stack

On 09/01/15 08:06, Maru Newby wrote:
> 
>> On Jan 8, 2015, at 3:54 PM, Sean Dague <sean at 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