Open Stack

Hi,

Robert Kukura's proposal does address the following:

1. Make it explicit to the user that an API is in "preview" until it's
moved out of the preview directories
2. One of the criteria to accept a BP for preview is for the functionality
to be optional via configuration. This will not impact the stability of
neutron in the general case
3. Allows for new API/functionality to be built leveraging all the neutron
infrastructure available
4. Allows for users to adopt new API, increasing the footprint of neutron
users

+1 on this proposal from my side.

Regards,
-hemanth


On Fri, Aug 8, 2014 at 3:28 PM, Salvatore Orlando <sorlando at nicira.com>
wrote:

> "If we want to keep everything the way it is, we have to change
> everything" [1]
>
> This is pretty much how I felt after reading this proposal, and I felt
> that this quote, which Ivar will probably appreciate, was apt to the
> situation.
> Recent events have spurred a discussion about the need for a change in
> process. It is not uncommon indeed to believe that by fixing the process,
> things will inevitably change for better. While no-one argues that flaws in
> processes need to be fixed, no process change will ever change anything, in
> my opinion, unless it is aimed at spurring change in people as well.
>
> From what I understand, this proposal starts with the assumption that any
> new feature which is committed to Neutron (ie: has a blueprint approved),
> and is not a required neutron component should be considered as a preview.
> This is not different from the process, which, albeit more informally, has
> been adopted so far. Load Balancing, Firewall, VPN, have all been
> explicitly documented as experimental in their first release; I would argue
> that even if not experimental anymore, they may not be considered stable
> until their stability was proven by upstream QA with API and scenario tests
> - but this is not sanctioned anywhere currently, I think.
>
> According to this proposal, for preview features:
> - all the code would be moved to a "preview" package
> - Options will be marked as "preview"
> - URIs should be prefixed with "preview"
> - CLIs will note the features are "preview" in their help strings
> - Documentation will explicitly state this feature is "preview" (I think
> we already mark them as experimental, frankly I don't think there are a lot
> of differences in terminology here)
> - Database migrations will be in the main alembic path as usual
> - CLI, Devstack and Heat support will be available
> - Can be used by non-preview neutron code
> - Will undergo the usual review process
> - QA will be desirable, but will done either with "WIP" tempest patches or
> merging the relevant scenario tests in the preview feature iself
> - The feature might be promoted or removed, but the process for this is
> not yet defined.
>
> I don't think this change in process will actually encourage better
> behaviour both by contributors and core reviewers.
> I reckon that better behaviour might be encouraged by forcing developer
> and reviewers to merge in the neutron source code tree only code which
> meets the highest quality standards. A change in process should enforce
> this - and when I think about the criteria, I think at the same kind of
> criteria we're being imposed to declare parity with nova. Proven
> reliability, and scalability should be a must. Proven usability should be a
> requirement for all new APIs.
> On the other hand we also need to avoid to over bureaucratise Neutron -
> nobody loves that - and therefore ensure this process is enforced only when
> really needed.
>
> Looking at this proposal I see a few thing I'm not comfortable with:
> - having no clear criterion for exclusion a feature might imply that will
> be silently bit-rotting code in the preview package. Which what would
> happen for instance if we end up with a badly maintained feature , but
> since one or two core devs care about it, they'll keep vetoing the removal
> - using the normal review process will still not solve the problem of slow
> review cycles, pointless downvotes for reviewers which actually just do not
> understand the subject matter, and other pains associated with lack of
> interest from small or large parts of the core team. For instance, I think
> there is a line of pretty annoyed contributors as we did not even bother
> reviewing their specs.
> - The current provision about QA seems to state that it's ok to keep code
> in the main repo that does not adhere to appropriate quality standards.
> Which is the mistake we did with lbaas and other features, and I would like
> to avoid. And to me it is not sufficient that the code is buried in the
> 'preview' package.
> - Mostly important, this process provides a justification for contributors
> to push features which do not meet the same standards as other neutron
> parts and expect them to be merged and eventually promoted, and on the
> other hand provides the core team with the entitlement for merging them -
> therefore my main concern that it does not encourages better behaviour in
> people, which should be the ultimate aim of a process change.
>
> If you managed to read through all of this, and tolerated my dorky
> literature references, I really appreciate your patience, and would like to
> conclude that here we're discussing proposals for a process change, whereas
> I expect to discuss in the next neutron meeting the following:
> - whether is acceptable to change the process now
> - what did go wrong in our spec review process, as we ended up with at
> least an approved spec which is actually fiercely opposed by other core
> team members.
>
> Have a good weekend,
> Salvatore
>
> [1] Quote from "Il Gattopardo" by Giuseppe Tomasi di Lampedusa (english
> name: The Leopard)
>
>
> On 8 August 2014 22:21, Robert Kukura <kukura at noironetworks.com> wrote:
>
>
> [Note - I understand there are ongoing discussion that may lead to a
>> proposal for an out-of-tree incubation process for new Neutron features.
>> This is a complementary proposal that describes how our existing
>> development process can be used to stabilize new features in-tree over the
>> time frame of a release cycle or two. We should fully consider both
>> proposals, and where each might apply. I hope something like the approach I
>> propose here will allow the implementations of Neutron BPs with non-trivial
>> APIs that have been targeted for the Juno release to be included in that
>> release, used by early adopters, and stabilized as quickly as possible for
>> general consumption.]
>>
>> According to our existing development process, once a blueprint and
>> associated specification for a new Neutron feature have been reviewed,
>> approved, and targeted to a release, development proceeds, resulting in a
>> series of patches to be reviewed and merged to the Neutron source tree.
>> This source tree is then the basis for milestone releases and the final
>> release for the cycle.
>>
>> Ideally, this development process would conclude successfully, well in
>> advance of the cycle's final release, and the resulting feature and its API
>> would be considered fully "stable" in that release. Stable features are
>> ready for widespread general deployment. Going forward, any further
>> modifications to a stable API must be backwards-compatible with previously
>> released versions. Upgrades must not lose any persistent state associated
>> with stable features. Upgrade processes and their impact on a deployments
>> (downtime, etc.) should be consistent for all stable features.
>>
>> In reality, we developers are not perfect, and minor (or more
>> significant) changes may be identified as necessary or highly desirable
>> once early adopters of the new feature have had a chance to use it. These
>> changes may be difficult or impossible to do in a way that honors the
>> guarantees associated with stable features.
>>
>> For new features that effect the "core" Neutron API and therefore impact
>> all Neutron deployments, the stability requirement is strict. But for
>> features that do not effect the core API, such as services whose deployment
>> is optional, the stability requirement can be relaxed initially, allowing
>> time for feedback from early adopters to be incorporated before declaring
>> these APIs stable. The key in doing this is to manage the expectations of
>> developers, packagers, operators, and end users regarding these new
>> optional features while they stabilize.
>>
>> I therefore propose that we manage these expectations, while new optional
>> features in the source tree stabilize, by clearly labeling these features
>> with the term "preview" until they are declared stable, and sufficiently
>> isolating them so that they are not confused with stable features. The
>> proposed guidelines would apply during development as the patches
>> implementing the feature are first merged, in the initial release
>> containing the feature, and in any subsequent releases that are necessary
>> to fully stabilize the feature.
>>
>> Here are my initial not-fully-baked ideas for how our current process can
>> be adapted with a "preview feature" concept supporting in-tree
>> stabilization of optional features:
>>
>> * Preview features are implementations of blueprints that have been
>> reviewed, approved, and targeted for a Neutron release. The process is
>> intended for features for which there is a commitment to add the feature to
>> Neutron, not for experimentation where "failing fast" is an acceptable
>> outcome.
>>
>> * Preview features must be optional to deploy, such as by configuring a
>> service plugin or some set of drivers. Blueprint implementations whose
>> deployment is not optional are not eligible to be treated as preview
>> features.
>>
>> * Patches implementing a preview feature are merged to the the master
>> branch of the Neutron source tree. This makes them immediately available to
>> all direct consumers of the source tree, such as developers, trunk-chasing
>> operators, packagers, and evaluators or end-users that use DevStack,
>> maximizing the opportunity to get the feedback that is essential to quickly
>> stabilize the feature.
>>
>> * The process for reviewing, approving and merging patches implementing
>> preview features is exactly the same as for all other Neutron patches. The
>> patches must meet HACKING standards, be production-quality code, have
>> adequate test coverage, have DB migration scripts, etc., and require two
>> +2s and a +A from Neutron core developers to merge.
>>
>> * DB migrations for preview features are treated similarly to other DB
>> migrations, forming a single ordered list that results in the current
>> overall DB schema, including the schema for the preview feature. But DB
>> migrations for a preview feature are not yet required to preserve existing
>> persistent state in a deployment, as would be required for a stable feature.
>>
>> * All code that is part of a preview feature is located under
>> neutron/preview/<feature>/. Associated unit tests are located under
>> neutron/tests/unit/preview/<feature>/, and similarly for other test
>> categories. This makes the feature's status clear to developers and other
>> direct consumers of the source tree, and also allows packagers to easily
>> partition all preview features or individual preview features into separate
>> optionally installable packages.
>>
>> * The tree structures underneath these locations should make it
>> straightforward to move the preview feature code to its proper tree
>> location once it is considered stable.
>>
>> * Tempest API and scenario tests for preview features are highly
>> desirable. We need to agree on how to accomplish this without preventing
>> necessary API changes. Posting WIP patches to the Tempest project may be
>> sufficient initially. Putting Tempest-like tests in the Neutron tree until
>> preview features stabilize, then moving them to Tempest when stabilization
>> is complete, might be a better long term solution.
>>
>> * No non-preview Neutron code should import code from anywhere under the
>> neutron.preview module, unless necessary for special cases like DB
>> migrations.
>>
>> * URIs for the resources provided by preview features should contain the
>> string "preview".
>>
>> * Configuration file content related to preview features should be
>> clearly labeled as "preview".
>>
>> * Preview features should be documented similarly to any stable Neutron
>> feature, but documents or sections of documents related to preview features
>> should have an easily recognizable label that clearly identifies the
>> feature as a "preview".
>>
>> * Support for preview features in client libraries, and in other projects
>> such as Horizon, Heat, and DevStack, are essential to get the feedback
>> needed from early adopters during feature stabilization. They are
>> implemented normally, but should be labeled "preview" appropriately, such
>> as in GUIs, in CLI help strings and in documentation so that end user
>> expectations regarding stability are managed.
>>
>> * A process is needed to prevent long-term stagnation of features in the
>> preview sub-tree. It is reasonable to expect a new feature to remain for
>> one or two cycles, possibly with little change (other than bug fixes),
>> before stabilizing. A suggested rule is that a new approved BP is required
>> after two cycles, or the feature gets removed from the Neutron source tree
>> (maybe moved (back) to an incubation repository).
>>
>>
>> I would appreciate feedback via this email thread on whether this
>> "preview feature" concept is worth further consideration, refinement and
>> potential usage for approved feature blueprints, especially during the Juno
>> cycle. I've also posted the proposal text at https://etherpad.openstack.
>> org/p/neutron-preview-features for those interested in helping refine
>> the proposal.
>>
>> Thanks,
>>
>> -Bob
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140808/1d705640/attachment.html>