Open Stack

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.

-Bob
>
> Regards,
>