[openstack-dev] [api] service type vs. project name for use in headers
mr.alex.meade at gmail.com
Thu Jan 28 14:31:31 UTC 2016
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.
On Thu, Jan 28, 2016 at 6:32 AM, Jay Pipes <jaypipes at gmail.com> wrote:
> Couldn't agree more, Chris.
> 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
>>> the API consumers first. We already have enough for them to wade
>>> the API-WG is making great gains in herding those particular cats, I
>>> 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. 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
>> * 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?
>>  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
>> * 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)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev