On 01/10/2015 05:57 AM, Armando M. wrote: >> >> If we were standing at a place with a detailed manual upgrade document >> that explained how to do minimal VM downtime, that a few ops had gone >> through and proved out, that would be one thing. And we could figure out >> which parts made sense to put tooling around to make this easier for >> everyone. >> >> But we seem far from there. >> >> My suggestion is to start with a detailed document, figure out that it >> works, and build automation around that process. >> > > The problem is that whatever documented solution we can come up with is > going to be so opinionated to be hardly of any use on general terms, let > alone worth automating. Furthermore, its lifespan is going to be reasonably > limited which to me doesn't seem to justify enough the engineering cost, > and it's not like we haven't been trying... > > I am not suggesting we give up entirely, but perhaps we should look at the > operator cases (for those who cannot afford cold migrations, or more simply > stand up a new cloud to run side-by-side with old cloud, and leave the old > one running until it drains), individually. This means having someone > technical who has a deep insight into these operator's environments lead > the development effort required to adjust the open source components to > accommodate whatever migration process makes sense to them. Having someone > championing a general effort from the 'outside' does not sound like an > efficient use of anyone's time. > > So this goes back to the question: who can effectively lead the technical > effort? I personally don't think we can have Neutron cores or Nova cores > lead this effort and be effective, if they don't have direct > access/knowledge to these cloud platforms, and everything that pertains to > them. > > Armando You have a good point Armando, the ideal person to lead this effort is someone with deep technical knowledge in this area. I think we can all agree that I don't have deep technical knowledge in this area (whether I have deep technical knowledge in any area can be a beer conversation).
I do have one ability, and folks can decide for themselves if that ability has value or not to them (I don't expect to have any consensus here). I do have the ability to wade into an area that everyone else deems too painful to bother with and share my perspective. Exercising that ability seems to stir up dormant feelings and either be looked on favourably or unfavourably depending on what someone's role in the history has been. Contrary to popular opinion I don't do what I do to hurt people, I do what I do from the motivation of trying to keep things flowing so all folks benefit (including folks who are affected by this decision and have never heard of OpenStack, let alone found this mailing list). In the absence of some person who actually has the abilities you outline, Armando, (and I do agree with your assessment, those qualities would be ideal) lets try to create a situation to perhaps attract such a person to either come forward or grow those abilities (or come forward _and_ grow those abilities), as we continue to move in the direction of putting ourselves (ourselves meaning OpenStack here) in the situation of deprecating Nova-Network. Thanks, Anita. > > >> -Sean >> >> -- >> Sean Dague >> http://dague.net >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStackfirstname.lastname@example.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > > > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev