Open Stack

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.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/fcf6aa2f/attachment.html>