I have a couple of reviews up to introduce the concept of shelving an
instance into Nova. The question has been raised as to whether or not
this belongs in Nova, or more rightly belongs in Heat. The blueprint
for this feature can be found at
https://blueprints.launchpad.net/nova/+spec/shelve-instance, but to make
things easy I'll outline some of the goals here.
The main use case that's being targeted is a user who wishes to stop an
instance at the end of a workday and then restart it again at the start
of their next workday, either the next day or after a weekend. From a
service provider standpoint the difference between shelving and stopping
an instance is that the contract allows removing that instance from the
hypervisor at any point so unshelving may move it to another host.
From a user standpoint what they're looking for is:
The ability to retain the endpoint for API calls on that instance. So
v2/<tenant_id>/servers/<server_id> continues to work after the instance
is unshelved.
All networking, attached volumes, admin pass, metadata, and other user
configurable properties remain unchanged when shelved/unshelved. Other
properties like task/vm/power state, host, *_at, may change.
The ability to see that instance in their list of servers when shelved.
Again, the objection that has been raised is that it seems like
orchestration and therefore would belong in Heat. While this is
somewhat similar to a snapshot/destroy/rebuild workflow there are
certain properties of shelving in Nova that I can't see how to reproduce
by handling this externally. At least not without exposing Nova
internals beyond a comfortable level.
So I'd like to understand what the thinking is around why this belongs
in Heat, and how that could be accomplished.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
