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 

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 <> 
> 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] 
> [2] 
> [3]
> [4]
> [5]
> [6]
> _______________________________________________
> OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to