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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev