Open Stack

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 <kukura at noironetworks.com 
> <mailto:kukura at noironetworks.com>>
> Reply-To: OpenStack List <openstack-dev at lists.openstack.org 
> <mailto:openstack-dev at lists.openstack.org>>
> Date: Tuesday, August 5, 2014 at 8:13 PM
> To: OpenStack List <openstack-dev at lists.openstack.org 
> <mailto:openstack-dev at 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 <kukura at noironetworks.com 
>> <mailto:kukura at noironetworks.com>>
>> Reply-To: OpenStack List <openstack-dev at lists.openstack.org 
>> <mailto:openstack-dev at lists.openstack.org>>
>> Date: Tuesday, August 5, 2014 at 5:20 PM
>> To: OpenStack List <openstack-dev at lists.openstack.org 
>> <mailto:openstack-dev at 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 at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.orghttp://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140805/449ca448/attachment-0001.html>