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 1: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee/Neutron_Gap_Coverage 2: https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron > On Dec 19, 2014, at 8:59 AM, Anita Kuno <ante...@anteaya.info> wrote: > > Rather than waste your time making excuses let me state where we are and > where I would like to get to, also sharing my thoughts about how you can > get involved if you want to see this happen as badly as I have been told > you do. > > Where we are: > * a great deal of foundation work has been accomplished to achieve > parity with nova-network and neutron to the extent that those involved > are ready for migration plans to be formulated and be put in place > * a summit session happened with notes and intentions[0] > * people took responsibility and promptly got swamped with other > responsibilities > * spec deadlines arose and in neutron's case have passed > * currently a neutron spec [1] is a work in progress (and it needs > significant work still) and a nova spec is required and doesn't have a > first draft or a champion > > Where I would like to get to: > * I need people in addition to Oleg Bondarev to be available to help > come up with ideas and words to describe them to create the specs in a > very short amount of time (Oleg is doing great work and is a fabulous > person, yay Oleg, he just can't do this alone) > * specifically I need a contact on the nova side of this complex > problem, similar to Oleg on the neutron side > * we need to have a way for people involved with this effort to find > each other, talk to each other and track progress > * we need to have representation at both nova and neutron weekly > meetings to communicate status and needs > > We are at K-2 and our current status is insufficient to expect this work > will be accomplished by the end of K-3. I will be championing this work, > in whatever state, so at least it doesn't fall off the map. If you would > like to help this effort please get in contact. I will be thinking of > ways to further this work and will be communicating to those who > identify as affected by these decisions in the most effective methods of > which I am capable. > > Thank you to all who have gotten us as far as well have gotten in this > effort, it has been a long haul and you have all done great work. Let's > keep going and finish this. > > Thank you, > Anita. > > [0] https://etherpad.openstack.org/p/kilo-nova-nova-network-to-neutron > [1] https://review.openstack.org/#/c/142456/ > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
