As discussed at the newton midcycle and in the dev
mailing list:
http://lists.openstack.org/pipermail/openstack-dev/2016-July/099860.html
We should add a Tempest test for any microversion that
changes the response schema so we have coverage in Tempest
and also so we don't have to fill large gaps in coverage
in Tempest when adding other unrelated tests.
Change-Id: Ie7cfe7ee857caf630d4380cf673ae208842fbc00
V2 code is gone , there is no need to talk about this
in our document any more.
Partially implements blueprint remove-legacy-v2-api-code
Change-Id: Ibca00e3e862c1487f0a440fdcc7d11d09026c7a8
There was recent discussion in some reviews about fixing
latent bugs in the legacy v2.0 API code. Since the
v2.0 API is deprecated and v2.1 is the default since Liberty,
we shouldn't need to fix latent low-priority bugs in v2.0
anymore.
However, we'll still fix critical bugs, and we shouldn't
knowingly introduce new regressions that would result
in a 500 response.
Change-Id: I9937d9226a99754dadcc48d599090296f5ae01f7
The versioned notificaton infrastructure is in place and the team
agreed on the midcycle to allow new notification types only based
on the versioned notification infrastructure. So the code-review
document is updated to reflect this decision
Change-Id: I7f3860ca59658dc21e67f26bb45341cb46da2235
Partially-Implements: bp versioned-notification-api
Since I8ad9313f824ef656c841a9b60ee575f02ddea321, the api-wg has
introduced a new guideline. That was based on Nova's development
experience, and this patch adds it as a reviewing point for making
consistent APIs.
Change-Id: I53c4055d973b6f76fca16ae170d0df9e1829fca5
The trivial bug list has already got a +1 and often the fixes there are
too trivial to learn very much. Replaced with some hopefully more
useful advice.
Change-Id: Ibf5abc4dca170770d302ae9276312faad5eabdb6
With blueprint centralize-config-options we came to a conclusion
that it makes sense to have all config options at one central place.
This patch enhances the "config options" section with a "location"
subsection to clarify this.
Change-Id: I48b6f0c3311ad75f9faef78a7d163ae5bf640c6c
During nova-specs/nova reviews, it is difficult to check all API changes
for following api-wg guideline because there is a lot of nova-specs/nova
patches. There are some common mistakes against following guideline,
then this patch adds a part of the guideline to the code-review guideline
for avoiding these mistakes.
Change-Id: I2192e9ffd3026057dc01006bd0ba419140c5b5b0
Adds a note to the code review guidelines to make sure appropriate third
party tests are passing before giving a change a +2 vote.
Change-Id: I42501d3996a2751b69803e37451cc0544ad75ce8
Python-novaclient need to be updated to address new microversion
API change , so add some suggestions in the doc.
Change-Id: Ibb2d137a6a16badea7c2619d210317b7a098ec4e
The code-review guidelines document should be a somewhat agreed list
of what to consider when doing a review. This patch set adds the
items to check if the review contains changes which involves config
options.
Change-Id: I142ab25fa7fc1c4ece5a68f68c5d841c797af1be
This adds a document that aims to provide a checklist-like review
guideline for code reviewers. We can encode small decisions and tribal
knowledge in this document to help increase consistency.
Right now, this just adds upgrade-related review items as those are
some of the more complicated and least-documented at the moment.
Change-Id: I5bbb7e4e2192b853373fed38ca0ad873fc8b329e
Matt Riedemann