Open Stack

On 8/4/14, 4:27 PM, Mark McClain 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.
The disconnect here is that the Neutron group-based policy sub-team that 
has been implementing this feature for Juno does not see this work as an 
experiment to gather data, but rather as an important innovative feature 
to put in the hands of early adopters in Juno and into widespread 
deployment with a stable API as early as Kilo.

The group-based policy BP approved for Juno addresses the critical need 
for a more usable, declarative, intent-based interface for cloud 
application developers and deployers, that can co-exist with Neutron's 
current networking-hardware-oriented API and work nicely with all 
existing core plugins. Additionally, we believe that this declarative 
approach is what is needed to properly integrate advanced services into 
Neutron, and will go a long way towards resolving the difficulties so 
far trying to integrate LBaaS, FWaaS, and VPNaaS APIs into the current 
Neutron model.

Like any new service API in Neutron, the initial group policy API 
release will be subject to incompatible changes before being declared 
"stable", and hence would be labeled "experimental" in Juno. This does 
not mean that it is an experiment where to "fail fast" is an acceptable 
outcome. The sub-team's goal is to stabilize the group policy API as 
quickly as possible,  making any needed changes based on early user and 
operator experience.

The L and M cycles that Mark suggests below to "revisit the status" are 
a completely different time frame. By the L or M cycle, we should be 
working on a new V3 Neutron API that pulls these APIs together into a 
more cohesive core API. We will not be in a position to do this properly 
without the experience of using the proposed group policy extension with 
the V2 Neutron API in production.

If we were failing miserably, or if serious technical issues were being 
identified with the patches, some delay might make sense. But, other 
than Mark's -2 blocking the initial patches from merging, we are on 
track to complete the planned work in Juno.

-Bob
>
>
> 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/1561a739/attachment.html>