<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, 1:23 PM, Gary Kotton wrote:<br>
</div>
<blockquote cite="mid:D006ED76.1D332%25gkotton@vmware.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div>Ok, thanks for the clarification. This means that it will not
be done automagically as it is today – the tenant will need to
create a Neutron port and then pass that through.</div>
</blockquote>
Not quite. Using the group policy API, the port will be created
implicitly when the endpoint is created (unless an existing port_id
is passed explicitly). All the user will need to do is obtain the
port_id value from the endpoint and pass this to nova.<br>
<br>
The goal is to make passing "--nic epg-id=<endpoint-group-id>"
just as automatic as passing "--nic net-id=<network-uuid>".
Code in Nova's Neutron integration would handle the epg-id by
passing it to create_endpoint, and then using the port_id that is
returned in the result.<br>
<br>
-Bob<br>
<blockquote cite="mid:D006ED76.1D332%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 8:13 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"><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">
<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 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>