Open Stack

Glad to hear that.  Just FYI, CIMI [1]  does this type of thing so if we 
ever do manage to harmonize the two APIs this might be a good place to 
start.

[1] 
http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.0d.pdf

thanks
-Doug
______________________________________________________
STSM |  Standards Architect  |  IBM Software Group
(919) 254-6905  |  IBM 444-6905  |  dug at us.ibm.com
The more I'm around some people, the more I like my dog.



Chris Behrens <cbehrens at codestud.com> 
06/01/2012 02:42 PM

To
Doug Davis/Raleigh/IBM at IBMUS
cc
Chris Behrens <cbehrens at codestud.com>, Matthew Sherborne 
<matt.sherborne at rackspace.com>, openstack at lists.launchpad.net
Subject
Re: [Openstack] hidden / phasing out instance_types/flavors






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  |  dug at us.ibm.com
The more I'm around some people, the more I like my dog. 


Matthew Sherborne <matt.sherborne at rackspace.com> 
Sent by: openstack-bounces+dug=us.ibm.com at lists.launchpad.net
06/01/2012 10:41 AM 


To
openstack at 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 at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack at lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20120601/4ee7c53c/attachment.html>