[openstack-dev] More on the topic of DELIMITER, the Quota Management Library proposal
whuisit at gmail.com
Sat Apr 23 20:53:31 UTC 2016
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
>>> 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
>>> For example, a "cluster" is not a resource. It is a collection of
>>> 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,
>>> PCI devices are the actual resources. The instance is a convenient
>>> way to
>>> tie those resources together, and doing a "resize" of the instance
>>> 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
>>> (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.
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev