Open Stack

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-novaclient$
> 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-novaclient$
> 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