On Fri, Apr 20, 2012 at 5:15 PM, Joseph Heck <he...@me.com> 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
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
