Open Stack

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 [1], 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?

Thanks
Amit.





[1] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog

> On Dec 18, 2014, at 11:19 PM, Everett Toews <everett.toews at RACKSPACE.COM> wrote:
> 
> Hi All,
> 
> At the recent API WG meeting [1] 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 [2]. 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 [3]. I wasn’t aware of all of the places where the concept of metadata is used in OpenStack so I did some analysis [4]. 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 [5] 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 [5]
> 
> Any thoughts or feedback on the above?
> 
> Thanks,
> Everett
> 
> [1] http://eavesdrop.openstack.org/meetings/api_wg/2014/api_wg.2014-12-18-16.00.log.html
> [2] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog
> [3] https://review.openstack.org/#/c/141229/
> [4] https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Metadata
> [5] https://review.openstack.org/#/c/133660/
> [6] https://wiki.openstack.org/wiki/API_Working_Group#How_to_Contribute
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev