Open Stack

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 <jaypipes at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160128/b561908c/attachment.html>