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