openstack team mailing list archive

[Doug Hellmann <doug.hellmann@xxxxxxxxxxxxx>]

On Fri, Apr 20, 2012 at 5:15 PM, Joseph Heck <heckj@xxxxxx> wrote:

> While I've been roaming about the summit and conference, I've been trying
> to figure out exactly what we're modeling with the current "service" and
> "endpoints" that are in the API today. After talking with a number of
> folks, it's getting clearer that how it's being used is very installation
> specific.
>
> I'd like to simplify this aspect of the API if at all possible, especially
> with a lot of the good ideas around describing the relationships between
> endpoints and and their installation.
>
> The use cases I'm hearing actively in use are:
>
> * (Horizon/UI/client) To indicate to a user where they can go to access
> their data
> * (Glance, Nova, Keystone client) to find the endpoint relevant to
> uploading images (current client implementations appear to assume there is
> only one image endpoint)
>
> The use case to indicate a geographic location for a datacenter or "cloud"
> is not consistent - some implementations I've learned of have that feature
> (and use "Region" for that sort of information), and others are load
> balancing a single endpoint to deploy to multiple datacenters and
> geographic regions from a single endpoint.
>
> At the summit and conference, I heard a desire to expose geographic
> information with the endpoints, but that is clearly an operator specific
> implementation/deployment detail. Likewise I heard a lot of "We could
> really..." if additional metadata was easily available on endpoints, again
> in fairly implementation/deployment specific detail.
>
> So looking forward towards a v.next API, what do you all think about
> having just "endpoints", with everything else being attributes on those
> endpoints (including what "service" and "type" it is), with some expected
> conventions (that there are a few well defined types - such as PublicURL
> and InternalURL, and relevant names for the rest API endpoints (ec2,
> compute, volume, image, identity...)
>
> Additional metadata can then float on the endpoints in
> deployment/implementation specific ways that don't lock in other systems to
> be deployed and implemented in the same fashion.
>

That makes a lot of sense. Justin proposed some image metadata naming
conventions at the summit. It would be nice if the vendor-specific
properties on endpoints used similar conventions.

Doug