[openstack-dev] API and implementation about show-availability-zone blueprint

Day, Phil philip.day at hp.com
Tue Jan 15 19:04:12 UTC 2013


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-novaclie
> 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-novaclie
> 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



More information about the OpenStack-dev mailing list