<font size=2 face="sans-serif">Hi Tim,</font>
<br>
<br><font size=2 face="sans-serif">Would be great to have a session around
these topics at the design summit.</font>
<br><font size=2 face="sans-serif">Going forward, I can see something like
this as a separate project or service, approaching the admin APIs of Nova.
In the host failure scenario, it would also make sense to use it to do
fencing, approaching Cinder, Neutron, Ironic..</font>
<br><font size=2 face="sans-serif">It might make sense to start with a
discussion in Nova, as it could be a natural place for at least some of
those scenarios and policies, and it would be natural to expect Nova to
provide majority of the relevant hooks, notifications and APIs if/when
the end-to-end scenario is implemented at some other place. Another option
is to have a discussion in the 'unconference' track.</font>
<br>
<br><font size=2 face="sans-serif">Regards,</font>
<br><font size=2 face="sans-serif">Alex</font>
<br>
<br><font size=2 face="sans-serif">[1] </font><a href="https://blueprints.launchpad.net/nova/+spec/host-maintenance"><font size=3 color=blue><u>https://blueprints.launchpad.net/nova/+spec/host-maintenance</u></font></a><font size=3>
</font>
<br><font size=2 face="sans-serif">[2] </font><a href="https://blueprints.launchpad.net/nova/+spec/find-host-and-evacuate-instance"><font size=3 color=blue><u>https://blueprints.launchpad.net/nova/+spec/find-host-and-evacuate-instance</u></font></a><font size=3>
</font>
<br><font size=2 face="sans-serif">[3] </font><a href="https://blueprints.launchpad.net/python-novaclient/+spec/evacuate-host"><font size=3 color=blue><u>https://blueprints.launchpad.net/python-novaclient/+spec/evacuate-host</u></font></a><font size=3>
</font>
<br><font size=2 face="sans-serif">[4] </font><a href="https://blueprints.launchpad.net/python-novaclient/+spec/find-and-evacuate-host"><font size=3 color=blue><u>https://blueprints.launchpad.net/python-novaclient/+spec/find-and-evacuate-host</u></font></a><font size=3>
</font>
<br>
<br><tt><font size=2>Tim Bell <Tim.Bell@cern.ch> wrote on 20/09/2013
12:02:57 AM:<br>
<br>
> </font></tt>
<br><tt><font size=2>> Discussing with various people in the community,
there seems to be <br>
> interest in a way to</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> - Identify
when a hypervisor is being drained or is down <br>
> and inventory its VMs</font></tt>
<br><tt><font size=2>> - Find the
best practise way of restarting that VM for <br>
> hypervisors still available</font></tt>
<br><tt><font size=2>> o Live migration</font></tt>
<br><tt><font size=2>> o Cold migration</font></tt>
<br><tt><font size=2>> - Defining
policies for the remaining cases</font></tt>
<br><tt><font size=2>> o Restart from base image</font></tt>
<br><tt><font size=2>> o Suspend</font></tt>
<br><tt><font size=2>> o Delete</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> This touches multiple components from Nova/Cinder/Quantum
(at minimum).</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> It also touches some cloud architecture questions
if OpenStack can <br>
> start to move into the low hanging fruit parts of service consolidation.</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> I’d like to have some form of summit discussion
in Hong Kong around <br>
> these topics but it is not clear where it fits.</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Are there others who feel similarly ? How can
we fit it in ?</font></tt>
<br><tt><font size=2>> </font></tt>
<br><tt><font size=2>> Tim</font></tt>
<br><tt><font size=2>> [attachment "smime.p7s" deleted
by Alex Glikson/Haifa/IBM] <br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> OpenStack-dev@lists.openstack.org<br>
> </font></tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev"><tt><font size=2>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</font></tt></a><tt><font size=2><br>
</font></tt>