On 8/5/14, 1:23 PM, Gary Kotton wrote:
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.
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.
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.
-Bob
Thanks
Gary
From: Robert Kukura <kuk...@noironetworks.com
<mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 5, 2014 at 8:13 PM
To: OpenStack List <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
forward
On 8/5/14, 11:04 AM, Gary Kotton wrote:
Hi,
Is there any description of how this will be consumed by Nova. My
concern is this code landing there.
Hi Gary,
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> ...".
-Bob
Thanks
Gary
From: Robert Kukura <kuk...@noironetworks.com
<mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List <openstack-dev@lists.openstack.org
<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
forward
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
<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>
[3]
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
