Open Stack

Playing the cynic, in a cloud ecosystem, users are "greedy".  If there is a
benefit to the organization of suspending, then an ideal situation would
pass along a benefit to the user as well.  Otherwise, the busy user is
disinclined to suspend because doing so has a cost in the form of instance
state management without any corresponding benefit to the user.  Lack of
cloud-wide resources is "IT's problem, not mine".  As it stands today, the
suspend functionality only seems useful for cloud users that are also cloud
admins.



On Mon, Jun 23, 2014 at 7:58 PM, Preston L. Bannister <preston at bannister.us>
wrote:

> There is an expectation here. Is it explicitly optioned in the API? Should
> it be?
>
> Should a suspended instance be immediately resumable?
>
> If the expectation is that a suspended instance is resumable, then the
> claim against quota should be preserved, and the current behavior is
> correct.
>
> If the expectation is that resources are released, the instance may *not*
> be immediately resumable, if quotas are exceeded.
>
> Should this be an option, or unclaim-resources a distinct operation? Or is
> the present semantics all that is allowable?
>
> (I am new to OpenStack, so I may have missed something.)
>
>
>
>
> On Mon, Jun 23, 2014 at 10:05 AM, Ricky Saltzer <ricky at cloudera.com>
> wrote:
>
>> 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
>>
>>
>> _______________________________________________
>> Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>> Post to     : openstack at lists.openstack.org
>> Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>>
>
> _______________________________________________
> Mailing list:
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe :
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>
>


-- 
Andrew Mann
DivvyCloud Inc.
www.divvycloud.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20140623/0fb74a7a/attachment.html>