+1 mark
On Tue, Aug 5, 2014 at 4:27 AM, Mark McClain <mmccl...@yahoo-inc.com> wrote: > All- > > tl;dr > > * Group Based Policy API is the kind of experimentation we be should > attempting. > * Experiments should be able to fail fast. > * The master branch does not fail fast. > * StackForge is the proper home to conduct this experiment. > > > Why this email? > --------------- > Our community has been discussing and working on Group Based Policy (GBP) > for many months. I think the discussion has reached a point where we need > to openly discuss a few issues before moving forward. I recognize that > this discussion could create frustration for those who have invested > significant time and energy, but the reality is we need ensure we are > making decisions that benefit all members of our community (users, > operators, developers and vendors). > > Experimentation > ---------------- > I like that as a community we are exploring alternate APIs. The process > of exploring via real user experimentation can produce valuable results. A > good experiment should be designed to fail fast to enable further trials > via rapid iteration. > > Merging large changes into the master branch is the exact opposite of > failing fast. > > The master branch deliberately favors small iterative changes over time. > Releasing a new version of the proposed API every six months limits our > ability to learn and make adjustments. > > In the past, we’ve released LBaaS, FWaaS, and VPNaaS as experimental APIs. > The results have been very mixed as operators either shy away from > testing/offering the API or embrace the API with the expectation that the > community will provide full API support and migration. In both cases, the > experiment fails because we either could not get the data we need or are > unable to make significant changes without accepting a non-trivial amount > of technical debt via migrations or draft API support. > > Next Steps > ---------- > Previously, the GPB subteam used a Github account to host the development, > but the workflows and tooling do not align with OpenStack's development > model. I’d like to see us create a group based policy project in > StackForge. StackForge will host the code and enable us to follow the same > open review and QA processes we use in the main project while we are > developing and testing the API. The infrastructure there will benefit us as > we will have a separate review velocity and can frequently publish > libraries to PyPI. From a technical perspective, the 13 new entities in > GPB [1] do not require any changes to internal Neutron data structures. > The docs[2] also suggest that an external plugin or service would work to > make it easier to speed development. > > End State > --------- > APIs require time to fully bake and right now it is too early to know the > final outcome. Using StackForge will allow the team to retain all of its > options including: merging the code into Neutron, adopting the repository > as sub-project of the Network Program, leaving the project in StackForge > project or learning that users want something completely different. I > would expect that we'll revisit the status of the repo during the L or M > cycles since the Kilo development cycle does not leave enough time to > experiment and iterate. > > > mark > > [1] > http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370 > [2] > https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078 > [3] > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
