Open Stack

+1 mark


On Tue, Aug 5, 2014 at 4:27 AM, Mark McClain <mmcclain at 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 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/20140805/c680f1ea/attachment.html>