Open Stack

Following up the mailing list[1] and DefCore meeting conversations last week,
I'd like to raise some questions for discussion to help us hear from
working group members and vendors about how to handle the issue of
additional properties. These questions are meant to create discussion,
but are not to be any sort of final or binding vote on the issue.

* Should there be a short-term exception for additional properties?

This change has been harmful to vendors, users, and the OpenStack
Powered program, and there should be a facility in DefCore to handle
this. Existing companies, that passed early in the year last year, no
longer pass. While there has been warning, product decisions move more
slowly. This exception gives vendors time to bring their products into
compliance with the direction that OpenStack is moving in. Additionally,
right now this is not harmful to interoperability in the current ecosystem. 
As far as I know there are no OpenStack clients, except for Tempest, 
that do strict response checking.

* Should there a permanent exception for additional properties?

My first inclination is to say, if additional properties can be safely
ignored by clients, no harm is done to the end users; especially those
who choose to ignore them. However, upstream is moving in this
direction, and it's only a matter of time before more projects and tools
adopt strict response checking, making it a long-term interoperability
issue regardless of the position DefCore takes. In 2017 we should
not be allowing clouds that send additional data in Nova responses
to pass interoperability testing.

* What is our guidance for vendors going forward?

My suggestion to vendors is to use the next year to adjust their product
strategy and releases. The ideal solution is to work with upstream to
have additional properties rolled into a new micro-version [2], which
would force those properties to be adopted upstream into the Tempest
library.

Failing that, there are options available for running OpenStack Powered
clouds that are compliant. These include (but are not limited to)
modifying the request API to optionally request additional properties
using http headers, or standing up new "vanilla" OpenStack endpoints
that the clients won't choke on.

[1] http://lists.openstack.org/pipermail/openstack-dev/2016-June/097349.html
[2] https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/api-no-more-extensions.html