Open Stack

On 04/23/2016 03:25 PM, Jay Pipes wrote:
> On 04/23/2016 03:18 PM, Mike Perez wrote:
>> On 14:54 Apr 18, Jay Pipes wrote:
>>> On 04/16/2016 05:51 PM, Amrith Kumar wrote:
>>>>          - update_resource(id or resource, newsize)
>>>
>>> Resizing resources is a bad idea, IMHO. Resources are easier to deal
>>> with
>>> when they are considered of immutable size and simple (i.e. not
>>> complex or
>>> nested). I think the problem here is in the definition of resource
>>> classes
>>> improperly.
>>>
>>> For example, a "cluster" is not a resource. It is a collection of
>>> resources
>>> of type node. "Resizing" a cluster is a misnomer, because you aren't
>>> resizing a resource at all. Instead, you are creating or destroying
>>> resources inside the cluster (i.e. joining or leaving cluster nodes).
>>>
>>> BTW, this is also why the "resize instance" API in Nova is such a
>>> giant pain
>>> in the ass. It's attempting to "modify" the instance "resource" when the
>>> instance isn't really the resource at all. The VCPU, RAM_MB, DISK_GB,
>>> and
>>> PCI devices are the actual resources. The instance is a convenient
>>> way to

-- Tom
>>> tie those resources together, and doing a "resize" of the instance
>>> behind
>>> the scenes actually performs a *move* operation, which isn't a
>>> *change* of
>>> the original resources. Rather, it is a creation of a new set of
>>> resources
>>> (of the new amounts) and a deletion of the old set of resources.
>>
>> How about extending a volume? A volume is a resource and can be
>> extended in
>> Cinder today.
> 
> Yep, understood :) I recognize some resource amounts can be modified for
> some resource classes. How about *shrinking* a volume. Is that supported?

manila has apis for both extending and shrinking shares.

FWIW I very much like the notion that we should be able to check actual
up-to-date resource usage, use a single source of truth, and reduce the
amount of races that have to be handled.  The previous one-sentence
paragraph provides a data-point and is not intended as an objection.

-- Tom

> 
> Best,
> -jay
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev