[openstack-dev] [api] Analysis of current API design
amit.gandhi at RACKSPACE.COM
Fri Dec 19 16:17:27 UTC 2014
How do the allocation of the service types in the service catalog get created.
For example, looking at the link provided below for service catalogs , you have with Rackspace a service type of rax:queues (which is running zaqar). However in devstack, zaqar is listed as “messaging”. FWIW i think the rackspace entry came before the devstack entry, but there is now an inconsistency.
How do new openstack related projects (that are not incubated/graduated) appear in the service catalog with a consistent service type name that can be used across providers with the confidence it refers to the same set of api's? Is it just an assumption, or do we need a catalogue somewhere listing what each service type is associated with? Does adding it to Devstack pretty much stake claim to the service type?
> On Dec 18, 2014, at 11:19 PM, Everett Toews <everett.toews at RACKSPACE.COM> wrote:
> Hi All,
> At the recent API WG meeting  we discussed the need for more analysis of current API design.
> We need to get better at doing analysis of current API design as part of our guideline proposals. We are not creating these guidelines in a vacuum. The current design should be analyzed and taken into account.
> Naturally the type of analysis will vary from guideline to guideline but backing your proposals with some kind of analysis will only make them better. Let’s take some examples.
> 1. Anne Gentle and I want to improve the consistency of service catalogs across cloud providers both public and private. This is going to require the analysis of many providers and we’ve got a start on it here . Hopefully a guideline for the service catalog should fall out of the analysis of the many providers.
> 2. There’s a guideline for metadata up for review . I wasn’t aware of all of the places where the concept of metadata is used in OpenStack so I did some analysis . I found that the representation was pretty consistent but how metadata was CRUDed wasn’t as consistent. I hope that information can help the review along.
> 3. This Guideline for collection resources' representation structures  basically codifies in a guideline what was found in the analysis. Good stuff and it has definitely helped the review along.
> For more information about analysis of current API design see #1 of How to Contribute 
> Any thoughts or feedback on the above?
>  http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-12-18-16.00.log.html
>  https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
>  https://review.openstack.org/#/c/141229/
>  https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Metadata
>  https://review.openstack.org/#/c/133660/
>  https://wiki.openstack.org/wiki/API_Working_Group#How_to_Contribute
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
More information about the OpenStack-dev