<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Apr 20, 2012 at 5:15 PM, Joseph Heck <span dir="ltr"><<a href="mailto:heckj@me.com" target="_blank">heckj@me.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">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.<div>
<br></div><div>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.</div><div><br></div>
<div>The use cases I'm hearing actively in use are:</div><div><br></div><div>* (Horizon/UI/client) To indicate to a user where they can go to access their data</div><div>* (Glance, Nova, Keystone client) to find the endpoint relevant to uploading images (current client implementations appear to assume there is only one image endpoint)</div>
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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...) </div>
<div><br></div><div>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.</div></div></blockquote>
<div><br></div><div>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.</div><div><br>
</div><div>Doug</div></div></div>