Open Stack

On Tue, Jun 25, 2013 at 7:22 AM, Andrew Laski <andrew.laski at rackspace.com>wrote:

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


the part that caught my eye as something that *may* be in heat's domain and
is at least worth a discussion is the snapshotting and periodic task part.

from what I can tell, it sounds like the use case is for this is:  I want
to 'shutdown' my VM overnight and save money since I am not using it, but I
want to keep everything looking the same.

But in this use case I would want to automatically 'shelve' my instance off
the compute-server every night (not leave it on the server) and every
morning I would want it to autostart before I get to work (and re-attach my
volume and re-associate my floating-ip).  All of this sounds much closer to
using heat and snapshotting then using 'shelving.'

Additionally, storing the shelved instance locally on the compute-node
until a simple periodic task to migrates 'shelved' instances off into deep
storage seems like it has undesired side-effects.  For example, as long as
the shelved instance is on a compute-node, you have to reserve CPU
resources for it, otherwise the instance may not be able to resume on the
same compute-node invalidating the benefits (as far as I can tell) of
keeping the instance locally snapshotted.



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

This sounds like a good reason to keep this in nova.


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

What properties are those, and more importantly why I need them?


>
> 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 at lists.openstack.**org <OpenStack-dev at lists.openstack.org>
> http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<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/20130625/bcd7f0d1/attachment.html>