Neutron needs a test for GET /

[Mark T. Voelker]

A fundamental operation for most OpenStack services is providing information about what versions of an API are available to clients. A version document can be retrieved by sending an unauthenticated GET request to the root URL ("/") for most services, including Neutron. This capability is important for discovery in that clients can learn how to interact with the cloud in question, and DefCore considers it an important capability for interoperability and has added similar capabilities to it's Guidelines for other services.[1][2] As Neutron moves toward microversioning [3], being able to retrieve a version document will be increasingly important for clients. However, there are currently no tests for GET /, so DefCore cannot make this a required Capability. We should a simple smoke test or two for GET /.

[1] http://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json#n117
[2] http://git.openstack.org/cgit/openstack/defcore/tree/2016.01.json#n1379
[3] https://etherpad.openstack.org/p/newton-neutron-future-neutron-api

[Assaf Muller (amuller)]

I would recommend an API test in the Neutron repo.

[Mark T. Voelker (mvoelker)]

@amuller: DefCore can currently only use tests either from Tempest or in-project-tree tests that are available via the Tempest plugin interface. As an FYI, in one of the QA sessions is was mentioned that some folks feel that DefCore tests should ultimately move into the Tempest tree rather than be scattered about the various projects (I believe Doug Hellman mentioned he might be interested in drafting something to that effect for TC consideration).

I wrote up a quick proof-of-concept on the flight home from Austin here:

https://review.openstack.org/#/c/311747/

[Assaf Muller (amuller)]

"DefCore can currently only use tests either from Tempest or in-project-tree tests that are available via the Tempest plugin interface."

Neutron has a Tempest plugin.

[Assaf Muller (amuller)]

I wasn't present for the discussion you are referring to, but my 2 cents is that the location of the tests has nothing to do with DefCore concepts as long as you can easily run the tests (e.g. Tempest plugins). The idea that all DefCore tests must live in a specific Git repo seems weird and oddly specific to me.

[Mark T. Voelker (mvoelker)]

Personally I don't have strong opinions either way: RefStack has the ability to run tests from both places, and are content to the let the projects/TC decide whether they want them to live somewhere centralized or not. However I thought it was worth mentioning that this is likely going to be a topic of a governance discussion soonish since you recommended taking an in-tree approach (in case foks feel strongly and want to weigh in). The POC I hacked up is actually in Tempest, but if folks feel strongly one way or another I'm happy to put it somewhere else.

That said, I think there are perhaps a few advantages to putting a new test like this in Tempest. For example, the most recent Board-approved DefCore Guideline covers Juno, Kilo, Liberty, and (now) Mitaka. Although we don't have a test for it, the version API itself has existed pretty much since forever in Neutron and should work just fine on all those releases. If we add the test to Tempest (which is branchless) users can get it quite easily. If we put it in-tree, we have to ask users to pull tests from master (or Newton once it arrives) even if the cloud they're working against is built on Kilo. So mechanically/logically, it's perhaps a bit easier on users.

[Armando Migliaccio (armando-migliaccio)]

This bug is > 180 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

[yatin (yatinkarel)]

This looks already fixed with https://review.opendev.org/c/openstack/tempest/+/311747, so i think it can be closed.