<div dir="ltr">I'd like an answer on this specific issue. I agree with Chris and I wonder if our goal is consistency across services or an ideal standard.<div><br></div><div>Nova has 'X-OpenStack-Nova-API-Version' and Manila has 'X-Openstack-Manila-Api-Version'. If we deviate from this, we should suggest that those projects add the new standard as an alternative way to specify the version.</div><div><br></div><div>Cinder has this patch, <a href="https://review.openstack.org/#/c/224910/">https://review.openstack.org/#/c/224910/</a>, which tries to be consistent with Nova and Manila. If we don't decide on the guideline soon it will likely merge soon as to not impede progress.</div><div><br></div><div>-Alex</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 28, 2016 at 6:32 AM, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Couldn't agree more, Chris.<span class="HOEnZb"><font color="#888888"><br>
<br>
-jay</font></span><div><div class="h5"><br>
<br>
On 01/28/2016 11:06 AM, Chris Dent wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
On Wed, 27 Jan 2016, Dean Troyer wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think we would be better served in selecting these things thinking<br>
about<br>
the API consumers first.  We already have  enough for them to wade<br>
through,<br>
the API-WG is making great gains in herding those particular cats, I<br>
would<br>
hate to see giving back some of that here.<br>
</blockquote>
<br>
I think it is high time we resolve the question of whether the<br>
api-wg guidelines are evaluating existing behaviors in OpenStack and<br>
blessing the best or providing aspirational guidelines of practices<br>
which are considered best at a more universal level.<br>
<br>
Within the group many of our debates pivot around the above issue.<br>
There is some fear that if we choose the latter none of the<br>
guidelines will be followed.<br>
<br>
I think that's pretty weak sauce and we need to take both a more<br>
assertive and more aggressive stance with regard to achieving<br>
quality and consistency in the APIs[1]. Reaching consistency is the<br>
primary mission of the group but consistent crap is still crap and<br>
our API consumers deserve better.<br>
<br>
The thread about Ekko which has spawned a subthread about the<br>
collision between the ceilometer and monasca APIs should be a<br>
good learning moment™: Having some rigor and vision in our<br>
guidelines would allow us to state things like:<br>
<br>
* The APIs are services (for which there could potentially be other<br>
   implementations but the service represents a namespace)<br>
* Identifiers used in that service are service related, not project<br>
   related.<br>
* More specifically: URIs are signifiers of a service, not a project.<br>
<br>
The guidelines should be one (of several) ways in which a project<br>
can ask itself "are we being OpenStack?". If there is a collision<br>
with the guidelines, that provides a clue that the thing being<br>
considered is out of alignment. It should be an excuse to change or<br>
create new guidelines.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In this case, the use of service type as the primary identifier for<br>
endpoints and API services is well established, and is how the service<br>
catalog has and will always work.<br>
</blockquote>
<br>
For the specific issue of the headers, I think the above is the crux of<br>
the biscuit. The service catalog is intended to be a source of truth;<br>
that truth should be reflected in the guidelines. If the API being<br>
considered isn't (planned to be) in the service catalog does that<br>
API need to even be thinking about adhering to OpenStack guidelines?<br>
<br>
[1] Choosing to be more rigorous in the guidelines puts a large<br>
burden on the group to not simply rubberstamp incoming guidelines<br>
and also be more selective about what actually matters in terms of<br>
the guidelines. This is challenging because it became clear early on<br>
that adherence to correct HTTP in existing APIs was weak and there<br>
was an opportunity for the group to be a fount of knowledge and<br>
wisdom and distill best practices.<br>
<br>
That work still needs to go on, but it is also time to align<br>
the work with some of the main themes in today's OpenStack:<br>
<br>
* alignment with the service catalog and what it is trying to<br>
   accomplish<br>
* effective use of APIs when re-using real users' client code amongst a<br>
   diversity of clouds<br>
<br>
Just those two things can help us evaluate proposals with some<br>
useful constraints.<br>
<br>
<br>
<br></div></div><span class="">
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>