Is there any description of how this will be consumed by Nova. My concern is 
this code landing there.

From: Robert Kukura <kuk...@noironetworks.com<mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List 
Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List 
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

On 8/4/14, 4:27 PM, Mark McClain wrote:


* 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.


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).

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 

Merging large changes into the master branch is the exact opposite of failing 

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.



OpenStack-dev mailing list

OpenStack-dev mailing list

Reply via email to