Just wondering, is there any reason flavors are not limited to just create-time? Meaning, use it to create a new instance and then copy all of the flavor data into the new instance's data. This breaks the relationship between the instance and the flavor, allow each to be changed independently - or even deleted. Doing this would mean you wouldn't need to add a "disabled" flag at all - just delete the flavor if you don't want anyone to use it. This would also allow for an easier modification of existing instances - just modify the instance's property that needs to change w/o creating a whole new flavor (avoids the proliferation of flavors too).
thanks -Doug ______________________________________________________ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. Matthew Sherborne <matt.sherbo...@rackspace.com> Sent by: openstack-bounces+dug=us.ibm....@lists.launchpad.net 06/01/2012 10:41 AM To openstack@lists.launchpad.net cc Subject [Openstack] hidden / phasing out instance_types/flavors Hi Openstack community, We recently uploaded this change: https://review.openstack.org/#/c/8007/ It adds a 'disabled' field to the 'instance_type' or 'flavor' concept. The usage scenario we had in mind was to phase out a flavor that's already in use; people shouldn't be able to build new instances from that flavor, nor should customers see it in the list of available flavors. But when they view an existing instance with that flavor type, they should still be able to see the name of it at least. But should you change your mind later and wish to re-enable it, it's easy to just flip the flag. We'd appreciate feedback on the added field and the use of the namespace in the core code. (Line 56 here: https://review.openstack.org/#/c/8007/1/nova/api/openstack/compute/views/flavors.py ) The reasoning behind this is: * If we did it as an extension, it would greatly complicate the code. The code is much simpler being right in the core code. * We can't just add a field to the API quickly, so we need to use the namespace. * The hope is that eventually it would be accepted into the main API anyway, then the coding would be just removing the namespace. Many thanks in for reading. All feedback appreciated. Kind Regards, Matthew Sherborne_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp