<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jun 25, 2013 at 10:38 AM, Andrew Laski <span dir="ltr"><<a href="mailto:andrew.laski@rackspace.com" target="_blank">andrew.laski@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 06/25/13 at 09:42am, Joe Gordon wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Tue, Jun 25, 2013 at 7:22 AM, Andrew Laski <<a href="mailto:andrew.laski@rackspace.com" target="_blank">andrew.laski@rackspace.com</a>><u></u>wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
I have a couple of reviews up to introduce the concept of shelving an<br>
instance into Nova. The question has been raised as to whether or not this<br>
belongs in Nova, or more rightly belongs in Heat. The blueprint for this<br></div>
feature can be found at <a href="https://blueprints.launchpad." target="_blank">https://blueprints.launchpad.</a>*<u></u>*<br>
net/nova/+spec/shelve-<u></u>instance<<a href="https://blueprints.launchpad.net/nova/+spec/shelve-instance" target="_blank">https://blueprints.<u></u>launchpad.net/nova/+spec/<u></u>shelve-instance</a>><br>
**, but to make things easy I'll outline some of the goals here.<div class="im"><br>
<br>
The main use case that's being targeted is a user who wishes to stop an<br>
instance at the end of a workday and then restart it again at the start of<br>
their next workday, either the next day or after a weekend. From a service<br>
provider standpoint the difference between shelving and stopping an<br>
instance is that the contract allows removing that instance from the<br>
hypervisor at any point so unshelving may move it to another host.<br>
<br>
</div></blockquote><div class="im">
<br>
<br>
the part that caught my eye as something that *may* be in heat's domain and<br>
is at least worth a discussion is the snapshotting and periodic task part.<br>
<br>
from what I can tell, it sounds like the use case is for this is: I want<br>
to 'shutdown' my VM overnight and save money since I am not using it, but I<br>
want to keep everything looking the same.<br>
<br>
But in this use case I would want to automatically 'shelve' my instance off<br>
the compute-server every night (not leave it on the server) and every<br>
morning I would want it to autostart before I get to work (and re-attach my<br>
volume and re-associate my floating-ip). All of this sounds much closer to<br>
using heat and snapshotting then using 'shelving.'<br>
</div></blockquote>
<br>
The periodic task for removing a shelved instance from the hypervisor is a first pass attempt at a mechanism for reclaiming resources, and is under discussion and will probably evolve over time. But the motivation for reclaiming resources will be driven by deployment capacity or the desire to reshuffle instances or maybe something else that's important to a deployer. Not the user. Since I see Heat as an advocate for user requests, not deployer concerns, I still think this falls outside of its concerns.<br>
</blockquote><div><br></div><div><br></div><div style>If this wasn't important to the user, they would never do it. But since this has the promise of cost saving for users, it does affect them.</div><div style><br></div>
<div style><br></div><div style>That being said I think a decent argument has been made for why this should be in nova.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
There's no concept of autostart included in shelving. I agree that that gets beyond what should be performed in Nova.<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Additionally, storing the shelved instance locally on the compute-node<br>
until a simple periodic task to migrates 'shelved' instances off into deep<br>
storage seems like it has undesired side-effects. For example, as long as<br>
the shelved instance is on a compute-node, you have to reserve CPU<br>
resources for it, otherwise the instance may not be able to resume on the<br>
same compute-node invalidating the benefits (as far as I can tell) of<br>
keeping the instance locally snapshotted.<br>
</blockquote>
<br></div>
You're correct that there's not a large benefit to a deployer unless resources are reclaimed. Perhaps some small power savings, and the freedom to migrate the instance transparently if desired. I would prefer to remove the instance when it's shelved rather than waiting for something, like a periodic task or admin api call, to trigger it. But booting disk based images can take a fairly long time so I've optimized for the case of an instance being shelved for a day or a weekend. That way users get acceptable unshelve times for the expected case, and deployers benefit when an instance is shelved longer term. I don't think this needs to be set in stone and the internal working can be modified as we find ways to improve it.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
>From a user standpoint what they're looking for is:<br>
<br>
The ability to retain the endpoint for API calls on that instance. So<br></div>
v2/<tenant_id>/servers/<**<u></u>server_id> continues to work after the instance<div class="im"><br>
is unshelved.<br>
<br>
All networking, attached volumes, admin pass, metadata, and other user<br>
configurable properties remain unchanged when shelved/unshelved. Other<br>
properties like task/vm/power state, host, *_at, may change.<br>
<br>
The ability to see that instance in their list of servers when shelved.<br>
<br>
</div></blockquote><div class="im">
<br>
This sounds like a good reason to keep this in nova.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<br>
Again, the objection that has been raised is that it seems like<br>
orchestration and therefore would belong in Heat. While this is somewhat<br>
similar to a snapshot/destroy/rebuild workflow there are certain properties<br>
of shelving in Nova that I can't see how to reproduce by handling this<br>
externally. At least not without exposing Nova internals beyond a<br>
comfortable level.<br>
<br>
</blockquote>
<br>
What properties are those, and more importantly why I need them?<br>
</div></blockquote>
<br>
Mainly uuid, but also the server listing. If Heat snapshots and removes an instance it has no way to recreate it with the same uuid. As much as I wish it wasn't the case, this is important to users.<br></blockquote>
<div><br></div><div style>*sigh*</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
So I'd like to understand what the thinking is around why this belongs in<br>
Heat, and how that could be accomplished.<br>
<br></div>
______________________________<u></u>**_________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.<u></u>**org <<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.<u></u>openstack.org</a>><br>
<a href="http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev" target="_blank">http://lists.openstack.org/**<u></u>cgi-bin/mailman/listinfo/**<u></u>openstack-dev</a><<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.<u></u>openstack.org/cgi-bin/mailman/<u></u>listinfo/openstack-dev</a>><br>
<br>
</blockquote></blockquote><div class="HOEnZb"><div class="h5">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</blockquote>
<br>
<br>
______________________________<u></u>_________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.<u></u>org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/<u></u>cgi-bin/mailman/listinfo/<u></u>openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>