<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura <span dir="ltr"><<a href="mailto:kukura@noironetworks.com" target="_blank">kukura@noironetworks.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
On 8/4/14, 4:27 PM, Mark McClain wrote:<br>
<blockquote type="cite">
All-<br>
<br>
tl;dr<br>
<br>
* Group Based Policy API is the kind of experimentation we be
should attempting.<br>
* Experiments should be able to fail fast.<br>
* The master branch does not fail fast.<br>
* StackForge is the proper home to conduct this experiment.<br>
</blockquote></div>
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. </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
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.<br>
<br>
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.<br>
<br>
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. </div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
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.<br>
<br>
-Bob</div></blockquote><div><br></div><div><br></div><div>As a member of nova-core, I find this whole discussion very startling. Putting aside the concerns over technical details and the pain of having in tree experimental APIs (such as nova v3 API), neutron still isn't the de-facto networking solution from nova's perspective and it won't be until neutron has feature and performance parity with nova-network. In fact due to the slow maturation of neutron, nova has moved nova-network from 'frozen' to open for development (with a few caveats). So unless this new API directly solves some of the gaps in [0], I see no reason to push this into Juno. Juno hardly seems to be the appropriate time to introduce a new not-so-stable API; Juno is the time to address all the gaps [0] and hit feature and performance parity with nova-network.</div>
<div><br></div><div><br></div><div>[0] <a href="https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage">https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage</a><br>
</div><div><br></div><div><br></div><div>best,</div><div>Joe</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><div><br>
<blockquote type="cite">
<br>
<br>
Why this email?<br>
---------------<br>
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).<br>
<br>
Experimentation<br>
----------------<br>
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.<br>
<br>
Merging large changes into the master branch is the exact opposite
of failing fast.<br>
<br>
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. <br>
<br>
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.<br>
<br>
Next Steps<br>
----------<br>
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.
<div><br>
End State<br>
---------<br>
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.<br>
<br>
<br>
mark<br>
<br>
[1] <a href="http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370" target="_blank">http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370</a><br>
[2] <a href="https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078" target="_blank">https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078</a>
<div>[3] </div>
</div>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
OpenStack-dev mailing list
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>