On 06/11/12 18:16, Ian Main wrote: > On Fri, Nov 02, 2012 at 12:07:56PM +0200, [email protected] wrote: >> Hi Ian: >> >> On 01/11/12 20:27, Ian Main wrote: >>> Name was not being set which is crucial for heat usage. >>> >> >> patch looks fine - in the sense that there is no problem for us to grab >> the 'name' of a flavor being passed back from Openstack and expose this >> as the 'name' attribute of a hardware_profile. >> >> HOWEVER, it is not possible to then use this 'name' attribute as a >> reference to a hardware profile. For example, lets say there is a flavor >> with ID: 1 and name: "256_MB_and_1_CPU": >> >> (against Deltacloud): >> >> GET /api/hardware_profiles/1 ==> 200 OK >> >> GET /api/hardware_profiles/256 MB and 1 CPU ==> explosions. >> >> Can you explain why is crucial for heat to have 'name'. If you really >> need to have lookup/reference to hardware profile by descriptive name, >> its possible but we need to change the deltacloud code. So that GET >> "256_MB_and_1_CPU" would mean getting a list of all flavors and >> filtering for the one with that name. > > Believe it or not it's so that humans can tell which one to use.. :) No > need to change deltacloud code as we will pass the ID into deltacloud > API.
ok - thanks for the clarification. I just pushed this patch with commit id cf5a3ae7b2e27b1e28d1e9cb33629e6ae8a9a824 - should make its way into release 1.0.5 which we are working to cut this week, (waiting for your input on the user-data patch - likely any changes there won't make their way into this release as we are getting the rc out asap) thanks, marios > >> Only issue here though is that :id is a bona-fide UUID whereas :name is >> just a string. I wonder if there can be duplicates? > > I think that depends on the configuration of the cloud.. I would think > in 99% of cases it would be unique. > > Ian >
