Open Stack

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


>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150109/289f4582/attachment.html>