<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 8/5/14, 11:04 AM, Gary Kotton wrote:<br>
</div>
<blockquote cite="mid:D006CCF3.1D2B0%25gkotton@vmware.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>Hi,</div>
<div>Is there any description of how this will be consumed by
Nova. My concern is this code landing there.</div>
</blockquote>
Hi Gary,<br>
<br>
Initially, an endpoint's port_id is passed to Nova using "nova boot
... --nic port-id=<port-uuid> ...", requiring no changes to
Nova. Later, slight enhancements to Nova would allow using commands
such as "nova boot ... --nic ep-id=<endpoint-uuid> ..." or
"nova boot ... --nic epg-id=<endpoint-group-uuid> ...".<br>
<br>
-Bob<br>
<blockquote cite="mid:D006CCF3.1D2B0%25gkotton@vmware.com"
type="cite">
<div>Thanks</div>
<div>Gary</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt;
text-align:left; color:black; BORDER-BOTTOM: medium none;
BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT:
0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid;
BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Robert Kukura
<<a moz-do-not-send="true"
href="mailto:kukura@noironetworks.com">kukura@noironetworks.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack
List <<a moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>Tuesday, August
5, 2014 at 5:20 PM<br>
<span style="font-weight:bold">To: </span>OpenStack List <<a
moz-do-not-send="true"
href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>Re:
[openstack-dev] [Neutron] Group Based Policy and the way
forward<br>
</div>
<div><br>
</div>
<div>
<div bgcolor="#FFFFFF" text="#000000">On 8/4/14, 4:27 PM, Mark
McClain wrote:<br>
<blockquote
cite="mid:370BE714-2271-4F09-B753-BE9D68778A1C@yahoo-inc.com"
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>
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.<br>
<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.<br>
<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<br>
<blockquote
cite="mid:370BE714-2271-4F09-B753-BE9D68778A1C@yahoo-inc.com"
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 moz-do-not-send="true"
href="http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370">http://git.openstack.org/cgit/openstack/neutron-specs/tree/specs/juno/group-based-policy-abstraction.rst#n370</a><br>
[2] <a moz-do-not-send="true"
href="https://urldefense.proofpoint.com/v1/url?u=https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit%23slide%3Did.g12c5a79d7_4078&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=cIUH5RoLkViWURawHObcnSgnma3z8rgd7F6cm454AZA%3D%0A&s=8159972efd976c5b98ebb1ab48249c7a32c90d4ff5d5c23a04d140dc241ab1ae">https://docs.google.com/presentation/d/1Nn1HjghAvk2RTPwvltSrnCUJkidWKWY2ckU7OYAVNpo/edit#slide=id.g12c5a79d7_4078</a>
<div>[3] </div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></pre>
</blockquote>
<br>
</div>
</div>
</span>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>