Open Stack

Hi,

Thanks for the quick reply - I hadn’t picked up from the Blueprint page that this will be two separate APIs.

Just to be clear - is the plan here is to have one new API extension which supports two different operations, one of which is protected by a role (admin by default), or two extensions ?        (I could be wrong but I thought the more common approach is to keep admin operations in a separate extension altogether, so that they can (for example) be loaded only on an internal API server.)

The "show availability_zone of instance" (https://review.openstack.org/#/c/17027/5) change seems to have stalled - is that still on-going work ?

Thanks
Phil

-----Original Message-----
From: gtt116 [mailto:gtt116 at 126.com] 
Sent: 16 January 2013 02:32
To: Day, Phil
Cc: OpenStack Development Mailing List; lzy.dev at gmail.com
Subject: Re: [openstack-dev] API and implementation about show-availability-zone blueprint

Hi Day

As the blueprint described
(https://blueprints.launchpad.net/nova/+spec/show-availability-zone ), We will add two new API. One is showing AZ in instance detail page. The other is show all the AZs in the system.

As lzy described, the detail information of AZ is just for admin, not the very end user. I think it is safe and good for maintenancing.

于 2013年01月16日 03:04, Day, Phil 写道:
> Hi Folks,
>
> A couple of thoughts on this:
>
> - Having a way to query the list of availability zones from the OSAPI sounds good.
>
> - I don't think a detailed view should return any details of specific hosts (or even numbers of hosts) in an AZ, as generally that's not user facing information.  Maybe ok to provide this kind of info to someone with a specific role - but not as general data.
>
> - Could this extension also add the availability zone to the details returned for a instance data ?  
>
> Phil
>
> -----Original Message-----
> From: Vishvananda Ishaya [mailto:vishvananda at gmail.com]
> Sent: 15 January 2013 18:15
> To: lzy.dev at gmail.com
> Cc: OpenStack Development Mailing List; gtt116 at 126.com
> Subject: Re: [openstack-dev] API and implementation about 
> show-availability-zone blueprint
>
>
> On Jan 14, 2013, at 11:10 PM, lzy.dev at gmail.com wrote:
>
>> Hi TianTian,
>>
>> I have saw the show-availability-zone blueprint you created at 
>> https://blueprints.launchpad.net/nova/+spec/show-availability-zone,
>> for "show all availibility_zone in a region" part, it's on TODO 
>> status, I also have this requirement so I have designed and commited 
>> the implementation to our internal. Since I don't want to revisit it 
>> in Grizll, so shall we talk about a)YOUR PLAN and b)ALIGN OUR 
>> IMPLEMENTATION WITH IT in future? There are API and implementation 
>> two parts, thanks.
>>
>> 1. For API part, I need it expose two restful endpoints to return a 
>> summary or detailed list of availability zone to client, just like 
>> EC2 API allowed.
>> Summary list (normal role) API: /v2/{tenant}/os-availability-zone 
>> Details list (admin  role) API:
>> /v2/{tenant}/os-availability-zone/detail
>>
>> I have one consern for API is that as we know nova-api ec2 API 
>> endpoint has ready support AZ listing function, so do you think it is 
>> a duplication on the design principle level? @Vish, could you pls 
>> give input? and @TianTian, what about reuse "os-availability-zone"
>> extension but not create "availability_zones" new one and what's your 
>> plan?
>>
>> 2. For implementation part, I have wrote an API extension base on 
>> os-availability-zone extension and a ResourceExtension to adding 
>> availability zone listing api extension to nova-api. In my current 
>> implementation, listing result like below:
>>
>> Example summary list as following (python-novaclient changed also):
>> lzy at dev-controller-ibm-folsom:?/workspace/openstack-es/python-novacli
>> e
>> nt$
>> nova availability-zone-list
>> +----------------------------------------+---------------------------------+
>> | Name                                   | Status                          |
>> +----------------------------------------+---------------------------------+
>> | nova                                   | available                       |
>> +----------------------------------------+---------------------------------+
>>
>> Example details list as following  (python-novaclient changed also):
>> lzy at dev-controller-ibm-folsom:?/workspace/openstack-es/python-novacli
>> e
>> nt$
>> nova availability-zone-list
>> +----------------------------------------+---------------------------------+
>> | Name                                   | Status                          |
>> +----------------------------------------+---------------------------------+
>> | nova                                   | available                       |
>> | |- dev-compute-ibm-folsom-1            |                                 |
>> | | |- nova-compute                      | enabled XXX 2012-12-11 11:35:06 |
>> | |- dev-controller-ibm-folsom           |                                 |
>> | | |- nova-scheduler                    | enabled XXX 2012-12-12 03:41:11 |
>> | | |- nova-cert                         | enabled XXX 2012-11-29 12:27:04 |
>> | | |- nova-network                      | enabled XXX 2012-12-12 03:41:11 |
>> | |- dev-nova-network-gateway-ibm-folsom |                                 |
>> | | |- nova-network                      | enabled XXX 2012-12-11 08:47:54 |
>> +----------------------------------------+---------------------------------+
>>
>> I have also one consern for this implementation part. As we know in 
>> grizzly we will import Cell concept, I'm not sure this change can 
>> keep consistency between the Availability zone and Cell concept? 
>> @Vish, could you pls input something to make me sure?
> Cells are a provider implementation detail. Therefore the view for users should depend on the az metadata in host aggregates, not cells. If a deployment wants to map azs to cells, they can do so by explicitly creating a host aggregate in each cell. That said, the host aggregate az data will need to be aggregated up to the parent cell for this all to work properly. I suspect that doesn't exist today.
>
> Vish
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
best regards,
gtt