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? Thanks Amit.  https://wiki.openstack.org/wiki/API_Working_Group/Current_Design/Service_Catalog > On Dec 18, 2014, at 11:19 PM, Everett Toews <everett.to...@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? > > Thanks, > Everett > >  > 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 > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev