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.to...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
