[Openstack] Why doesn't suspend release vCPUs/memory?

Wangpan hzwangpan at corp.netease.com
Thu Jun 26 04:00:00 UTC 2014


Oh, sorry, I misunderstood your idea,
Ok, then the last problem is how to release the vcpus/mem resources of suspended instances on the compute nodes?

2014-06-26 11:57 (UTC+8)
Wangpan

----- Original Message -----
> From: Ricky Saltzer <ricky at cloudera.com>
> To: "Wangpan"<hzwangpan at corp.netease.com>
> Sent: 2014-06-25 03:58
> Subject: Re: Re: [Openstack] Why doesn't suspend release vCPUs/memory?
I don't see how there would be a problem if you still enforced a hard limit of the number of instances a user can have. The proposal here is suspending would release only vCPUs and memory, so the user could still potentially exceed their quota by reaching their allotted amount of instances. Let's say 5/10 instances for a user accumulated to 20 vCPUs (4 vCPUs per node), suspending those 5 instances would release the 20 vCPUs back, but those 5 suspended instances would still count towards their total number of instances quota.  






On Mon, Jun 23, 2014 at 11:24 PM, Wangpan <hzwangpan at corp.netease.com> wrote:

I think if we do this, a serious security risk is imported, think this use case:
1) an user has quotas like 10 instances, 20 vcpus, 100G ram and 200G disks
2) he boots 10 instances under his quotas
3) he suspends all this instances
4) he repeats step 2&3 day and night
5) then the cloud platform will have no resources to supply eventually

2014-06-24 11:17 (UTC+8)
Wangpan

----- Original Message -----
> From: Ricky Saltzer <ricky at cloudera.com>
> To: "John Griffith"<john.griffith at solidfire.com>
> Sent: 2014-06-24 01:05
> Subject: Re: [Openstack] Why doesn't suspend release vCPUs/memory?
That seems to be the case, and I can see where you're coming from, but if the resources aren't released at the quota level, then they're effectively being used from a user's point of view. It would be nice if suspend released resources after the instance is shutdown, and a resume would reclaim the resources (provided enough are available). For instance, if I had 210/210 vCPUs used, and I suspend instance_a with 1 vCPU, and then launch instance_b with 1 vCPU...instance_b should successfully deploy, but resuming instance_a should fail with a quota exceeded exception.





On Mon, Jun 23, 2014 at 12:54 PM, John Griffith <john.griffith at solidfire.com> wrote:






On Mon, Jun 23, 2014 at 10:49 AM, Ricky Saltzer <ricky at cloudera.com> wrote:

Right, the quotas don't seem to be released. If I have 210/210 vCPUs used, and I suspend an instance with 4 vCPUs, I still have 210/210 vCPUs used. 




On Mon, Jun 23, 2014 at 11:38 AM, John Griffith <john.griffith at solidfire.com> wrote:



On Mon, Jun 23, 2014 at 7:45 AM, Ricky Saltzer <ricky at cloudera.com> wrote:

https://ask.openstack.org/en/question/32826/why-doesnt-suspend-release-vcpusmemory/


​My understanding was always that the instance is no longer consuming any resources via the virt layer, so in essence the resources are in fact freed up on the Compute Node.  Quotas and such however aren't modified (which seems correct to me).  Are you saying you want to see quota's adjusted here? ​






-- 

Ricky Saltzer
http://www.cloudera.com



​Yeah, I think that makes sense and is expected, as a user you're still consuming those "items" even if they're not active.  The alternative would be (which I think is what you're getting at) to actually deduct items that are suspended from the tenants quota count.  I guess when I think of it though those resources are still "reserved" even if they're not in use.  I suppose you could do this and then if on resume the quota isn't there we don't actually resume... but I think this could be argued either way.


Maybe seperate quotas for active vs suspended?  ​





-- 

Ricky Saltzer
http://www.cloudera.com







-- 

Ricky Saltzer
http://www.cloudera.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140626/36c2d1a6/attachment.html>


More information about the Openstack mailing list