Doug, That's the behavior I'd like to see and think it makes the most sense. It's really a requirement if we want a great cells implementation. instance_types table should only be used at the top level API cell. The data contained in the table is passed in the messaging and stored with the newly built, re-built, or re-sized instance. I brought this up a couple days ago internally at Rackspace while this current patch was being developed and I think we were going to start to look at that next…. assuming everyone loves the idea. :)
- Chris On Jun 1, 2012, at 9:54 AM, Doug Davis wrote: > > 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 | [email protected] > The more I'm around some people, the more I like my dog. > > > Matthew Sherborne <[email protected]> > Sent by: [email protected] > 06/01/2012 10:41 AM > > To > [email protected] > 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 : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : [email protected] > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : [email protected] Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
