<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Jan 13, 2017 at 7:39 AM, Sean Dague <span dir="ltr"><<a href="mailto:sean@dague.net" target="_blank">sean@dague.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 01/12/2017 01:35 PM, Scott D'Angelo wrote:<br>
> TL;DR: Let's discuss Version Discovery and Endpoints in the Service<br>
> Catalog at the PTG in Atlanta.<br>
><br>
> The topic of Versioning and the Endpoints discovered in the Service<br>
> Catalog was discussed in today's API Working Group Meeting[1].<br>
> A previous ML post[2] claimed:<br>
><br>
> In a perfect world, every endpoint would return the same type of resource -<br>
> most likely the versions resource as described in the API WG Microversions<br>
> spec. It would also be nice if version negotiation can happen without<br>
> requiring authentication, the easiest path to which would be supporting the<br>
> 'max_version' and 'min_version' fields in the root versions resource.<br>
><br>
> One problem is multiple versioned service names in the catalog for a<br>
> given service[3], as opposed to a single endpoint that would return<br>
> version info[4].<br>
><br>
> Can we get to this "perfect world"? Let's discuss at the PTG.....<br>
> It is my understanding that we do not have the ability to schedule a<br>
> time or room for such a cross-project discussion. Please chime in if<br>
> interested, and/or make your interest known to scottda, mordred, or edleafe.<br>
<br>
</span>Happy to join in on this, it does seem weird there is no time / space<br>
for such things at PTG.<br>
<br>
We actually had a rough sketch of a plan last year here which would go a<br>
slightly different direction, and get that all up into the service<br>
catalog. That also ensures consistent schema enforcement, as it would<br>
all be through keystone.<br>
<br>
Definitely need keystone folks in the room to be able to make forward<br>
progress here I think, because part of the tension in the past has been<br>
understanding domain boundaries, and it would be a shame to do a ton of<br>
work in all the projects that could be easily done in one project, just<br>
because of communication gaps.<br></blockquote><div><br></div><div>If theres a room I'll be there, and try to rope in other folks too. </div></div></div></div>