openstack team mailing list archive

[Yun Mao <yunmao@xxxxxxxxx>]

In EC2, shutdown_terminate is really to deal with instance-store
(local) vs EBS-backed (remote volume) instances. Once an instance is
stopped, all local state is cleaned so there is no way to bring back a
VM whose disk is local. That's why it's terminated automatically. For
EBS-backed instances, there is no local state. To start a stopped EBS
instance, it will go through the scheduler to find a compute node as
if we are creating a new instance.

My bet is that there are people who depend on this kind of EC2
compatibility. https://bugs.launchpad.net/nova/+bug/905270
Whether that's too much a burden to support, I'm not sure...

A related problem to stopped instances is about resource management.
Once the VM is stopped, it doesn't occupy resources (say memory). This
will be periodically reported back to the DB by the compute manager,
and the scheduler will be aware of that. However, starting the
instance back goes directly to the compute node. So it's possible that
you either have overcommitted resources in this case because new VMs
are spawned while in shutdown mode, or simply fail to start a VM due
to the lack of resources.

Billing stopped instances is tricky too but it seems to be more
provider specific.

Personally I like the EC2 API behavior over OS API because it makes
resource management simpler. But I'd be happy to go with OS API
behavior if we can have a good story to the resource update problem.
In any case, having a single, well defined, consistent behavior is
better than what's happening now. :)

Thanks,

Yun

On Fri, Jun 1, 2012 at 3:45 AM, Vishvananda Ishaya
<vishvananda@xxxxxxxxx> wrote:
> I did some cleanup of stop and power_off in the review here.
>
> https://review.openstack.org/#/c/8021/
>
> I removed the weird  shutdown_terminate handling. Honestly I feel like
> that is compatibility we don't need. It should be up to the provider whether
> a stop_instances counts as a terminate. In my mind they are two different
> things.
>
> Comments welcome on the review.
>
> Vish
>
> On May 31, 2012, at 6:40 PM, Yun Mao wrote:
>
> shutdown, stop, are power_off are synonym in this discussion. They all
> mean to stop the VM from running, but keep the disk image and network,
> so that the VM could be started back on again.
>
> There are three ways to do it: 1) using EC2 stop-instance API. 2) use
> OS API stop-server. 3) inside the VM, execute halt or equivalent.
> However, the devil is in the details.
>
> In EC2 API, a shutdown_terminate flag is checked when a stop-instance
> call is issued. If it's true, then stop-instances actually means
> terminate instances. The flag is true by default unless there is block
> device mapping provided, and it doesn't appear to be configurable by a
> user.
>
> In OS API, it's defined in v1.1, neither the specification nor the
> implementation check the shutdown_terminate flag at all. It will
> always do stop instead of terminate.
>
> So, when shutdown_terminate is true (default), the OS API and the EC2
> API will behave differently. If we accept this, it might still be
> acceptable. After all they are different APIs and could have different
> behavior. But the pickle is the case where a user initiates a shutdown
> inside the VM. What's the expected behavior after it's detected?
> Should it respect the shutdown_terminate flag or work more like an OS
> API?  Right now when a shutdown in a VM is detected, the vm state is
> updated to SHUTOFF and that's pretty much it..
>
> To summarize, there are 3 ways of doing the same thing, each now has a
> different behavior. I'd vote to patch the code to be a little more
> consistent. But what should be the right behavior?
>
> Yun
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>