On 8/11/14, 4:52 AM, Thierry Carrez wrote:
gustavo panizzo (gfa) wrote:
only one think i didn't like it

why all url,api, etc has to include the word 'preview'?
i imagine that i would be consuming the new feature using heat, puppet,
local scripts, custom horizon, whatever. Why do you make me to change
all them when the feature moves out of preview? it could be a lot of
rework (for consumers) without gain. I would totally support other big
fat warnings everywhere (logs, documentation, startup log of
neutron-server) but don't change the API if is not necessary
I see two issues with this proposal: the first one is what Gustavo just
said: the use of the "preview" package/configoption/API creates friction
when the feature needs to go mainstream (package renaming, change in
configuration for deployers, change in API calls for users...).
Hi Thierry,

I completely agree with you and with Gustavo that "mangling" the REST URIs to include "preview" may have more cost (i.e. friction when the API becomes stable) than benefit. I'm happy to drop that particular part of the proposal. The email was intended to kick off discussion of these sorts of details.

My understanding is that the goal is to make it easy for people to "try"
the preview feature, and keeping the experimental feature in-tree is
seen as simpler to experiment with. But the pain from this friction imho
outweighs the pain of deploying an out-of-tree plugin for deployers.
I agree out-of-tree is a better option for truly experimental features. This in-tree stabilization is intended for a beta release, as opposed to a prototype.

The second issue is that once the feature is in "preview" in tree, it
moves the responsibility/burden of making it official (or removed) to
the core developers (as Salvatore mentioned). I kind of like the
approach where experimental features are developed in faster iterations
out-of-tree and when they are celebrated by experimenters and are ready
to be stable-supported, they are moved in tree.
I don't think we are really disagreeing here. There are clearly situations where rapid iteration out-of-tree, without the burden of the core review process, is most appropriate. But this proposal is intended for features that are on the cusp of being declared stable, rather than for experimentation. The intent is absolutely to have all changes to the code go through the regular core review process during this stabilization phase. This enables the feature to be fully reviewed and integrated (also including CLIs, Horizon and Heat support, documentation, etc.) at the point when the decision is made that no further incompatible API changes will be needed. Once the feature is declared stable, from the end-user perspective, its just a matter of removing the "preview" label. Moving the feature's code from the preview subtree to its normal locations in the tree will not effect most users or operators.

Note that the GBP team had implemented a proof-of-concept prior to the start of the Juno cycle out-of-tree. Our initial plan was to get this PoC code reviewed and merged at the beginning of Juno, and then iteratively improve it throughout the cycle. But we got a lot of resistance to the idea of merging a large body of code that had been developed outside the Neutron development and review process. We've instead had to break it into multiple pieces, and make sure each of those is production ready, to have any chance of getting through the review process during Juno. Its not really clear that something significant developed externally can ever be "moved in tree", at least without major upheaval, including incompatible API changes, as it goes through the review/merge process.

Finally, consider that many interesting potential features for Neutron involve integrations with external back-ends, such as ODL or vendor-specific devices or controllers, along with a reference implementation that doesn't depend on external systems. To really validate that the API, the model, and the driver framework code for a new feature are all stable, it is necessary to implement and deploy several of these back-end integrations along with the reference implementation. But vendors may not be willing to invest substantially in this integration effort without the assurances about the quality and relative stability of the interfaces involved that comes from the core review process, and without the clear path to market that comes with in-tree development of an approved blueprint targeted at a specific Neutron release.



OpenStack-dev mailing list

Reply via email to