Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Kevin Benton]

The only issue with the separate service proxying API calls is that it
can't receive requests between the service and core plugins.

What kind of stability requirements were you concerned about? A response
change would be similar to having a custom policy.json file where things
that violate constraints would result in a 403.
On Aug 8, 2014 1:04 PM, "Maru Newby"  wrote:

> On Aug 8, 2014, at 10:56 AM, Kevin Benton  wrote:
>
> > There is an enforcement component to the group policy that allows you to
> use the current APIs and it's the reason that group policy is integrated
> into the neutron project. If someone uses the current APIs, the group
> policy plugin will make sure they don't violate any policy constraints
> before passing the request into the regular core/service plugins.
>
>
> The enforcement requirement might be easier to implement through
> code-based integration, but a separate service could provide the same
> guarantee against constraint violation by proxying v2 API calls for an
> endpoint to which access was restricted.
>
> Apologies if I've missed discussion of this (it's a big thread), but won't
> enforcement by group policy on the v2 API have the potential to violate
> stability requirements?  If new errors related to enforcement can result
> from API calls, that would seem to be a change in behavior.  Do we have a
> precedent for allowing extensions or new services to modify core behavior
> in this way?
>
>
> m.
>
> >
> >
> > On Fri, Aug 8, 2014 at 11:02 AM, Salvatore Orlando 
> wrote:
> > It might be because of the wording used, but it seems to me that you're
> making it sound like the group policy effort could have been completely
> orthogonal to neutron as we know it now.
> >
> > What I understood is that the declarative abstraction offered by group
> policy could do without any existing neutron entity leveraging "native"
> drivers, but can actually be used also with existing neutron plugins
> through the mapping driver - which will provide a sort of backward
> compatibility. And still in that case I'm not sure one would be able to use
> "traditional" neutron API (or "legacy" as it has been called), since I
> don't know if the mapping driver is bidirectional.
> >
> > I know this probably stems from my ignorance on the subject - I had
> unfortunately very little time to catch-up with this effort in the past
> months.
> >
> > Salvatore
> >
> >
> > On 8 August 2014 18:49, Ivar Lazzaro  wrote:
> > Hi Jay,
> >
> > You can choose. The whole purpose of this is about flexibility, if you
> want to use GBP API 'only' with a specific driver you just can.
> > Additionally, given the 'ML2 like' architecture, the reference mapping
> driver can ideally run alongside by filling the core Neutron constructs
> without ever 'disturbing' your own driver (I'm not entirely sure about this
> but it seems feasible).
> >
> > I hope this answers your question,
> > Ivar.
> >
> >
> > On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes  wrote:
> > On 08/08/2014 08:55 AM, Kevin Benton wrote:
> > The existing constructs will not change.
> >
> > A followup question on the above...
> >
> > If GPB API is merged into Neutron, the next logical steps (from what I
> can tell) will be to add drivers that handle policy-based payloads/requests.
> >
> > Some of these drivers, AFAICT, will *not* be deconstructing these policy
> requests into the low-level port, network, and subnet
> creation/attachment/detachment commands, but instead will be calling out
> as-is to hardware that speaks the higher-level abstraction API [1], not the
> lower-level port/subnet/network APIs. The low-level APIs would essentially
> be consumed entirely within the policy-based driver, which would
> effectively mean that the only way a system would be able to orchestrate
> networking in systems using these drivers would be via the high-level
> policy API.
> >
> > Is that correct? Very sorry if I haven't explained clearly my
> question... this is a tough question to frame eloquently :(
> >
> > Thanks,
> > -jay
> >
> > [1]
> http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html
> >
> > On Aug 8, 2014 9:49 AM, "CARVER, PAUL"  > > wrote:
> >
> > Wuhongning [mailto:wuhongn...@huawei.com
> > ] wrote:
> >
> >  >Does it make sense to move all advanced extension out of ML2, like
> > security
> >  >group, qos...? Then we can just talk about advanced service
> > itself, without
> >  >bothering basic neutron object (network/subnet/port)
> >
> > A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I
> > still
> > think it's too late in the game to be shooting down all the work
> > that the
> > GBP team has put in unless there's a really clean and effective way
> of
> > running AND iterating on GBP in conjunction with Neutron without
> being
> > part of the Juno release. As far as I can tell they've 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Maru Newby]

On Aug 8, 2014, at 10:56 AM, Kevin Benton  wrote:

> There is an enforcement component to the group policy that allows you to use 
> the current APIs and it's the reason that group policy is integrated into the 
> neutron project. If someone uses the current APIs, the group policy plugin 
> will make sure they don't violate any policy constraints before passing the 
> request into the regular core/service plugins.


The enforcement requirement might be easier to implement through code-based 
integration, but a separate service could provide the same guarantee against 
constraint violation by proxying v2 API calls for an endpoint to which access 
was restricted.

Apologies if I've missed discussion of this (it's a big thread), but won't 
enforcement by group policy on the v2 API have the potential to violate 
stability requirements?  If new errors related to enforcement can result from 
API calls, that would seem to be a change in behavior.  Do we have a precedent 
for allowing extensions or new services to modify core behavior in this way?


m. 

> 
> 
> On Fri, Aug 8, 2014 at 11:02 AM, Salvatore Orlando  
> wrote:
> It might be because of the wording used, but it seems to me that you're 
> making it sound like the group policy effort could have been completely 
> orthogonal to neutron as we know it now.
> 
> What I understood is that the declarative abstraction offered by group policy 
> could do without any existing neutron entity leveraging "native" drivers, but 
> can actually be used also with existing neutron plugins through the mapping 
> driver - which will provide a sort of backward compatibility. And still in 
> that case I'm not sure one would be able to use "traditional" neutron API (or 
> "legacy" as it has been called), since I don't know if the mapping driver is 
> bidirectional.
> 
> I know this probably stems from my ignorance on the subject - I had 
> unfortunately very little time to catch-up with this effort in the past 
> months.
> 
> Salvatore
> 
> 
> On 8 August 2014 18:49, Ivar Lazzaro  wrote:
> Hi Jay,
> 
> You can choose. The whole purpose of this is about flexibility, if you want 
> to use GBP API 'only' with a specific driver you just can.
> Additionally, given the 'ML2 like' architecture, the reference mapping driver 
> can ideally run alongside by filling the core Neutron constructs without ever 
> 'disturbing' your own driver (I'm not entirely sure about this but it seems 
> feasible).
> 
> I hope this answers your question,
> Ivar.
> 
> 
> On Fri, Aug 8, 2014 at 6:28 PM, Jay Pipes  wrote:
> On 08/08/2014 08:55 AM, Kevin Benton wrote:
> The existing constructs will not change.
> 
> A followup question on the above...
> 
> If GPB API is merged into Neutron, the next logical steps (from what I can 
> tell) will be to add drivers that handle policy-based payloads/requests.
> 
> Some of these drivers, AFAICT, will *not* be deconstructing these policy 
> requests into the low-level port, network, and subnet 
> creation/attachment/detachment commands, but instead will be calling out 
> as-is to hardware that speaks the higher-level abstraction API [1], not the 
> lower-level port/subnet/network APIs. The low-level APIs would essentially be 
> consumed entirely within the policy-based driver, which would effectively 
> mean that the only way a system would be able to orchestrate networking in 
> systems using these drivers would be via the high-level policy API.
> 
> Is that correct? Very sorry if I haven't explained clearly my question... 
> this is a tough question to frame eloquently :(
> 
> Thanks,
> -jay
> 
> [1] 
> http://www.cisco.com/c/en/us/solutions/data-center-virtualization/application-centric-infrastructure/index.html
> 
> On Aug 8, 2014 9:49 AM, "CARVER, PAUL"  > wrote:
> 
> Wuhongning [mailto:wuhongn...@huawei.com
> ] wrote:
> 
>  >Does it make sense to move all advanced extension out of ML2, like
> security
>  >group, qos...? Then we can just talk about advanced service
> itself, without
>  >bothering basic neutron object (network/subnet/port)
> 
> A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I
> still
> think it's too late in the game to be shooting down all the work
> that the
> GBP team has put in unless there's a really clean and effective way of
> running AND iterating on GBP in conjunction with Neutron without being
> part of the Juno release. As far as I can tell they've worked really
> hard to follow the process and accommodate input. They shouldn't have
> to wait multiple more releases on a hypothetical refactoring of how
> L3+ vs
> L2 is structured.
> 
> But, just so I'm not making a horrible mistake, can someone reassure me
> that GBP isn't removing the constructs of network/subnet/port from
> Neutron?
> 
> I'm under the impression that GBP is adding a higher level abstraction
> but that it's 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Edgar Magana]

Ivar,

You are totally right. I just want to clarify that I haven’t express any 
disagreement on the plugin, I actually (as Sumit mentioned) +2 this patch 
before. I just pointed our that I have expressed previously that GBP should use 
the standard Policy Terminology. I did not push hard enough at the right time 
because I consider it a minor thing but Jay has a valid point and I think it 
has to be reconsidered IMHO.

Let’s be careful with our public statements!

Edgar

From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 2:52 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


Edgar,

Actually, As Pedro said, I think that the time for discussing these kind of 
concerns was the BP approval. The fact that it has been approved after many 
proposals and reviews means that a community effort wanted the GBP to be 
implemented in this release cycle the way it was presented at that time.

With this, I absolutely don't want to say that you should not express your 
disagreement! I'm just saying that it should be expressed differently (a BP to 
propose your model in K?). Otherwise, the whole BP process becomes just 
pointless.

Meanwhile, imho, blocking the patch feels really unfair.

Ivar.

On Aug 6, 2014 11:00 PM, "Edgar Magana" 
mailto:edgar.mag...@workday.com>> wrote:
Ivar,

Of course and this is why we are having this conversation, in order to merge 
our different opinions.

Edgar

From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 1:41 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Hi Edgar,

Actually, I think that other reviewers saw that name clash, and still thought 
it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be 
different from yours.

Regards,
Ivar.


On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.

Edgar

On 8/6/14, 11:32 AM, "Sumit Naiksatam" 
mailto:sumitnaiksa...@gmail.com>> wrote:

>Not sure what you are talking about? You claim now that you had
>suggestion which was not considered, yet you +2'ed a patch, by stating
>that "All looks good to me!".
>
>On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
>mailto:edgar.mag...@workday.com>>
>wrote:
>> That is the beauty of the open source projects, there is always a
>>smartest
>> reviewer catching out the facts that you don¹t.
>>
>> Edgar
>>
>> On 8/6/14, 10:55 AM, "Sumit Naiksatam" 
>> mailto:sumitnaiksa...@gmail.com>> wrote:
>>
>>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>>>
>>>"
>>>Edgar Magana
>>>Jul 2 8:42 AM
>>>
>>>Patch Set 13: Code-Review+2
>>>
>>>All looks good to me! I am not approving yet because Nachi was also
>>>reviewing this code and I would like to see his opinion as well.
>>>"
>>>
>>>That would suggest that you were happy with what was in it. I don't
>>>see anything in the review comments that suggests otherwise.
>>>
>>>[1]  https://review.openstack.org/#/c/95900/
>>>
>>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
>>>mailto:edgar.mag...@workday.com>>
>>>wrote:
>>>> This is the consequence of a proposal that is not following the
>>>>standardized
>>>> terminology (IETF - RFC) for any Policy-based System:
>>>> http://tools.ietf.org/html/rfc3198
>>>>
>>>> Well, I did bring  this point during the Hong Kong Summit but as you
>>>>can see
>>>> my comments were totally ignored:
>>>>
>>>>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
>>>>Ir
>>>>upCD9E/edit
>>>>
>>>> I clearly saw this kind of issues coming. Let me quote myself what I
>>>> suggested: "For instance: "endpoints" should be "enforcement point"
>>>>
>>>

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Ivar Lazzaro]

Edgar,

Actually, As Pedro said, I think that the time for discussing these kind of
concerns was the BP approval. The fact that it has been approved after many
proposals and reviews means that a community effort wanted the GBP to be
implemented in this release cycle the way it was presented at that time.

With this, I absolutely don't want to say that you should not express your
disagreement! I'm just saying that it should be expressed differently (a BP
to propose your model in K?). Otherwise, the whole BP process becomes just
pointless.

Meanwhile, imho, blocking the patch feels really unfair.

Ivar.
 On Aug 6, 2014 11:00 PM, "Edgar Magana"  wrote:

>  Ivar,
>
>  Of course and this is why we are having this conversation, in order to
> merge our different opinions.
>
>  Edgar
>
>   From: Ivar Lazzaro 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Date: Wednesday, August 6, 2014 at 1:41 PM
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev@lists.openstack.org>
> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
> forward
>
>   Hi Edgar,
>
>  Actually, I think that other reviewers saw that name clash, and still
> thought it was ok to use the same terminology in such a different context.
> BP reviews are a community effort right? So of course someones' idea may
> be different from yours.
>
>  Regards,
> Ivar.
>
>
> On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
> wrote:
>
>> Basically, I am admitting that I did not catch in my review the part of
>> the endpoint term that Jay was pointing out.
>>
>> Edgar
>>
>> On 8/6/14, 11:32 AM, "Sumit Naiksatam"  wrote:
>>
>> >Not sure what you are talking about? You claim now that you had
>> >suggestion which was not considered, yet you +2'ed a patch, by stating
>> >that "All looks good to me!".
>> >
>> >On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
>> >wrote:
>> >> That is the beauty of the open source projects, there is always a
>> >>smartest
>> >> reviewer catching out the facts that you don¹t.
>> >>
>> >> Edgar
>> >>
>> >> On 8/6/14, 10:55 AM, "Sumit Naiksatam" 
>> wrote:
>> >>
>> >>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>> >>>
>> >>>"
>> >>>Edgar Magana
>> >>>Jul 2 8:42 AM
>> >>>
>> >>>Patch Set 13: Code-Review+2
>> >>>
>> >>>All looks good to me! I am not approving yet because Nachi was also
>> >>>reviewing this code and I would like to see his opinion as well.
>> >>>"
>> >>>
>> >>>That would suggest that you were happy with what was in it. I don't
>> >>>see anything in the review comments that suggests otherwise.
>> >>>
>> >>>[1]  https://review.openstack.org/#/c/95900/
>> >>>
>> >>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana <
>> edgar.mag...@workday.com>
>> >>>wrote:
>> >>>> This is the consequence of a proposal that is not following the
>> >>>>standardized
>> >>>> terminology (IETF - RFC) for any Policy-based System:
>> >>>> http://tools.ietf.org/html/rfc3198
>> >>>>
>> >>>> Well, I did bring  this point during the Hong Kong Summit but as you
>> >>>>can see
>> >>>> my comments were totally ignored:
>> >>>>
>> >>>>
>> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
>> >>>>Ir
>> >>>>upCD9E/edit
>> >>>>
>> >>>> I clearly saw this kind of issues coming. Let me quote myself what I
>> >>>> suggested: "For instance: "endpoints" should be "enforcement point"
>> >>>>
>> >>>> I do not understand why GBP did not include this suggestionŠ
>> >>>>
>> >>>> Edgar
>> >>>>
>> >>>> From: Kevin Benton 
>> >>>> Reply-To: "OpenStack Development Mailing List (not for usage
>> >>>>questions)"
>> >>>> 
>> >>>> Date: Wednesday, August 6, 2014 at 10:22 AM
>> >>>> To: "OpenStack Development Mailing List (not for us

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Edgar Magana]

Ivar,

Of course and this is why we are having this conversation, in order to merge 
our different opinions.

Edgar

From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 1:41 PM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Hi Edgar,

Actually, I think that other reviewers saw that name clash, and still thought 
it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be 
different from yours.

Regards,
Ivar.


On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
mailto:edgar.mag...@workday.com>> wrote:
Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.

Edgar

On 8/6/14, 11:32 AM, "Sumit Naiksatam" 
mailto:sumitnaiksa...@gmail.com>> wrote:

>Not sure what you are talking about? You claim now that you had
>suggestion which was not considered, yet you +2'ed a patch, by stating
>that "All looks good to me!".
>
>On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
>mailto:edgar.mag...@workday.com>>
>wrote:
>> That is the beauty of the open source projects, there is always a
>>smartest
>> reviewer catching out the facts that you don¹t.
>>
>> Edgar
>>
>> On 8/6/14, 10:55 AM, "Sumit Naiksatam" 
>> mailto:sumitnaiksa...@gmail.com>> wrote:
>>
>>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>>>
>>>"
>>>Edgar Magana
>>>Jul 2 8:42 AM
>>>
>>>Patch Set 13: Code-Review+2
>>>
>>>All looks good to me! I am not approving yet because Nachi was also
>>>reviewing this code and I would like to see his opinion as well.
>>>"
>>>
>>>That would suggest that you were happy with what was in it. I don't
>>>see anything in the review comments that suggests otherwise.
>>>
>>>[1]  https://review.openstack.org/#/c/95900/
>>>
>>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
>>>mailto:edgar.mag...@workday.com>>
>>>wrote:
>>>> This is the consequence of a proposal that is not following the
>>>>standardized
>>>> terminology (IETF - RFC) for any Policy-based System:
>>>> http://tools.ietf.org/html/rfc3198
>>>>
>>>> Well, I did bring  this point during the Hong Kong Summit but as you
>>>>can see
>>>> my comments were totally ignored:
>>>>
>>>>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
>>>>Ir
>>>>upCD9E/edit
>>>>
>>>> I clearly saw this kind of issues coming. Let me quote myself what I
>>>> suggested: "For instance: "endpoints" should be "enforcement point"
>>>>
>>>> I do not understand why GBP did not include this suggestionŠ
>>>>
>>>> Edgar
>>>>
>>>> From: Kevin Benton mailto:blak...@gmail.com>>
>>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>>questions)"
>>>> mailto:openstack-dev@lists.openstack.org>>
>>>> Date: Wednesday, August 6, 2014 at 10:22 AM
>>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>> mailto:openstack-dev@lists.openstack.org>>
>>>>
>>>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>>>> forward
>>>>
>>>> What I was referring to was also not Keystone's definition of an
>>>>endpoint.
>>>> It's almost as if the term has many uses and was not invented for
>>>>Keystone.
>>>> :-)
>>>>
>>>> http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
>>>>
>>>> Did a similar discussion occur when Heat wanted to use the word
>>>>'template'
>>>> since this was clearly already in use by Horizon?
>>>>
>>>> On Aug 6, 2014 9:24 AM, "Jay Pipes" 
>>>> mailto:jaypi...@gmail.com>> wrote:
>>>>>
>>>>> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>>>>>>
>>>>>> Given that, pointing to the Nova parity work seems a bit like a red
>&g

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Ivar Lazzaro]

Hi Edgar,

Actually, I think that other reviewers saw that name clash, and still
thought it was ok to use the same terminology in such a different context.
BP reviews are a community effort right? So of course someones' idea may be
different from yours.

Regards,
Ivar.


On Wed, Aug 6, 2014 at 10:29 PM, Edgar Magana 
wrote:

> Basically, I am admitting that I did not catch in my review the part of
> the endpoint term that Jay was pointing out.
>
> Edgar
>
> On 8/6/14, 11:32 AM, "Sumit Naiksatam"  wrote:
>
> >Not sure what you are talking about? You claim now that you had
> >suggestion which was not considered, yet you +2'ed a patch, by stating
> >that "All looks good to me!".
> >
> >On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
> >wrote:
> >> That is the beauty of the open source projects, there is always a
> >>smartest
> >> reviewer catching out the facts that you don¹t.
> >>
> >> Edgar
> >>
> >> On 8/6/14, 10:55 AM, "Sumit Naiksatam" 
> wrote:
> >>
> >>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
> >>>
> >>>"
> >>>Edgar Magana
> >>>Jul 2 8:42 AM
> >>>
> >>>Patch Set 13: Code-Review+2
> >>>
> >>>All looks good to me! I am not approving yet because Nachi was also
> >>>reviewing this code and I would like to see his opinion as well.
> >>>"
> >>>
> >>>That would suggest that you were happy with what was in it. I don't
> >>>see anything in the review comments that suggests otherwise.
> >>>
> >>>[1]  https://review.openstack.org/#/c/95900/
> >>>
> >>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana  >
> >>>wrote:
> >>>> This is the consequence of a proposal that is not following the
> >>>>standardized
> >>>> terminology (IETF - RFC) for any Policy-based System:
> >>>> http://tools.ietf.org/html/rfc3198
> >>>>
> >>>> Well, I did bring  this point during the Hong Kong Summit but as you
> >>>>can see
> >>>> my comments were totally ignored:
> >>>>
> >>>>
> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
> >>>>Ir
> >>>>upCD9E/edit
> >>>>
> >>>> I clearly saw this kind of issues coming. Let me quote myself what I
> >>>> suggested: "For instance: "endpoints" should be "enforcement point"
> >>>>
> >>>> I do not understand why GBP did not include this suggestionŠ
> >>>>
> >>>> Edgar
> >>>>
> >>>> From: Kevin Benton 
> >>>> Reply-To: "OpenStack Development Mailing List (not for usage
> >>>>questions)"
> >>>> 
> >>>> Date: Wednesday, August 6, 2014 at 10:22 AM
> >>>> To: "OpenStack Development Mailing List (not for usage questions)"
> >>>> 
> >>>>
> >>>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
> >>>> forward
> >>>>
> >>>> What I was referring to was also not Keystone's definition of an
> >>>>endpoint.
> >>>> It's almost as if the term has many uses and was not invented for
> >>>>Keystone.
> >>>> :-)
> >>>>
> >>>> http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
> >>>>
> >>>> Did a similar discussion occur when Heat wanted to use the word
> >>>>'template'
> >>>> since this was clearly already in use by Horizon?
> >>>>
> >>>> On Aug 6, 2014 9:24 AM, "Jay Pipes"  wrote:
> >>>>>
> >>>>> On 08/06/2014 02:12 AM, Kevin Benton wrote:
> >>>>>>
> >>>>>> Given that, pointing to the Nova parity work seems a bit like a red
> >>>>>> herring. This new API is being developed orthogonally to the
> >>>>>>existing
> >>>>>> API endpoints
> >>>>>
> >>>>>
> >>>>> You see how you used the term endpoints there? :P
> >>>>>
> >>>>> -jay
> >>>>>
> >>>>> ___
> >>>>> 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
> >>>>
> >>>
> >>>___
> >>>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
> >
> >___
> >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
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Edgar Magana]

Basically, I am admitting that I did not catch in my review the part of
the endpoint term that Jay was pointing out.

Edgar

On 8/6/14, 11:32 AM, "Sumit Naiksatam"  wrote:

>Not sure what you are talking about? You claim now that you had
>suggestion which was not considered, yet you +2'ed a patch, by stating
>that "All looks good to me!".
>
>On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana 
>wrote:
>> That is the beauty of the open source projects, there is always a
>>smartest
>> reviewer catching out the facts that you don¹t.
>>
>> Edgar
>>
>> On 8/6/14, 10:55 AM, "Sumit Naiksatam"  wrote:
>>
>>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>>>
>>>"
>>>Edgar Magana
>>>Jul 2 8:42 AM
>>>
>>>Patch Set 13: Code-Review+2
>>>
>>>All looks good to me! I am not approving yet because Nachi was also
>>>reviewing this code and I would like to see his opinion as well.
>>>"
>>>
>>>That would suggest that you were happy with what was in it. I don't
>>>see anything in the review comments that suggests otherwise.
>>>
>>>[1]  https://review.openstack.org/#/c/95900/
>>>
>>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
>>>wrote:
>>>> This is the consequence of a proposal that is not following the
>>>>standardized
>>>> terminology (IETF - RFC) for any Policy-based System:
>>>> http://tools.ietf.org/html/rfc3198
>>>>
>>>> Well, I did bring  this point during the Hong Kong Summit but as you
>>>>can see
>>>> my comments were totally ignored:
>>>>
>>>>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaB
>>>>Ir
>>>>upCD9E/edit
>>>>
>>>> I clearly saw this kind of issues coming. Let me quote myself what I
>>>> suggested: "For instance: "endpoints" should be "enforcement point"
>>>>
>>>> I do not understand why GBP did not include this suggestionŠ
>>>>
>>>> Edgar
>>>>
>>>> From: Kevin Benton 
>>>> Reply-To: "OpenStack Development Mailing List (not for usage
>>>>questions)"
>>>> 
>>>> Date: Wednesday, August 6, 2014 at 10:22 AM
>>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>>> 
>>>>
>>>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>>>> forward
>>>>
>>>> What I was referring to was also not Keystone's definition of an
>>>>endpoint.
>>>> It's almost as if the term has many uses and was not invented for
>>>>Keystone.
>>>> :-)
>>>>
>>>> http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
>>>>
>>>> Did a similar discussion occur when Heat wanted to use the word
>>>>'template'
>>>> since this was clearly already in use by Horizon?
>>>>
>>>> On Aug 6, 2014 9:24 AM, "Jay Pipes"  wrote:
>>>>>
>>>>> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>>>>>>
>>>>>> Given that, pointing to the Nova parity work seems a bit like a red
>>>>>> herring. This new API is being developed orthogonally to the
>>>>>>existing
>>>>>> API endpoints
>>>>>
>>>>>
>>>>> You see how you used the term endpoints there? :P
>>>>>
>>>>> -jay
>>>>>
>>>>> ___
>>>>> 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
>>>>
>>>
>>>___
>>>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
>
>___
>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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Henry Fourie]

+1

From: Edgar Magana [mailto:edgar.mag...@workday.com]
Sent: Wednesday, August 06, 2014 10:40 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

This is the consequence of a proposal that is not following the standardized 
terminology (IETF - RFC) for any Policy-based System:
http://tools.ietf.org/html/rfc3198

Well, I did bring  this point during the Hong Kong Summit but as you can see my 
comments were totally ignored:
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit

I clearly saw this kind of issues coming. Let me quote myself what I suggested: 
"For instance: "endpoints" should be "enforcement point"

I do not understand why GBP did not include this suggestion...

Edgar

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 10:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


What I was referring to was also not Keystone's definition of an endpoint. It's 
almost as if the term has many uses and was not invented for Keystone. :-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word 'template' 
since this was clearly already in use by Horizon?
On Aug 6, 2014 9:24 AM, "Jay Pipes" 
mailto:jaypi...@gmail.com>> wrote:
On 08/06/2014 02:12 AM, Kevin Benton wrote:
Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing
API endpoints

You see how you used the term endpoints there? :P

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Yapeng Wu]

Hi, Salvatore,

Thanks listing out the options.

Can you elaborate more on your 2nd option? Do you mean merge the patches and 
mark the API as ‘experimental’?

Yapeng


From: Salvatore Orlando [mailto:sorla...@nicira.com]
Sent: Wednesday, August 06, 2014 1:44 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

As Ronak said, this thread is starting to move in a lot of different 
directions, ranging from correctness of the blueprint approval process to 
nova/neutron integration, which are rather off topic.

In particular it seems things are being skewed towards a discussion around nova 
parity, whereas actually some people have just chimed in with their honest 
opinion that with all the stuff still needed to finally be able to make neutron 
"THE" openstack networking solution, the effort towards adding a new tenant 
facing API appears to have a lesser priority.

I just want to reassure everybody that the majority of the core team and a 
large part of the community have actually made this their first priority. For 
what is worth, some of them have even delayed plugin/driver specific 
development to this aim.

So I would invite to go back to the original subject of the discussion, that is 
to say decide as a community what would the best way forward for this effort.
I see so far the following options:
- merge the outstanding patches, assuming there are no further technical 
concerns, and include GBP in Juno.
- consider GBP an 'experimental' V3 tenant API (this was mentioned somewhere in 
this thread) and treat it accordingly
- delay to the next release
- move the development of the service plugin to stackforge as suggested to this 
thread.

More options are obviously welcome!

Regards,
Salvatore

On 6 August 2014 19:40, Ivar Lazzaro 
mailto:ivarlazz...@gmail.com>> wrote:
Which kind of uncertainty are you referring to?

Given that the blueprint was approved long ago, and the code has been ready and 
under review following those specs... I think GBP is probably the patch with 
the least effort to be merged right now.

Ivar.

On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon 
mailto:joe.gord...@gmail.com>> wrote:

On Aug 6, 2014 10:21 AM, "Ronak Shah" 
mailto:ronak.malav.s...@gmail.com>> wrote:
>
> We have diverged our attention towards nova-network-> neutron parity on this 
> thread unnecessarily.
>
> Can we discuss and collectively decide on what is the way forward for GBP in 
> Juno release?
>
> Efforts have been made by the subteam starting from throwing PoC at last 
> summit to spec approval to code review.
>
> There are usefulness to this feature and I think everyone is on the same page 
> there.
>
> Let us not discourage the effort by bringing in existing neutron issue in 
> play.

> Yes, we has a neutorn community needs to fix that with highest priority.
> But this is orthogonal effort.

The efforts may be orthogonal, but the review team and bandwidth of said team 
is one and the same. Making nova-network the highest priority means pushing 
other blueprints back as needed.  And since there is still so much uncertainty 
around GPB this late in the cycle, IMHO it's a good candidate for getting 
deferred.
> If endpoint is not a likeable preferred name than lets propose more 
> meaningful alternative.
> Let us try to find a middle ground on how this feature can be made generally 
> available.
>
> Thanks,
> Ronak
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Sumit Naiksatam]

Not sure what you are talking about? You claim now that you had
suggestion which was not considered, yet you +2'ed a patch, by stating
that "All looks good to me!".

On Wed, Aug 6, 2014 at 11:19 AM, Edgar Magana  wrote:
> That is the beauty of the open source projects, there is always a smartest
> reviewer catching out the facts that you don¹t.
>
> Edgar
>
> On 8/6/14, 10:55 AM, "Sumit Naiksatam"  wrote:
>
>>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>>
>>"
>>Edgar Magana
>>Jul 2 8:42 AM
>>
>>Patch Set 13: Code-Review+2
>>
>>All looks good to me! I am not approving yet because Nachi was also
>>reviewing this code and I would like to see his opinion as well.
>>"
>>
>>That would suggest that you were happy with what was in it. I don't
>>see anything in the review comments that suggests otherwise.
>>
>>[1]  https://review.openstack.org/#/c/95900/
>>
>>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
>>wrote:
>>> This is the consequence of a proposal that is not following the
>>>standardized
>>> terminology (IETF - RFC) for any Policy-based System:
>>> http://tools.ietf.org/html/rfc3198
>>>
>>> Well, I did bring  this point during the Hong Kong Summit but as you
>>>can see
>>> my comments were totally ignored:
>>>
>>>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIr
>>>upCD9E/edit
>>>
>>> I clearly saw this kind of issues coming. Let me quote myself what I
>>> suggested: "For instance: "endpoints" should be "enforcement point"
>>>
>>> I do not understand why GBP did not include this suggestionŠ
>>>
>>> Edgar
>>>
>>> From: Kevin Benton 
>>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>> Date: Wednesday, August 6, 2014 at 10:22 AM
>>> To: "OpenStack Development Mailing List (not for usage questions)"
>>> 
>>>
>>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>>> forward
>>>
>>> What I was referring to was also not Keystone's definition of an
>>>endpoint.
>>> It's almost as if the term has many uses and was not invented for
>>>Keystone.
>>> :-)
>>>
>>> http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
>>>
>>> Did a similar discussion occur when Heat wanted to use the word
>>>'template'
>>> since this was clearly already in use by Horizon?
>>>
>>> On Aug 6, 2014 9:24 AM, "Jay Pipes"  wrote:
>>>>
>>>> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>>>>>
>>>>> Given that, pointing to the Nova parity work seems a bit like a red
>>>>> herring. This new API is being developed orthogonally to the existing
>>>>> API endpoints
>>>>
>>>>
>>>> You see how you used the term endpoints there? :P
>>>>
>>>> -jay
>>>>
>>>> ___
>>>> 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
>>>
>>
>>___
>>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

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Edgar Magana]

That is the beauty of the open source projects, there is always a smartest
reviewer catching out the facts that you don¹t.

Edgar

On 8/6/14, 10:55 AM, "Sumit Naiksatam"  wrote:

>Edgar, you seemed to have +2'ed this patch on July 2nd [1]:
>
>"
>Edgar Magana
>Jul 2 8:42 AM
>
>Patch Set 13: Code-Review+2
>
>All looks good to me! I am not approving yet because Nachi was also
>reviewing this code and I would like to see his opinion as well.
>"
>
>That would suggest that you were happy with what was in it. I don't
>see anything in the review comments that suggests otherwise.
>
>[1]  https://review.openstack.org/#/c/95900/
>
>On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana 
>wrote:
>> This is the consequence of a proposal that is not following the
>>standardized
>> terminology (IETF - RFC) for any Policy-based System:
>> http://tools.ietf.org/html/rfc3198
>>
>> Well, I did bring  this point during the Hong Kong Summit but as you
>>can see
>> my comments were totally ignored:
>> 
>>https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIr
>>upCD9E/edit
>>
>> I clearly saw this kind of issues coming. Let me quote myself what I
>> suggested: "For instance: "endpoints" should be "enforcement point"
>>
>> I do not understand why GBP did not include this suggestionŠ
>>
>> Edgar
>>
>> From: Kevin Benton 
>> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>> Date: Wednesday, August 6, 2014 at 10:22 AM
>> To: "OpenStack Development Mailing List (not for usage questions)"
>> 
>>
>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>> forward
>>
>> What I was referring to was also not Keystone's definition of an
>>endpoint.
>> It's almost as if the term has many uses and was not invented for
>>Keystone.
>> :-)
>>
>> http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
>>
>> Did a similar discussion occur when Heat wanted to use the word
>>'template'
>> since this was clearly already in use by Horizon?
>>
>> On Aug 6, 2014 9:24 AM, "Jay Pipes"  wrote:
>>>
>>> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>>>>
>>>> Given that, pointing to the Nova parity work seems a bit like a red
>>>> herring. This new API is being developed orthogonally to the existing
>>>> API endpoints
>>>
>>>
>>> You see how you used the term endpoints there? :P
>>>
>>> -jay
>>>
>>> ___
>>> 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
>>
>
>___
>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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Ivar Lazzaro]

Salvatore,

Can you expand on point 2? Not sure what means in this case to 'treat it
accordingly'.

Thanks,
Ivar.


On Wed, Aug 6, 2014 at 7:44 PM, Salvatore Orlando 
wrote:

> As Ronak said, this thread is starting to move in a lot of different
> directions, ranging from correctness of the blueprint approval process to
> nova/neutron integration, which are rather off topic.
>
> In particular it seems things are being skewed towards a discussion around
> nova parity, whereas actually some people have just chimed in with their
> honest opinion that with all the stuff still needed to finally be able to
> make neutron "THE" openstack networking solution, the effort towards adding
> a new tenant facing API appears to have a lesser priority.
>
> I just want to reassure everybody that the majority of the core team and a
> large part of the community have actually made this their first priority.
> For what is worth, some of them have even delayed plugin/driver specific
> development to this aim.
>
> So I would invite to go back to the original subject of the discussion,
> that is to say decide as a community what would the best way forward for
> this effort.
> I see so far the following options:
> - merge the outstanding patches, assuming there are no further technical
> concerns, and include GBP in Juno.
> - consider GBP an 'experimental' V3 tenant API (this was mentioned
> somewhere in this thread) and treat it accordingly
> - delay to the next release
> - move the development of the service plugin to stackforge as suggested to
> this thread.
>
> More options are obviously welcome!
>
> Regards,
> Salvatore
>
>
> On 6 August 2014 19:40, Ivar Lazzaro  wrote:
>
>> Which kind of uncertainty are you referring to?
>>
>> Given that the blueprint was approved long ago, and the code has been
>> ready and under review following those specs... I think GBP is probably the
>> patch with the least effort to be merged right now.
>>
>> Ivar.
>>
>>
>> On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon  wrote:
>>
>>>
>>> On Aug 6, 2014 10:21 AM, "Ronak Shah" 
>>> wrote:
>>> >
>>> > We have diverged our attention towards nova-network-> neutron parity
>>> on this thread unnecessarily.
>>> >
>>> > Can we discuss and collectively decide on what is the way forward for
>>> GBP in Juno release?
>>> >
>>> > Efforts have been made by the subteam starting from throwing PoC at
>>> last summit to spec approval to code review.
>>> >
>>> > There are usefulness to this feature and I think everyone is on the
>>> same page there.
>>> >
>>> > Let us not discourage the effort by bringing in existing neutron issue
>>> in play.
>>>
>>> > Yes, we has a neutorn community needs to fix that with highest
>>> priority.
>>> > But this is orthogonal effort.
>>>
>>> The efforts may be orthogonal, but the review team and bandwidth of said
>>> team is one and the same. Making nova-network the highest priority means
>>> pushing other blueprints back as needed.  And since there is still so much
>>> uncertainty around GPB this late in the cycle, IMHO it's a good candidate
>>> for getting deferred.
>>>
>>> > If endpoint is not a likeable preferred name than lets propose more
>>> meaningful alternative.
>>> > Let us try to find a middle ground on how this feature can be made
>>> generally available.
>>> >
>>> > Thanks,
>>> > Ronak
>>> >
>>> > ___
>>> > 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
>>>
>>>
>>
>> ___
>> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Sumit Naiksatam]

Edgar, you seemed to have +2'ed this patch on July 2nd [1]:

"
Edgar Magana
Jul 2 8:42 AM

Patch Set 13: Code-Review+2

All looks good to me! I am not approving yet because Nachi was also
reviewing this code and I would like to see his opinion as well.
"

That would suggest that you were happy with what was in it. I don't
see anything in the review comments that suggests otherwise.

[1]  https://review.openstack.org/#/c/95900/

On Wed, Aug 6, 2014 at 10:39 AM, Edgar Magana  wrote:
> This is the consequence of a proposal that is not following the standardized
> terminology (IETF - RFC) for any Policy-based System:
> http://tools.ietf.org/html/rfc3198
>
> Well, I did bring  this point during the Hong Kong Summit but as you can see
> my comments were totally ignored:
> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit
>
> I clearly saw this kind of issues coming. Let me quote myself what I
> suggested: "For instance: "endpoints" should be "enforcement point"
>
> I do not understand why GBP did not include this suggestion…
>
> Edgar
>
> From: Kevin Benton 
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: Wednesday, August 6, 2014 at 10:22 AM
> To: "OpenStack Development Mailing List (not for usage questions)"
> 
>
> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
> forward
>
> What I was referring to was also not Keystone's definition of an endpoint.
> It's almost as if the term has many uses and was not invented for Keystone.
> :-)
>
> http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html
>
> Did a similar discussion occur when Heat wanted to use the word 'template'
> since this was clearly already in use by Horizon?
>
> On Aug 6, 2014 9:24 AM, "Jay Pipes"  wrote:
>>
>> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>>>
>>> Given that, pointing to the Nova parity work seems a bit like a red
>>> herring. This new API is being developed orthogonally to the existing
>>> API endpoints
>>
>>
>> You see how you used the term endpoints there? :P
>>
>> -jay
>>
>> ___
>> 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
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Jay Pipes]

On 08/06/2014 01:22 PM, Kevin Benton wrote:

What I was referring to was also not Keystone's definition of an
endpoint. It's almost as if the term has many uses and was not invented
for Keystone. :-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word
'template' since this was clearly already in use by Horizon?


Not sure. But I do know that conversations around resource names in REST 
API endpoints (yes, that is how the term has been used in OpenStack) 
have been numerous. Just search for various conversations around project 
or tenant, or any of the Tuskar API modeling conversations. These kinds 
of discussions do come up often, and for good reason... these are the 
public APIs of OpenStack and are our "first impression" to the user, so 
to speak. It's a lot easier to try and get things right first than go 
through endless deprecation and backwards compatibility discussions. :)


Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Salvatore Orlando]

As Ronak said, this thread is starting to move in a lot of different
directions, ranging from correctness of the blueprint approval process to
nova/neutron integration, which are rather off topic.

In particular it seems things are being skewed towards a discussion around
nova parity, whereas actually some people have just chimed in with their
honest opinion that with all the stuff still needed to finally be able to
make neutron "THE" openstack networking solution, the effort towards adding
a new tenant facing API appears to have a lesser priority.

I just want to reassure everybody that the majority of the core team and a
large part of the community have actually made this their first priority.
For what is worth, some of them have even delayed plugin/driver specific
development to this aim.

So I would invite to go back to the original subject of the discussion,
that is to say decide as a community what would the best way forward for
this effort.
I see so far the following options:
- merge the outstanding patches, assuming there are no further technical
concerns, and include GBP in Juno.
- consider GBP an 'experimental' V3 tenant API (this was mentioned
somewhere in this thread) and treat it accordingly
- delay to the next release
- move the development of the service plugin to stackforge as suggested to
this thread.

More options are obviously welcome!

Regards,
Salvatore


On 6 August 2014 19:40, Ivar Lazzaro  wrote:

> Which kind of uncertainty are you referring to?
>
> Given that the blueprint was approved long ago, and the code has been
> ready and under review following those specs... I think GBP is probably the
> patch with the least effort to be merged right now.
>
> Ivar.
>
>
> On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon  wrote:
>
>>
>> On Aug 6, 2014 10:21 AM, "Ronak Shah"  wrote:
>> >
>> > We have diverged our attention towards nova-network-> neutron parity on
>> this thread unnecessarily.
>> >
>> > Can we discuss and collectively decide on what is the way forward for
>> GBP in Juno release?
>> >
>> > Efforts have been made by the subteam starting from throwing PoC at
>> last summit to spec approval to code review.
>> >
>> > There are usefulness to this feature and I think everyone is on the
>> same page there.
>> >
>> > Let us not discourage the effort by bringing in existing neutron issue
>> in play.
>>
>> > Yes, we has a neutorn community needs to fix that with highest
>> priority.
>> > But this is orthogonal effort.
>>
>> The efforts may be orthogonal, but the review team and bandwidth of said
>> team is one and the same. Making nova-network the highest priority means
>> pushing other blueprints back as needed.  And since there is still so much
>> uncertainty around GPB this late in the cycle, IMHO it's a good candidate
>> for getting deferred.
>>
>> > If endpoint is not a likeable preferred name than lets propose more
>> meaningful alternative.
>> > Let us try to find a middle ground on how this feature can be made
>> generally available.
>> >
>> > Thanks,
>> > Ronak
>> >
>> > ___
>> > 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
>>
>>
>
> ___
> 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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Ivar Lazzaro]

Which kind of uncertainty are you referring to?

Given that the blueprint was approved long ago, and the code has been ready
and under review following those specs... I think GBP is probably the patch
with the least effort to be merged right now.

Ivar.


On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon  wrote:

>
> On Aug 6, 2014 10:21 AM, "Ronak Shah"  wrote:
> >
> > We have diverged our attention towards nova-network-> neutron parity on
> this thread unnecessarily.
> >
> > Can we discuss and collectively decide on what is the way forward for
> GBP in Juno release?
> >
> > Efforts have been made by the subteam starting from throwing PoC at last
> summit to spec approval to code review.
> >
> > There are usefulness to this feature and I think everyone is on the same
> page there.
> >
> > Let us not discourage the effort by bringing in existing neutron issue
> in play.
>
> > Yes, we has a neutorn community needs to fix that with highest priority.
> > But this is orthogonal effort.
>
> The efforts may be orthogonal, but the review team and bandwidth of said
> team is one and the same. Making nova-network the highest priority means
> pushing other blueprints back as needed.  And since there is still so much
> uncertainty around GPB this late in the cycle, IMHO it's a good candidate
> for getting deferred.
>
> > If endpoint is not a likeable preferred name than lets propose more
> meaningful alternative.
> > Let us try to find a middle ground on how this feature can be made
> generally available.
> >
> > Thanks,
> > Ronak
> >
> > ___
> > 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Edgar Magana]

This is the consequence of a proposal that is not following the standardized 
terminology (IETF - RFC) for any Policy-based System:
http://tools.ietf.org/html/rfc3198

Well, I did bring  this point during the Hong Kong Summit but as you can see my 
comments were totally ignored:
https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit

I clearly saw this kind of issues coming. Let me quote myself what I suggested: 
"For instance: "endpoints" should be "enforcement point"

I do not understand why GBP did not include this suggestion...

Edgar

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 10:22 AM
To: "OpenStack Development Mailing List (not for usage questions)" 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


What I was referring to was also not Keystone's definition of an endpoint. It's 
almost as if the term has many uses and was not invented for Keystone. :-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word 'template' 
since this was clearly already in use by Horizon?

On Aug 6, 2014 9:24 AM, "Jay Pipes" 
mailto:jaypi...@gmail.com>> wrote:
On 08/06/2014 02:12 AM, Kevin Benton wrote:
Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing
API endpoints

You see how you used the term endpoints there? :P

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Sridar Kandaswamy (skandasw)]

Hi All:

+1 Ivar. Yes the timing of the alternate proposal does make the notion of spec 
reviews seem like a process tick mark with no seeming benefit. It is indeed 
unfair to the folks who have put in a lot of effort with an approved spec to 
have a workflow change pulled on them so late in the cycle.

Thanks

Sridar

From: Ivar Lazzaro mailto:ivarlazz...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 12:01 PM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


Hi Joe,

Are you suggesting to stop/remove everything that is not related to Nova Parity 
for the Juno release? Because then I fail to see why this and Mark's proposal 
are targeted  only to GBP.

In my humble opinion, these kind of concerns should be addressed at BP approval 
time. Otherwise the whole purpose of the BP process feels void.

If we really feel like proposing a new way of addressing new features in 
Neutron (which basically is a workflow change), we should discuss all of it for 
the next release without blocking patches which went through the whole approval 
process and are ready to be merged after community effort (BP process, Weakly 
meetings, POC, reviews). Just like has been done in other similar cases (eg. 
3rd Party CI). This of course is IMHO.

Ivar.

On Aug 6, 2014 4:55 PM, "Joe Gordon" 
mailto:joe.gord...@gmail.com>> wrote:



On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton 
mailto:blak...@gmail.com>> wrote:
Are there any parity features you are aware of that aren't receiving adequate 
developer/reviewer time? I'm not aware of any parity features that are in a 
place where throwing more engineers at them is going to speed anything up. 
Maybe Mark McClain (Nova parity leader) can provide some better insight here, 
but that is the impression I've gotten as an active Neutron contributor 
observing the ongoing parity work.

I cannot speak for which parts of nova-parity are short staffed, if any, but 
from an outsiders perspective I don't think neutron will hit full parity in 
Juno. And I would be very surprised to hear that more developers working on 
parity won't help. For example we are already in Juno-3 and the following work 
is yet to be completed (as per the neutron gap wiki):

* Make check-tempest-dsvm-neutron-full stable enough to vote
* Grenade testing
* DVR (Neutron replacement for Nova multi-host)
* Document Open Source Options
* Real world (not in gate) performance, stability and scalability testing 
(performance parity with nova-networking).



Given that, pointing to the Nova parity work seems a bit like a red herring. 
This new API is being developed orthogonally to the existing API endpoints and 
I don't think it was ever the expectation that Nova would switch to this during 
the Juno timeframe anyway. The new API will not be used during normal operation 
and should not impact the existing API at all.



On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague 
mailto:s...@dague.net>> wrote:
On 08/05/2014 07:28 PM, Joe Gordon wrote:
>
>
>
> On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura 
> mailto:kuk...@noironetworks.com>
> <mailto:kuk...@noironetworks.com<mailto:kuk...@noironetworks.com>>> wrote:
>
> 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 bein

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Joe Gordon]

On Aug 6, 2014 10:21 AM, "Ronak Shah"  wrote:
>
> We have diverged our attention towards nova-network-> neutron parity on
this thread unnecessarily.
>
> Can we discuss and collectively decide on what is the way forward for GBP
in Juno release?
>
> Efforts have been made by the subteam starting from throwing PoC at last
summit to spec approval to code review.
>
> There are usefulness to this feature and I think everyone is on the same
page there.
>
> Let us not discourage the effort by bringing in existing neutron issue in
play.

> Yes, we has a neutorn community needs to fix that with highest priority.
> But this is orthogonal effort.

The efforts may be orthogonal, but the review team and bandwidth of said
team is one and the same. Making nova-network the highest priority means
pushing other blueprints back as needed.  And since there is still so much
uncertainty around GPB this late in the cycle, IMHO it's a good candidate
for getting deferred.

> If endpoint is not a likeable preferred name than lets propose more
meaningful alternative.
> Let us try to find a middle ground on how this feature can be made
generally available.
>
> Thanks,
> Ronak
>
> ___
> 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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Kevin Benton]

What I was referring to was also not Keystone's definition of an endpoint.
It's almost as if the term has many uses and was not invented for Keystone.
:-)

http://www.wireshark.org/docs/wsug_html_chunked/ChStatEndpoints.html

Did a similar discussion occur when Heat wanted to use the word 'template'
since this was clearly already in use by Horizon?
On Aug 6, 2014 9:24 AM, "Jay Pipes"  wrote:

> On 08/06/2014 02:12 AM, Kevin Benton wrote:
>
>> Given that, pointing to the Nova parity work seems a bit like a red
>> herring. This new API is being developed orthogonally to the existing
>> API endpoints
>>
>
> You see how you used the term endpoints there? :P
>
> -jay
>
> ___
> 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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Ronak Shah]

We have diverged our attention towards nova-network-> neutron parity on
this thread unnecessarily.

Can we discuss and collectively decide on what is the way forward for GBP
in Juno release?

Efforts have been made by the subteam starting from throwing PoC at last
summit to spec approval to code review.

There are usefulness to this feature and I think everyone is on the same
page there.

Let us not discourage the effort by bringing in existing neutron issue in
play.
Yes, we has a neutorn community needs to fix that with highest priority.
But this is orthogonal effort.
If endpoint is not a likeable preferred name than lets propose more
meaningful alternative.
Let us try to find a middle ground on how this feature can be made
generally available.

Thanks,
Ronak
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

As a cloud admin one needs to make sure the endpoints in keystone
publicurl, internalurl and adminurl all map to the right places in the
infrastructure. As a cloud user (for example when using the HP/RAX public
cloud that has multiple regions/endpoints) a user needs to be aware of
which region maps to which endpoint.


On Wed, Aug 6, 2014 at 9:56 AM, Kevin Benton  wrote:

> It sounds to me like you are describing how a developer uses Keystone, not
> a user. My reference to 'application deployer' was to someone trying to run
> something like a mail server on an openstack cloud.
> On Aug 6, 2014 7:07 AM, "Russell Bryant"  wrote:
>
>> On 08/05/2014 06:13 PM, Kevin Benton wrote:
>> > That makes sense. It's not quite a fair analogy though to compare to
>> > reintroducing projects or tenants because Keystone endpoints aren't
>> > 'user-facing' so to speak. i.e. a regular user (application deployer,
>> > instance operator, etc) should never have to see or understand the
>> > purpose of a Keystone endpoint.
>>
>> An end user that is consuming any OpenStack API absolutely must
>> understand endpoints in the service catalog.  The entire purpose of the
>> catalog is so that an application only needs to know the API endpoint to
>> keystone and is then able to discover where the rest of the APIs are
>> located.  They are very much user facing, IMO.
>>
>> --
>> Russell Bryant
>>
>> ___
>> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Kevin Benton]

In the weekly neutron meetings it hasn't been mentioned that any of these
items are at risk due to developer shortage. That's why I wanted Mark
McClain to reply here because he has been leading the parity effort.
On Aug 6, 2014 8:56 AM, "Joe Gordon"  wrote:

>
>
>
> On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton  wrote:
>
>> Are there any parity features you are aware of that aren't receiving
>> adequate developer/reviewer time? I'm not aware of any parity features that
>> are in a place where throwing more engineers at them is going to speed
>> anything up. Maybe Mark McClain (Nova parity leader) can provide some
>> better insight here, but that is the impression I've gotten as an active
>> Neutron contributor observing the ongoing parity work.
>>
>
> I cannot speak for which parts of nova-parity are short staffed, if any,
> but from an outsiders perspective I don't think neutron will hit full
> parity in Juno. And I would be very surprised to hear that more developers
> working on parity won't help. For example we are already in Juno-3 and the
> following work is yet to be completed (as per the neutron gap wiki):
>
> * Make check-tempest-dsvm-neutron-full stable enough to vote
> * Grenade testing
> * DVR (Neutron replacement for Nova multi-host)
> * Document Open Source Options
> * Real world (not in gate) performance, stability and scalability testing
> (performance parity with nova-networking).
>
>
>
>>
>> Given that, pointing to the Nova parity work seems a bit like a red
>> herring. This new API is being developed orthogonally to the existing API
>> endpoints and I don't think it was ever the expectation that Nova would
>> switch to this during the Juno timeframe anyway. The new API will not be
>> used during normal operation and should not impact the existing API at all.
>>
>
>>
>
>>
>
>> On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague  wrote:
>>
>>> On 08/05/2014 07:28 PM, Joe Gordon wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura <
>>> kuk...@noironetworks.com
>>> > > wrote:
>>> >
>>> > 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
>>> >
>>> >
>>> >
>>> > As a member of nova-core, I find this whole discussion very startling.
>>> > Putting aside the concerns over technical details and the pain of
>>> hav

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Kevin Benton]

It sounds to me like you are describing how a developer uses Keystone, not
a user. My reference to 'application deployer' was to someone trying to run
something like a mail server on an openstack cloud.
On Aug 6, 2014 7:07 AM, "Russell Bryant"  wrote:

> On 08/05/2014 06:13 PM, Kevin Benton wrote:
> > That makes sense. It's not quite a fair analogy though to compare to
> > reintroducing projects or tenants because Keystone endpoints aren't
> > 'user-facing' so to speak. i.e. a regular user (application deployer,
> > instance operator, etc) should never have to see or understand the
> > purpose of a Keystone endpoint.
>
> An end user that is consuming any OpenStack API absolutely must
> understand endpoints in the service catalog.  The entire purpose of the
> catalog is so that an application only needs to know the API endpoint to
> keystone and is then able to discover where the rest of the APIs are
> located.  They are very much user facing, IMO.
>
> --
> Russell Bryant
>
> ___
> 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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Ivar Lazzaro]

Hi Joe,

Are you suggesting to stop/remove everything that is not related to Nova
Parity for the Juno release? Because then I fail to see why this and Mark's
proposal are targeted  only to GBP.

In my humble opinion, these kind of concerns should be addressed at BP
approval time. Otherwise the whole purpose of the BP process feels void.

If we really feel like proposing a new way of addressing new features in
Neutron (which basically is a workflow change), we should discuss all of it
for the next release without blocking patches which went through the whole
approval process and are ready to be merged after community effort (BP
process, Weakly meetings, POC, reviews). Just like has been done in other
similar cases (eg. 3rd Party CI). This of course is IMHO.

Ivar.
On Aug 6, 2014 4:55 PM, "Joe Gordon"  wrote:

>
>
>
> On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton  wrote:
>
>> Are there any parity features you are aware of that aren't receiving
>> adequate developer/reviewer time? I'm not aware of any parity features that
>> are in a place where throwing more engineers at them is going to speed
>> anything up. Maybe Mark McClain (Nova parity leader) can provide some
>> better insight here, but that is the impression I've gotten as an active
>> Neutron contributor observing the ongoing parity work.
>>
>
> I cannot speak for which parts of nova-parity are short staffed, if any,
> but from an outsiders perspective I don't think neutron will hit full
> parity in Juno. And I would be very surprised to hear that more developers
> working on parity won't help. For example we are already in Juno-3 and the
> following work is yet to be completed (as per the neutron gap wiki):
>
> * Make check-tempest-dsvm-neutron-full stable enough to vote
> * Grenade testing
> * DVR (Neutron replacement for Nova multi-host)
> * Document Open Source Options
> * Real world (not in gate) performance, stability and scalability testing
> (performance parity with nova-networking).
>
>
>
>>
>> Given that, pointing to the Nova parity work seems a bit like a red
>> herring. This new API is being developed orthogonally to the existing API
>> endpoints and I don't think it was ever the expectation that Nova would
>> switch to this during the Juno timeframe anyway. The new API will not be
>> used during normal operation and should not impact the existing API at all.
>>
>
>>
>
>>
>
>> On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague  wrote:
>>
>>> On 08/05/2014 07:28 PM, Joe Gordon wrote:
>>> >
>>> >
>>> >
>>> > On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura <
>>> kuk...@noironetworks.com
>>> > > wrote:
>>> >
>>> > 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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Jay Pipes]

On 08/06/2014 02:12 AM, Kevin Benton wrote:

Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing
API endpoints


You see how you used the term endpoints there? :P

-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Joe Gordon]

On Wed, Aug 6, 2014 at 4:12 PM, Kevin Benton  wrote:

> Are there any parity features you are aware of that aren't receiving
> adequate developer/reviewer time? I'm not aware of any parity features that
> are in a place where throwing more engineers at them is going to speed
> anything up. Maybe Mark McClain (Nova parity leader) can provide some
> better insight here, but that is the impression I've gotten as an active
> Neutron contributor observing the ongoing parity work.
>

I cannot speak for which parts of nova-parity are short staffed, if any,
but from an outsiders perspective I don't think neutron will hit full
parity in Juno. And I would be very surprised to hear that more developers
working on parity won't help. For example we are already in Juno-3 and the
following work is yet to be completed (as per the neutron gap wiki):

* Make check-tempest-dsvm-neutron-full stable enough to vote
* Grenade testing
* DVR (Neutron replacement for Nova multi-host)
* Document Open Source Options
* Real world (not in gate) performance, stability and scalability testing
(performance parity with nova-networking).



>
> Given that, pointing to the Nova parity work seems a bit like a red
> herring. This new API is being developed orthogonally to the existing API
> endpoints and I don't think it was ever the expectation that Nova would
> switch to this during the Juno timeframe anyway. The new API will not be
> used during normal operation and should not impact the existing API at all.
>

>

>

> On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague  wrote:
>
>> On 08/05/2014 07:28 PM, Joe Gordon wrote:
>> >
>> >
>> >
>> > On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura <
>> kuk...@noironetworks.com
>> > > wrote:
>> >
>> > 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
>> >
>> >
>> >
>> > As a member of nova-core, I find this whole discussion very startling.
>> > Putting aside the concerns over technical details and the pain of having
>> > in tree experimental APIs (such as nova v3 API), neutron still isn't the
>> > de-facto networking solution from nova's perspective and it won't be
>> > until neutron has feature and performance parity with nova-network. In
>> > fact due to the slow maturation of neutron, nova has moved nova-network
>> > from 'frozen' to open for development (with a few caveats).  So unless
>> > this

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Carlino, Chuck (OpenStack TripleO, Neutron)]

On Aug 6, 2014, at 1:11 AM, Aaron Rosen 
mailto:aaronoro...@gmail.com>> wrote:

I agree, I had actually proposed this here: 
https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port  :),   
though there are some issues we need to solve in neutron first -- allowing the 
mac_address on the port to be updated in neutron. This is required for bare 
metal support as when the port is created we don't know which physical mac will 
need to be mapped to the port.


FYI, this is work in progress (see 
https://bugs.launchpad.net/neutron/+bug/1341268 and 
https://review.openstack.org/#/c/112129/).

Chuck Carlino

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Russell Bryant]

On 08/05/2014 06:13 PM, Kevin Benton wrote:
> That makes sense. It's not quite a fair analogy though to compare to
> reintroducing projects or tenants because Keystone endpoints aren't
> 'user-facing' so to speak. i.e. a regular user (application deployer,
> instance operator, etc) should never have to see or understand the
> purpose of a Keystone endpoint.

An end user that is consuming any OpenStack API absolutely must
understand endpoints in the service catalog.  The entire purpose of the
catalog is so that an application only needs to know the API endpoint to
keystone and is then able to discover where the rest of the APIs are
located.  They are very much user facing, IMO.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Russell Bryant]

On 08/05/2014 05:24 PM, Sumit Naiksatam wrote:
> On Tue, Aug 5, 2014 at 1:41 PM, Jay Pipes  wrote:
>> On 08/05/2014 04:26 PM, Stephen Wong wrote:
>>>
>>> Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
>>> integration, and the preliminary idea, as Bob alluded to, is to add
>>> "endpoint" as an option in place of Neutron port. But if we can make
>>> Nova EPG-aware, it would be great.
>>
>>
>> Is anyone listening to what I'm saying? The term "endpoint" is obtuse and
>> completely disregards the existing denotation of the word "endpoint" in use
>> in OpenStack today.
>>
> 
> Yes, listening, absolutely. I acknowledged your point in this thread
> as well as on the review. Your suggestion on the thread seemed to be
> to document this better and clarify. Is that sufficient for moving
> forward, or are you thinking something else?

I agree with Jay's concern here.  I think using the term "endpoint" at
all is problematic and should be renamed to something else.  As Jay has
stated, "endpoint" is already a well defined and completely different
concept in OpenStack.  What's being created here should be called
something else.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Kyle Mestery]

On Wed, Aug 6, 2014 at 3:11 AM, Aaron Rosen  wrote:
>
>
>
> On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton  wrote:
>>
>>
>>
>> From: Aaron Rosen 
>> Reply-To: OpenStack List 
>> Date: Wednesday, August 6, 2014 at 10:09 AM
>>
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>> forward
>>
>>
>> On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton  wrote:
>>>
>>>
>>>
>>> On 8/5/14, 8:53 PM, "Russell Bryant"  wrote:
>>>
>>> >On 08/05/2014 01: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.
>>> >
>>> >FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
>>> >like to get rid of automatic port creation, but can't do that in the
>>> >current stable API.
>>>
>>> Can you elaborate on what you mean here? What are the issues with port
>>> creation?
>>>
>>
>> Having nova-compute create ports for neutron is problematic if timeouts
>> occur between nova and neutron as you have to garbage collect neutron ports
>> in nova to cleanup (which was the cause of several bug in the cache handing
>> allowing ports to leak into the info_cache in nova).  Pushing this out to
>> the tenant is less orchestration nova has to do.
>>
>> [gary] my take on this is that we should allocate this via the n-api and
>> not via the nova compute (which is far too late in the process. But that is
>> another discussion :)
>
>
> I agree, I had actually proposed this here:
> https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port
> :),   though there are some issues we need to solve in neutron first --
> allowing the mac_address on the port to be updated in neutron. This is
> required for bare metal support as when the port is created we don't know
> which physical mac will need to be mapped to the port.
>>
Looks like someone has proposed a patch which does just that, please
have a look below:

https://review.openstack.org/#/c/112129/

>>
>>> >
>>> >--
>>> >Russell Bryant
>>> >
>>> >___
>>> >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
>>
>>
>>
>> ___
>> 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
>

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Christopher Yeoh]

On Wed, Aug 6, 2014 at 5:41 PM, Aaron Rosen  wrote:

>
>
>
> On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton  wrote:
>
>>
>>
>>   From: Aaron Rosen 
>> Reply-To: OpenStack List 
>> Date: Wednesday, August 6, 2014 at 10:09 AM
>>
>> To: OpenStack List 
>> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
>> forward
>>
>>
>> On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton  wrote:
>>
>>>
>>>
>>> On 8/5/14, 8:53 PM, "Russell Bryant"  wrote:
>>>
>>> >On 08/05/2014 01: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.
>>> >
>>> >FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
>>> >like to get rid of automatic port creation, but can't do that in the
>>> >current stable API.
>>>
>>>  Can you elaborate on what you mean here? What are the issues with port
>>> creation?
>>>
>>>
>> Having nova-compute create ports for neutron is problematic if timeouts
>> occur between nova and neutron as you have to garbage collect neutron ports
>> in nova to cleanup (which was the cause of several bug in the cache handing
>> allowing ports to leak into the info_cache in nova).  Pushing this out to
>> the tenant is less orchestration nova has to do.
>>
>>  [gary] my take on this is that we should allocate this via the n-api
>> and not via the nova compute (which is far too late in the process. But
>> that is another discussion :)
>>
>
> I agree, I had actually proposed this here:
> https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port
>  :),   though there are some issues we need to solve in neutron first --
> allowing the mac_address on the port to be updated in neutron. This is
> required for bare metal support as when the port is created we don't know
> which physical mac will need to be mapped to the port.
>
>>
>>

I think that in the long term (when we can do an API rev) we should just be
getting rid of the automatic port creation completely with the updated Nova
API. I don't see why the Nova API needs to do proxying work to neutron to
create the port when the client can do it directly with neutron (perhaps
via some convenience client code if desired). It removes the complexity of
the garbage collection on failure issues in Nova that we currently have.

Chris



>   >
>>> >--
>>> >Russell Bryant
>>> >
>>> >___
>>> >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
>>>
>>
>>
>> ___
>> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Gary Kotton]

From: Aaron Rosen mailto:aaronoro...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 11:11 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward




On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:


From: Aaron Rosen mailto:aaronoro...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 10:09 AM

To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:


On 8/5/14, 8:53 PM, "Russell Bryant" 
mailto:rbry...@redhat.com>> wrote:

>On 08/05/2014 01: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.
>
>FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
>like to get rid of automatic port creation, but can't do that in the
>current stable API.

Can you elaborate on what you mean here? What are the issues with port
creation?


Having nova-compute create ports for neutron is problematic if timeouts occur 
between nova and neutron as you have to garbage collect neutron ports in nova 
to cleanup (which was the cause of several bug in the cache handing allowing 
ports to leak into the info_cache in nova).  Pushing this out to the tenant is 
less orchestration nova has to do.

[gary] my take on this is that we should allocate this via the n-api and not 
via the nova compute (which is far too late in the process. But that is another 
discussion :)

I agree, I had actually proposed this here: 
https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port<https://urldefense.proofpoint.com/v1/url?u=https://blueprints.launchpad.net/nova/%2Bspec/nova-api-quantum-create-port&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=eH0pxTUZo8NPZyF6hgoMQu%2BfDtysg45MkPhCZFxPEq8%3D%0A&m=nxi%2BsVOGOwFKN8cKE9T4thh6hF%2Fbbz59EZEBQvd1lkE%3D%0A&s=50f7fe08f64d0d647ee97a8da6f91091e380cca72e84d06fa9c57c62dbb4e4ee>
  :),   though there are some issues we need to solve in neutron first -- 
allowing the mac_address on the port to be updated in neutron. This is required 
for bare metal support as when the port is created we don't know which physical 
mac will need to be mapped to the port.

[gary] agreed

>
>--
>Russell Bryant
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Wed, Aug 6, 2014 at 12:59 AM, Gary Kotton  wrote:

>
>
>   From: Aaron Rosen 
> Reply-To: OpenStack List 
> Date: Wednesday, August 6, 2014 at 10:09 AM
>
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
> forward
>
>
> On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton  wrote:
>
>>
>>
>> On 8/5/14, 8:53 PM, "Russell Bryant"  wrote:
>>
>> >On 08/05/2014 01: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.
>> >
>> >FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
>> >like to get rid of automatic port creation, but can't do that in the
>> >current stable API.
>>
>>  Can you elaborate on what you mean here? What are the issues with port
>> creation?
>>
>>
> Having nova-compute create ports for neutron is problematic if timeouts
> occur between nova and neutron as you have to garbage collect neutron ports
> in nova to cleanup (which was the cause of several bug in the cache handing
> allowing ports to leak into the info_cache in nova).  Pushing this out to
> the tenant is less orchestration nova has to do.
>
>  [gary] my take on this is that we should allocate this via the n-api and
> not via the nova compute (which is far too late in the process. But that is
> another discussion :)
>

I agree, I had actually proposed this here:
https://blueprints.launchpad.net/nova/+spec/nova-api-quantum-create-port
 :),   though there are some issues we need to solve in neutron first --
allowing the mac_address on the port to be updated in neutron. This is
required for bare metal support as when the port is created we don't know
which physical mac will need to be mapped to the port.

>
>   >
>> >--
>> >Russell Bryant
>> >
>> >___
>> >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
>>
>
>
> ___
> 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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Gary Kotton]

From: Aaron Rosen mailto:aaronoro...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 10:09 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward


On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton 
mailto:gkot...@vmware.com>> wrote:


On 8/5/14, 8:53 PM, "Russell Bryant" 
mailto:rbry...@redhat.com>> wrote:

>On 08/05/2014 01: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.
>
>FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
>like to get rid of automatic port creation, but can't do that in the
>current stable API.

Can you elaborate on what you mean here? What are the issues with port
creation?


Having nova-compute create ports for neutron is problematic if timeouts occur 
between nova and neutron as you have to garbage collect neutron ports in nova 
to cleanup (which was the cause of several bug in the cache handing allowing 
ports to leak into the info_cache in nova).  Pushing this out to the tenant is 
less orchestration nova has to do.

[gary] my take on this is that we should allocate this via the n-api and not 
via the nova compute (which is far too late in the process. But that is another 
discussion :)


>
>--
>Russell Bryant
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org<mailto:OpenStack-dev@lists.openstack.org>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org<mailto: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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Sumit Naiksatam]

On Tue, Aug 5, 2014 at 11:46 PM, Gary Kotton  wrote:
> Correct, this work is orthogonal to the parity work, which I understand is
> coming along very nicely.

Agree Gary and Kevin. I think the topic of Nova integration has
created confusion in people’s mind (at least the non-Neutron folks)
with regards to what is being proposed in the Group-based Policy (GBP)
feature. So to clarify - GBP is an optional extension, like many other
existing Neutron extensions. It is not meant to replace the Neutron
core API and/or the current Nova-Neutron interaction in Juno.

> Do new features in Nova also require parity -
> https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks
> (for example enables the MTU to be configured instead of via a configuration
> variable)
> At the moment it seems like a moving target.
>
> From: Kevin Benton 
> Reply-To: OpenStack List 
> Date: Wednesday, August 6, 2014 at 9:12 AM
>
> To: OpenStack List 
> Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way
> forward
>
> Are there any parity features you are aware of that aren't receiving
> adequate developer/reviewer time? I'm not aware of any parity features that
> are in a place where throwing more engineers at them is going to speed
> anything up. Maybe Mark McClain (Nova parity leader) can provide some better
> insight here, but that is the impression I've gotten as an active Neutron
> contributor observing the ongoing parity work.
>
> Given that, pointing to the Nova parity work seems a bit like a red herring.
> This new API is being developed orthogonally to the existing API endpoints
> and I don't think it was ever the expectation that Nova would switch to this
> during the Juno timeframe anyway. The new API will not be used during normal
> operation and should not impact the existing API at all.
>
>
> On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague  wrote:
>>
>> On 08/05/2014 07:28 PM, Joe Gordon wrote:
>> >
>> >
>> >
>> > On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura > > <mailto:kuk...@noironetworks.com>> wrote:
>> >
>> > 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
>> >

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Masakazu Shinohara]

Hi,

I'm Masakazu Shinohara of Cyberagent corporation in Japan.

I am a representative of our new cloud network project.
We have a lot of services such as on line games blogs or all kind of web
services.

Now we have been testing Openstack and Cisco ACI.
It is a really important thing that they can work correctly.

We have been observing, learning and following very closely the work going
on for Group Based Policy. Our production deployment relies on using it in
Juno. We strongly want to see it complete as proposed in Neutron.

Best regards

--
Masakazu Shinohara
CyberAgent,Inc
Ameba division Ameba Infra. Unit
Architect group
Zip code 150-0045
Shibuya First Place Bldg, 8-16 Shinsen-cho
Shibuya-ku Tokyo
Mobile +81 80-6863-2356
Extension 62478
shinohara_masak...@cyberagent.co.jp
---



From: Mark McClain mailto:mmccl...@yahoo-inc.com>>
> Reply-To: "OpenStack Development Mailing List (not for usage questions)"
>  <mailto:openstack-dev@lists.openstack.org>>
> Date: Monday, August 4, 2014 at 4:27 PM
> To: "OpenStack Development Mailing List (not for usage questions)"
>  <mailto:openstack-dev@lists.openstack.org>>
> Subject: [openstack-dev] [Neutron] Group Based Policy and the way forward
>
> 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.
>
>
> 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
&

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Aaron Rosen]

On Tue, Aug 5, 2014 at 11:18 PM, Gary Kotton  wrote:

>
>
> On 8/5/14, 8:53 PM, "Russell Bryant"  wrote:
>
> >On 08/05/2014 01: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.
> >
> >FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
> >like to get rid of automatic port creation, but can't do that in the
> >current stable API.
>
> Can you elaborate on what you mean here? What are the issues with port
> creation?
>
>
Having nova-compute create ports for neutron is problematic if timeouts
occur between nova and neutron as you have to garbage collect neutron ports
in nova to cleanup (which was the cause of several bug in the cache handing
allowing ports to leak into the info_cache in nova).  Pushing this out to
the tenant is less orchestration nova has to do.


>
> >--
> >Russell Bryant
> >
> >___
> >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
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Gary Kotton]

Correct, this work is orthogonal to the parity work, which I understand is 
coming along very nicely. Do new features in Nova also require parity - 
https://blueprints.launchpad.net/nova/+spec/better-support-for-multiple-networks
 (for example enables the MTU to be configured instead of via a configuration 
variable)
At the moment it seems like a moving target.

From: Kevin Benton mailto:blak...@gmail.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Wednesday, August 6, 2014 at 9:12 AM
To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

Are there any parity features you are aware of that aren't receiving adequate 
developer/reviewer time? I'm not aware of any parity features that are in a 
place where throwing more engineers at them is going to speed anything up. 
Maybe Mark McClain (Nova parity leader) can provide some better insight here, 
but that is the impression I've gotten as an active Neutron contributor 
observing the ongoing parity work.

Given that, pointing to the Nova parity work seems a bit like a red herring. 
This new API is being developed orthogonally to the existing API endpoints and 
I don't think it was ever the expectation that Nova would switch to this during 
the Juno timeframe anyway. The new API will not be used during normal operation 
and should not impact the existing API at all.


On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague 
mailto:s...@dague.net>> wrote:
On 08/05/2014 07:28 PM, Joe Gordon wrote:
>
>
>
> On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura 
> mailto:kuk...@noironetworks.com>
> <mailto:kuk...@noironetworks.com<mailto:kuk...@noironetworks.com>>> wrote:
>
> 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
>
>
>
> As a member of nova-core, I find this whole discussion very startling.
> Putting aside the concerns over technical details and the pain of having
> in tree experimental APIs (such as nova v3 API), neutron still isn't the
> de-facto networking solution from nova's perspective and it won't be
> until neutron has feature and performance parity with nova-network

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Gary Kotton]

On 8/5/14, 8:53 PM, "Russell Bryant"  wrote:

>On 08/05/2014 01: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.
>
>FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
>like to get rid of automatic port creation, but can't do that in the
>current stable API.

Can you elaborate on what you mean here? What are the issues with port
creation? 

>
>-- 
>Russell Bryant
>
>___
>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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Kevin Benton]

Are there any parity features you are aware of that aren't receiving
adequate developer/reviewer time? I'm not aware of any parity features that
are in a place where throwing more engineers at them is going to speed
anything up. Maybe Mark McClain (Nova parity leader) can provide some
better insight here, but that is the impression I've gotten as an active
Neutron contributor observing the ongoing parity work.

Given that, pointing to the Nova parity work seems a bit like a red
herring. This new API is being developed orthogonally to the existing API
endpoints and I don't think it was ever the expectation that Nova would
switch to this during the Juno timeframe anyway. The new API will not be
used during normal operation and should not impact the existing API at all.


On Tue, Aug 5, 2014 at 5:51 PM, Sean Dague  wrote:

> On 08/05/2014 07:28 PM, Joe Gordon wrote:
> >
> >
> >
> > On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura  > > wrote:
> >
> > 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
> >
> >
> >
> > As a member of nova-core, I find this whole discussion very startling.
> > Putting aside the concerns over technical details and the pain of having
> > in tree experimental APIs (such as nova v3 API), neutron still isn't the
> > de-facto networking solution from nova's perspective and it won't be
> > until neutron has feature and performance parity with nova-network. In
> > fact due to the slow maturation of neutron, nova has moved nova-network
> > from 'frozen' to open for development (with a few caveats).  So unless
> > this new API directly solves some of the gaps in [0], I see no reason to
> > push this into Juno. Juno hardly seems to be the appropriate time to
> > introduce a new not-so-stable API; Juno is the time to address all the
> > gaps [0] and hit feature and performance parity with nova-network.
> >
> >
> > [0]
> >
> https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage
>
> I would agree.
>
> There has been a pretty regular issue with Neutron team members working
> on new features instead of getting Neutron to feature parity with Nova
> network so we can retire the thing. This whole push for another API at
> this stage makes no sense to me.
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Sean Dague]

On 08/05/2014 07:28 PM, Joe Gordon wrote:
> 
> 
> 
> On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura  > wrote:
> 
> 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
> 
> 
> 
> As a member of nova-core, I find this whole discussion very startling.
> Putting aside the concerns over technical details and the pain of having
> in tree experimental APIs (such as nova v3 API), neutron still isn't the
> de-facto networking solution from nova's perspective and it won't be
> until neutron has feature and performance parity with nova-network. In
> fact due to the slow maturation of neutron, nova has moved nova-network
> from 'frozen' to open for development (with a few caveats).  So unless
> this new API directly solves some of the gaps in [0], I see no reason to
> push this into Juno. Juno hardly seems to be the appropriate time to
> introduce a new not-so-stable API; Juno is the time to address all the
> gaps [0] and hit feature and performance parity with nova-network.
> 
> 
> [0]
> https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage

I would agree.

There has been a pretty regular issue with Neutron team members working
on new features instead of getting Neutron to feature parity with Nova
network so we can retire the thing. This whole push for another API at
this stage makes no sense to me.

-Sean

-- 
Sean Dague
http://dague.net

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Joe Gordon]

On Wed, Aug 6, 2014 at 12:20 AM, Robert Kukura 
wrote:

>  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
>


As a member of nova-core, I find this whole discussion very startling.
Putting aside the concerns over technical details and the pain of having in
tree experimental APIs (such as nova v3 API), neutron still isn't the
de-facto networking solution from nova's perspective and it won't be until
neutron has feature and performance parity with nova-network. In fact due
to the slow maturation of neutron, nova has moved nova-network from
'frozen' to open for development (with a few caveats).  So unless this new
API directly solves some of the gaps in [0], I see no reason to push this
into Juno. Juno hardly seems to be the appropriate time to introduce a new
not-so-stable API; Juno is the time to address all the gaps [0] and hit
feature and performance parity with nova-network.


[0]
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/Neutron_Gap_Coverage


best,
Joe



>
>
>
> 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 ho

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Kevin Benton]

That makes sense. It's not quite a fair analogy though to compare to
reintroducing projects or tenants because Keystone endpoints aren't
'user-facing' so to speak. i.e. a regular user (application deployer,
instance operator, etc) should never have to see or understand the purpose
of a Keystone endpoint.
On Aug 5, 2014 3:53 PM, "Jay Pipes"  wrote:

> On 08/05/2014 05:22 PM, Kevin Benton wrote:
>
>>  >Is anyone listening to what I'm saying? The term "endpoint" is obtuse
>> and completely disregards the existing denotation of the word "endpoint"
>> in use in OpenStack today.
>>
>> Sorry, I didn't understand the confusion because you didn't provide a
>> reference to how "endpoint" is used in OpenStack now. I hadn't heard the
>> term until this GBP work other than keystone endpoints, which have no
>> overlap with this. Can you provide the definition you are familiar with
>> so someone can explain the difference?
>>
>
> Yes, a Keystone endpoint, which exists in the service catalog that every
> single token sent to and from any OpenStack service.
>
> You are correct that there is no overlap with the GBP concept of endpoint.
> But, I guess I'm surprised nobody brought this up when discussing the
> proposed GBP API extensions to Neutron... since the endpoint has been a
> part of the Keystone service catalog API for years.
>
> It would be like if the GBP API came up with a new resource called
> "project" or "tenant" and expected everyone to just understand that this
> new "project" resource had nothing to do with the project concept that is
> used throughout the other APIs...
>
> Anyway, sorry if I'm just blowing off some steam here... it's my fault for
> not paying more attention to this earlier on. But this point goes directly
> to the discussion that Mark McClain and Bob were having about whether to
> let an major API extension like this bake somewhere outside of Neutron vs.
> baking inside Neutron ala VPNaaS, LBaaS, etc.
>
> OK, steam has been blown off, sorry for the partially tangential thread.
>
> -jay
>
>
>  On Tue, Aug 5, 2014 at 2:41 PM, Jay Pipes > > wrote:
>>
>> On 08/05/2014 04:26 PM, Stephen Wong wrote:
>>
>> Agreed with Kevin and Sumit here. As a subgroup we talked about
>> Nova
>> integration, and the preliminary idea, as Bob alluded to, is to
>> add
>> "endpoint" as an option in place of Neutron port. But if we can
>> make
>> Nova EPG-aware, it would be great.
>>
>>
>> Is anyone listening to what I'm saying? The term "endpoint" is
>> obtuse and completely disregards the existing denotation of the word
>> "endpoint" in use in OpenStack today.
>>
>> So, we've gone ahead and replaced the term "port" in the caller
>> interface -- which, besides being too entirely too low-level,
>> actually did describe what the object was -- to using a term
>> "endpoint" that doesn't describe even remotely what the thing is (a
>> template for a collection of networking-related policies and
>> objects) and that already has a well-known definition in the
>> OpenStack ecosystem.
>>
>> That is my point. That is why I brought up the comment on the
>> original patch in the series that some docstrings would be helpful
>> for those not entirely subscribed to the Tenets of National
>> Dvorkinism.
>>
>> These interfaces should speak plain old concepts, not networking
>> guru arcanum.
>>
>> Best,
>> -jay
>>
>> On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
>> mailto:sumitnaiksa...@gmail.com>
>> > >> wrote:
>>
>>  That's right Kevin, EPG (and its association to the
>> L2/3_Policy)
>>  capture the attributes which would represent the
>> "network-template"
>>  being referenced here.
>>
>>  Jay, what Bob mentioned here was an option to use the
>> "endpoint" as a
>>  one-to-one replacement for the option of using a Neutron
>> port. This is
>>  more so in the context of providing an evolutionary path
>> (from the way
>>  Nova currently does it using a pre-defined port). However,
>> if it makes
>>  sense to make Nova aware of the EPG right at the outset,
>> then that is
>>  even better.
>>
>>  I have also noted your suggestion on clarifying the
>> "endpoint"
>>  terminology. This was already done in one of the patches
>> you had
>>  reviewed earlier, and will do that in the first patch as
>> well (where
>>  you pointed it out now).
>>
>>  Thanks,
>>  ~Sumit.
>>
>>  On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton
>> mailto:blak...@gmail.com>
>>  >>
>> wrote:
>>   > Spe

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Jay Pipes]

On 08/05/2014 05:22 PM, Kevin Benton wrote:

 >Is anyone listening to what I'm saying? The term "endpoint" is obtuse
and completely disregards the existing denotation of the word "endpoint"
in use in OpenStack today.

Sorry, I didn't understand the confusion because you didn't provide a
reference to how "endpoint" is used in OpenStack now. I hadn't heard the
term until this GBP work other than keystone endpoints, which have no
overlap with this. Can you provide the definition you are familiar with
so someone can explain the difference?


Yes, a Keystone endpoint, which exists in the service catalog that every 
single token sent to and from any OpenStack service.


You are correct that there is no overlap with the GBP concept of 
endpoint. But, I guess I'm surprised nobody brought this up when 
discussing the proposed GBP API extensions to Neutron... since the 
endpoint has been a part of the Keystone service catalog API for years.


It would be like if the GBP API came up with a new resource called 
"project" or "tenant" and expected everyone to just understand that this 
new "project" resource had nothing to do with the project concept that 
is used throughout the other APIs...


Anyway, sorry if I'm just blowing off some steam here... it's my fault 
for not paying more attention to this earlier on. But this point goes 
directly to the discussion that Mark McClain and Bob were having about 
whether to let an major API extension like this bake somewhere outside 
of Neutron vs. baking inside Neutron ala VPNaaS, LBaaS, etc.


OK, steam has been blown off, sorry for the partially tangential thread.

-jay



On Tue, Aug 5, 2014 at 2:41 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote:

On 08/05/2014 04:26 PM, Stephen Wong wrote:

Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
integration, and the preliminary idea, as Bob alluded to, is to add
"endpoint" as an option in place of Neutron port. But if we can make
Nova EPG-aware, it would be great.


Is anyone listening to what I'm saying? The term "endpoint" is
obtuse and completely disregards the existing denotation of the word
"endpoint" in use in OpenStack today.

So, we've gone ahead and replaced the term "port" in the caller
interface -- which, besides being too entirely too low-level,
actually did describe what the object was -- to using a term
"endpoint" that doesn't describe even remotely what the thing is (a
template for a collection of networking-related policies and
objects) and that already has a well-known definition in the
OpenStack ecosystem.

That is my point. That is why I brought up the comment on the
original patch in the series that some docstrings would be helpful
for those not entirely subscribed to the Tenets of National Dvorkinism.

These interfaces should speak plain old concepts, not networking
guru arcanum.

Best,
-jay

On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
mailto:sumitnaiksa...@gmail.com>
>> wrote:

 That's right Kevin, EPG (and its association to the
L2/3_Policy)
 capture the attributes which would represent the
"network-template"
 being referenced here.

 Jay, what Bob mentioned here was an option to use the
"endpoint" as a
 one-to-one replacement for the option of using a Neutron
port. This is
 more so in the context of providing an evolutionary path
(from the way
 Nova currently does it using a pre-defined port). However,
if it makes
 sense to make Nova aware of the EPG right at the outset,
then that is
 even better.

 I have also noted your suggestion on clarifying the "endpoint"
 terminology. This was already done in one of the patches
you had
 reviewed earlier, and will do that in the first patch as
well (where
 you pointed it out now).

 Thanks,
 ~Sumit.

 On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton
mailto:blak...@gmail.com>
 >> wrote:
  > Specifying an endpoint group would achieve the
 --networking-template effects
  > you described. The endpoint group would have all of the
security
 policies,
  > IP allocation policies, connectivity policies, etc.
already setup.
  >
  >
  > On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes
mailto:jaypi...@gmail.com>
 >> wrote:
  >>
  >> On 08/05/2014 01:13 PM, Robert Kukura wrote:
  >>>
  >>>
  

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Sumit Naiksatam]

On Tue, Aug 5, 2014 at 1:41 PM, Jay Pipes  wrote:
> On 08/05/2014 04:26 PM, Stephen Wong wrote:
>>
>> Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
>> integration, and the preliminary idea, as Bob alluded to, is to add
>> "endpoint" as an option in place of Neutron port. But if we can make
>> Nova EPG-aware, it would be great.
>
>
> Is anyone listening to what I'm saying? The term "endpoint" is obtuse and
> completely disregards the existing denotation of the word "endpoint" in use
> in OpenStack today.
>

Yes, listening, absolutely. I acknowledged your point in this thread
as well as on the review. Your suggestion on the thread seemed to be
to document this better and clarify. Is that sufficient for moving
forward, or are you thinking something else?

> So, we've gone ahead and replaced the term "port" in the caller interface --
> which, besides being too entirely too low-level, actually did describe what
> the object was -- to using a term "endpoint" that doesn't describe even
> remotely what the thing is (a template for a collection of
> networking-related policies and objects) and that already has a well-known
> definition in the OpenStack ecosystem.
>

Couple of things -

The "endpoint", as is being used in this context, does not refer to
the "template" that you are referring to (if I understand you
correctly). The template in some ways is analogous to the "endpoint
group" (or EPG), and is defined as a collection of endpoints. Kevin,
Stephen, and I, have been alluding to that in this thread earlier.

Why "endpoint"? The thinking, among the people discussing this, was
that it needs to be something more abstract than the very specific
network "port" terminology, and something with which can associate
policies and labels/tags. I am not advocating that this is the perfect
naming convention, and I do appreciate the concern that there is
overlap with an endpoint being used in a different context elsewhere
in OpenStack. This overlap however escaped everybody's attention until
it manifested in the code and your review (after having gone through
review in two design summit sessions and being in discussion over
several months).

> That is my point. That is why I brought up the comment on the original patch
> in the series that some docstrings would be helpful for those not entirely
> subscribed to the Tenets of National Dvorkinism.
>
> These interfaces should speak plain old concepts, not networking guru
> arcanum.
>
> Best,
> -jay
>
>> On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
>> mailto:sumitnaiksa...@gmail.com>> wrote:
>>
>> That's right Kevin, EPG (and its association to the L2/3_Policy)
>> capture the attributes which would represent the "network-template"
>> being referenced here.
>>
>> Jay, what Bob mentioned here was an option to use the "endpoint" as a
>> one-to-one replacement for the option of using a Neutron port. This is
>> more so in the context of providing an evolutionary path (from the way
>> Nova currently does it using a pre-defined port). However, if it makes
>> sense to make Nova aware of the EPG right at the outset, then that is
>> even better.
>>
>> I have also noted your suggestion on clarifying the "endpoint"
>> terminology. This was already done in one of the patches you had
>> reviewed earlier, and will do that in the first patch as well (where
>> you pointed it out now).
>>
>> Thanks,
>> ~Sumit.
>>
>> On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton > > wrote:
>>  > Specifying an endpoint group would achieve the
>> --networking-template effects
>>  > you described. The endpoint group would have all of the security
>> policies,
>>  > IP allocation policies, connectivity policies, etc. already setup.
>>  >
>>  >
>>  > On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes > > wrote:
>>  >>
>>  >> On 08/05/2014 01:13 PM, Robert Kukura wrote:
>>  >>>
>>  >>>
>>  >>> 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= ...", requiring no changes to Nova.
>> Later,
>>  >>> slight enhancements to Nova would allow using commands such as
>> "nova
>>  >>> boot ... --nic ep-id= ..." or "nova boot ... --nic
>>  >>> epg-id= ...".
>>  >>
>>  >>
>>  >> Hi Bob,
>>  >>
>>  >> How exactly is the above a friendlier API for the main user of
>> Neutron,
>>  >> which is Nova? I thought one of the main ideas behind the GBP
>> stuff was to
>>  >> create a more declarative and intuitive API for users of Neutron
>> -- i.e.
>>  >> Nova -- to use in constru

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Kevin Benton]

>Is anyone listening to what I'm saying? The term "endpoint" is obtuse and
completely disregards the existing denotation of the word "endpoint" in use
in OpenStack today.

Sorry, I didn't understand the confusion because you didn't provide a
reference to how "endpoint" is used in OpenStack now. I hadn't heard the
term until this GBP work other than keystone endpoints, which have no
overlap with this. Can you provide the definition you are familiar with so
someone can explain the difference?


On Tue, Aug 5, 2014 at 2:41 PM, Jay Pipes  wrote:

> On 08/05/2014 04:26 PM, Stephen Wong wrote:
>
>> Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
>> integration, and the preliminary idea, as Bob alluded to, is to add
>> "endpoint" as an option in place of Neutron port. But if we can make
>> Nova EPG-aware, it would be great.
>>
>
> Is anyone listening to what I'm saying? The term "endpoint" is obtuse and
> completely disregards the existing denotation of the word "endpoint" in use
> in OpenStack today.
>
> So, we've gone ahead and replaced the term "port" in the caller interface
> -- which, besides being too entirely too low-level, actually did describe
> what the object was -- to using a term "endpoint" that doesn't describe
> even remotely what the thing is (a template for a collection of
> networking-related policies and objects) and that already has a well-known
> definition in the OpenStack ecosystem.
>
> That is my point. That is why I brought up the comment on the original
> patch in the series that some docstrings would be helpful for those not
> entirely subscribed to the Tenets of National Dvorkinism.
>
> These interfaces should speak plain old concepts, not networking guru
> arcanum.
>
> Best,
> -jay
>
>  On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
>> mailto:sumitnaiksa...@gmail.com>> wrote:
>>
>> That's right Kevin, EPG (and its association to the L2/3_Policy)
>> capture the attributes which would represent the "network-template"
>> being referenced here.
>>
>> Jay, what Bob mentioned here was an option to use the "endpoint" as a
>> one-to-one replacement for the option of using a Neutron port. This is
>> more so in the context of providing an evolutionary path (from the way
>> Nova currently does it using a pre-defined port). However, if it makes
>> sense to make Nova aware of the EPG right at the outset, then that is
>> even better.
>>
>> I have also noted your suggestion on clarifying the "endpoint"
>> terminology. This was already done in one of the patches you had
>> reviewed earlier, and will do that in the first patch as well (where
>> you pointed it out now).
>>
>> Thanks,
>> ~Sumit.
>>
>> On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton > > wrote:
>>  > Specifying an endpoint group would achieve the
>> --networking-template effects
>>  > you described. The endpoint group would have all of the security
>> policies,
>>  > IP allocation policies, connectivity policies, etc. already setup.
>>  >
>>  >
>>  > On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes > > wrote:
>>  >>
>>  >> On 08/05/2014 01:13 PM, Robert Kukura wrote:
>>  >>>
>>  >>>
>>  >>> 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= ...", requiring no changes to Nova.
>> Later,
>>  >>> slight enhancements to Nova would allow using commands such as
>> "nova
>>  >>> boot ... --nic ep-id= ..." or "nova boot ... --nic
>>  >>> epg-id= ...".
>>  >>
>>  >>
>>  >> Hi Bob,
>>  >>
>>  >> How exactly is the above a friendlier API for the main user of
>> Neutron,
>>  >> which is Nova? I thought one of the main ideas behind the GBP
>> stuff was to
>>  >> create a more declarative and intuitive API for users of Neutron
>> -- i.e.
>>  >> Nova -- to use in constructing needed networking objects. The
>> above just
>>  >> seems to me to be exchanging one low-level object (port) with
>> another
>>  >> low-level object (endpoint or endpoint group)?
>>  >>
>>  >> Perhaps the disconnect is due to the term "endpoint" being used,
>> which,
>>  >> everywhere else in the OpenStack universe, means something
>> entirely
>>  >> different from GBP.
>>  >>
>>  >> I guess, based on my understanding of the *intent* of the GBP
>> API, I would
>>  >> have expected an API more like:
>>  >>
>>  >>  nova boot ... --networking-template 
>>  >>
>>  >> where --networking-template would refer to a network, subnet
>> topology, IP
>>  >> assi

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Jay Pipes]

On 08/05/2014 04:26 PM, Stephen Wong wrote:

Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
integration, and the preliminary idea, as Bob alluded to, is to add
"endpoint" as an option in place of Neutron port. But if we can make
Nova EPG-aware, it would be great.


Is anyone listening to what I'm saying? The term "endpoint" is obtuse 
and completely disregards the existing denotation of the word "endpoint" 
in use in OpenStack today.


So, we've gone ahead and replaced the term "port" in the caller 
interface -- which, besides being too entirely too low-level, actually 
did describe what the object was -- to using a term "endpoint" that 
doesn't describe even remotely what the thing is (a template for a 
collection of networking-related policies and objects) and that already 
has a well-known definition in the OpenStack ecosystem.


That is my point. That is why I brought up the comment on the original 
patch in the series that some docstrings would be helpful for those not 
entirely subscribed to the Tenets of National Dvorkinism.


These interfaces should speak plain old concepts, not networking guru 
arcanum.


Best,
-jay


On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam
mailto:sumitnaiksa...@gmail.com>> wrote:

That's right Kevin, EPG (and its association to the L2/3_Policy)
capture the attributes which would represent the "network-template"
being referenced here.

Jay, what Bob mentioned here was an option to use the "endpoint" as a
one-to-one replacement for the option of using a Neutron port. This is
more so in the context of providing an evolutionary path (from the way
Nova currently does it using a pre-defined port). However, if it makes
sense to make Nova aware of the EPG right at the outset, then that is
even better.

I have also noted your suggestion on clarifying the "endpoint"
terminology. This was already done in one of the patches you had
reviewed earlier, and will do that in the first patch as well (where
you pointed it out now).

Thanks,
~Sumit.

On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton mailto:blak...@gmail.com>> wrote:
 > Specifying an endpoint group would achieve the
--networking-template effects
 > you described. The endpoint group would have all of the security
policies,
 > IP allocation policies, connectivity policies, etc. already setup.
 >
 >
 > On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote:
 >>
 >> On 08/05/2014 01:13 PM, Robert Kukura wrote:
 >>>
 >>>
 >>> 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= ...", requiring no changes to Nova.
Later,
 >>> slight enhancements to Nova would allow using commands such as
"nova
 >>> boot ... --nic ep-id= ..." or "nova boot ... --nic
 >>> epg-id= ...".
 >>
 >>
 >> Hi Bob,
 >>
 >> How exactly is the above a friendlier API for the main user of
Neutron,
 >> which is Nova? I thought one of the main ideas behind the GBP
stuff was to
 >> create a more declarative and intuitive API for users of Neutron
-- i.e.
 >> Nova -- to use in constructing needed networking objects. The
above just
 >> seems to me to be exchanging one low-level object (port) with
another
 >> low-level object (endpoint or endpoint group)?
 >>
 >> Perhaps the disconnect is due to the term "endpoint" being used,
which,
 >> everywhere else in the OpenStack universe, means something entirely
 >> different from GBP.
 >>
 >> I guess, based on my understanding of the *intent* of the GBP
API, I would
 >> have expected an API more like:
 >>
 >>  nova boot ... --networking-template 
 >>
 >> where --networking-template would refer to a network, subnet
topology, IP
 >> assignment policy, collection of security groups and firewall
policies that
 >> the tenant had established prior to booting an instance...
thereby making
 >> the API more intuitive and less cluttered.
 >>
 >> Or is it that I just don't understand this new "endpoint"
terminology?
 >>
 >> Best,
 >> -jay
 >>
 >>
 >> ___
 >> OpenStack-dev mailing list
 >> OpenStack-dev@lists.openstack.org

 >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
 >
 >
 >
 >
 > --
 > Kevin Benton
 >
 > ___
 > OpenStack-dev mailing list
 > OpenStack-dev@lists.openstack.org

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Stephen Wong]

Agreed with Kevin and Sumit here. As a subgroup we talked about Nova
integration, and the preliminary idea, as Bob alluded to, is to add
"endpoint" as an option in place of Neutron port. But if we can make Nova
EPG-aware, it would be great.


On Tue, Aug 5, 2014 at 12:54 PM, Sumit Naiksatam 
wrote:

> That's right Kevin, EPG (and its association to the L2/3_Policy)
> capture the attributes which would represent the "network-template"
> being referenced here.
>
> Jay, what Bob mentioned here was an option to use the "endpoint" as a
> one-to-one replacement for the option of using a Neutron port. This is
> more so in the context of providing an evolutionary path (from the way
> Nova currently does it using a pre-defined port). However, if it makes
> sense to make Nova aware of the EPG right at the outset, then that is
> even better.
>
> I have also noted your suggestion on clarifying the "endpoint"
> terminology. This was already done in one of the patches you had
> reviewed earlier, and will do that in the first patch as well (where
> you pointed it out now).
>
> Thanks,
> ~Sumit.
>
> On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton  wrote:
> > Specifying an endpoint group would achieve the --networking-template
> effects
> > you described. The endpoint group would have all of the security
> policies,
> > IP allocation policies, connectivity policies, etc. already setup.
> >
> >
> > On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes  wrote:
> >>
> >> On 08/05/2014 01:13 PM, Robert Kukura wrote:
> >>>
> >>>
> >>> 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= ...", requiring no changes to Nova. Later,
> >>> slight enhancements to Nova would allow using commands such as "nova
> >>> boot ... --nic ep-id= ..." or "nova boot ... --nic
> >>> epg-id= ...".
> >>
> >>
> >> Hi Bob,
> >>
> >> How exactly is the above a friendlier API for the main user of Neutron,
> >> which is Nova? I thought one of the main ideas behind the GBP stuff was
> to
> >> create a more declarative and intuitive API for users of Neutron -- i.e.
> >> Nova -- to use in constructing needed networking objects. The above just
> >> seems to me to be exchanging one low-level object (port) with another
> >> low-level object (endpoint or endpoint group)?
> >>
> >> Perhaps the disconnect is due to the term "endpoint" being used, which,
> >> everywhere else in the OpenStack universe, means something entirely
> >> different from GBP.
> >>
> >> I guess, based on my understanding of the *intent* of the GBP API, I
> would
> >> have expected an API more like:
> >>
> >>  nova boot ... --networking-template 
> >>
> >> where --networking-template would refer to a network, subnet topology,
> IP
> >> assignment policy, collection of security groups and firewall policies
> that
> >> the tenant had established prior to booting an instance... thereby
> making
> >> the API more intuitive and less cluttered.
> >>
> >> Or is it that I just don't understand this new "endpoint" terminology?
> >>
> >> Best,
> >> -jay
> >>
> >>
> >> ___
> >> OpenStack-dev mailing list
> >> OpenStack-dev@lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> >
> > --
> > Kevin Benton
> >
> > ___
> > 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
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Sumit Naiksatam]

That's right Kevin, EPG (and its association to the L2/3_Policy)
capture the attributes which would represent the "network-template"
being referenced here.

Jay, what Bob mentioned here was an option to use the "endpoint" as a
one-to-one replacement for the option of using a Neutron port. This is
more so in the context of providing an evolutionary path (from the way
Nova currently does it using a pre-defined port). However, if it makes
sense to make Nova aware of the EPG right at the outset, then that is
even better.

I have also noted your suggestion on clarifying the "endpoint"
terminology. This was already done in one of the patches you had
reviewed earlier, and will do that in the first patch as well (where
you pointed it out now).

Thanks,
~Sumit.

On Tue, Aug 5, 2014 at 12:24 PM, Kevin Benton  wrote:
> Specifying an endpoint group would achieve the --networking-template effects
> you described. The endpoint group would have all of the security policies,
> IP allocation policies, connectivity policies, etc. already setup.
>
>
> On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes  wrote:
>>
>> On 08/05/2014 01:13 PM, Robert Kukura wrote:
>>>
>>>
>>> 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= ...", requiring no changes to Nova. Later,
>>> slight enhancements to Nova would allow using commands such as "nova
>>> boot ... --nic ep-id= ..." or "nova boot ... --nic
>>> epg-id= ...".
>>
>>
>> Hi Bob,
>>
>> How exactly is the above a friendlier API for the main user of Neutron,
>> which is Nova? I thought one of the main ideas behind the GBP stuff was to
>> create a more declarative and intuitive API for users of Neutron -- i.e.
>> Nova -- to use in constructing needed networking objects. The above just
>> seems to me to be exchanging one low-level object (port) with another
>> low-level object (endpoint or endpoint group)?
>>
>> Perhaps the disconnect is due to the term "endpoint" being used, which,
>> everywhere else in the OpenStack universe, means something entirely
>> different from GBP.
>>
>> I guess, based on my understanding of the *intent* of the GBP API, I would
>> have expected an API more like:
>>
>>  nova boot ... --networking-template 
>>
>> where --networking-template would refer to a network, subnet topology, IP
>> assignment policy, collection of security groups and firewall policies that
>> the tenant had established prior to booting an instance... thereby making
>> the API more intuitive and less cluttered.
>>
>> Or is it that I just don't understand this new "endpoint" terminology?
>>
>> Best,
>> -jay
>>
>>
>> ___
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> --
> Kevin Benton
>
> ___
> 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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Jay Pipes]

On 08/05/2014 03:24 PM, Kevin Benton wrote:

Specifying an endpoint group would achieve the --networking-template
effects you described. The endpoint group would have all of the security
policies, IP allocation policies, connectivity policies, etc. already setup.


OK. Is there any reason it was called an "endpoint group" then? Perhaps 
I am missing something, but the term endpoint is well-used and 
understood to mean something entirely different in the OpenStack 
ecosystem...


Best,
-jay


On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes mailto:jaypi...@gmail.com>> wrote:

On 08/05/2014 01:13 PM, Robert Kukura wrote:


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= ...", requiring no changes to Nova. Later,
slight enhancements to Nova would allow using commands such as "nova
boot ... --nic ep-id= ..." or "nova boot ... --nic
epg-id= ...".


Hi Bob,

How exactly is the above a friendlier API for the main user of
Neutron, which is Nova? I thought one of the main ideas behind the
GBP stuff was to create a more declarative and intuitive API for
users of Neutron -- i.e. Nova -- to use in constructing needed
networking objects. The above just seems to me to be exchanging one
low-level object (port) with another low-level object (endpoint or
endpoint group)?

Perhaps the disconnect is due to the term "endpoint" being used,
which, everywhere else in the OpenStack universe, means something
entirely different from GBP.

I guess, based on my understanding of the *intent* of the GBP API, I
would have expected an API more like:

  nova boot ... --networking-template 

where --networking-template would refer to a network, subnet
topology, IP assignment policy, collection of security groups and
firewall policies that the tenant had established prior to booting
an instance... thereby making the API more intuitive and less cluttered.

Or is it that I just don't understand this new "endpoint" terminology?

Best,
-jay


_
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.__org

http://lists.openstack.org/__cgi-bin/mailman/listinfo/__openstack-dev 





--
Kevin Benton


___
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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Kevin Benton]

Specifying an endpoint group would achieve the --networking-template
effects you described. The endpoint group would have all of the security
policies, IP allocation policies, connectivity policies, etc. already setup.


On Tue, Aug 5, 2014 at 1:04 PM, Jay Pipes  wrote:

> On 08/05/2014 01:13 PM, Robert Kukura wrote:
>
>>
>> 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= ...", requiring no changes to Nova. Later,
>> slight enhancements to Nova would allow using commands such as "nova
>> boot ... --nic ep-id= ..." or "nova boot ... --nic
>> epg-id= ...".
>>
>
> Hi Bob,
>
> How exactly is the above a friendlier API for the main user of Neutron,
> which is Nova? I thought one of the main ideas behind the GBP stuff was to
> create a more declarative and intuitive API for users of Neutron -- i.e.
> Nova -- to use in constructing needed networking objects. The above just
> seems to me to be exchanging one low-level object (port) with another
> low-level object (endpoint or endpoint group)?
>
> Perhaps the disconnect is due to the term "endpoint" being used, which,
> everywhere else in the OpenStack universe, means something entirely
> different from GBP.
>
> I guess, based on my understanding of the *intent* of the GBP API, I would
> have expected an API more like:
>
>  nova boot ... --networking-template 
>
> where --networking-template would refer to a network, subnet topology, IP
> assignment policy, collection of security groups and firewall policies that
> the tenant had established prior to booting an instance... thereby making
> the API more intuitive and less cluttered.
>
> Or is it that I just don't understand this new "endpoint" terminology?
>
> Best,
> -jay
>
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Kevin Benton
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Jay Pipes]

On 08/05/2014 01:13 PM, Robert Kukura wrote:


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= ...", requiring no changes to Nova. Later,
slight enhancements to Nova would allow using commands such as "nova
boot ... --nic ep-id= ..." or "nova boot ... --nic
epg-id= ...".


Hi Bob,

How exactly is the above a friendlier API for the main user of Neutron, 
which is Nova? I thought one of the main ideas behind the GBP stuff was 
to create a more declarative and intuitive API for users of Neutron -- 
i.e. Nova -- to use in constructing needed networking objects. The above 
just seems to me to be exchanging one low-level object (port) with 
another low-level object (endpoint or endpoint group)?


Perhaps the disconnect is due to the term "endpoint" being used, which, 
everywhere else in the OpenStack universe, means something entirely 
different from GBP.


I guess, based on my understanding of the *intent* of the GBP API, I 
would have expected an API more like:


 nova boot ... --networking-template 

where --networking-template would refer to a network, subnet topology, 
IP assignment policy, collection of security groups and firewall 
policies that the tenant had established prior to booting an instance... 
thereby making the API more intuitive and less cluttered.


Or is it that I just don't understand this new "endpoint" terminology?

Best,
-jay

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Russell Bryant]

On 08/05/2014 01: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.

FWIW, that's the direction we've wanted to move in Nova anyway.  We'd
like to get rid of automatic port creation, but can't do that in the
current stable API.

-- 
Russell Bryant

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Robert Kukura]

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=" just as 
automatic as passing "--nic net-id=". 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 <mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List <mailto:openstack-dev@lists.openstack.org>>

Date: Tuesday, August 5, 2014 at 8:13 PM
To: OpenStack List <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= ...", requiring no changes to Nova. 
Later, slight enhancements to Nova would allow using commands such as 
"nova boot ... --nic ep-id= ..." or "nova boot ... 
--nic epg-id= ...".


-Bob

Thanks
Gary

From: Robert Kukura <mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List <mailto:openstack-dev@lists.openstack.org>>

Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List <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 experi

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Gary Kotton]

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.
Thanks
Gary

From: Robert Kukura mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 5, 2014 at 8:13 PM
To: OpenStack List 
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= ...", requiring no changes to Nova. Later, slight 
enhancements to Nova would allow using commands such as "nova boot ... --nic 
ep-id= ..." or "nova boot ... --nic epg-id= 
...".

-Bob
Thanks
Gary

From: Robert Kukura mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List 
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 migra

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Robert Kukura]

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= ...", requiring no changes to Nova. Later, 
slight enhancements to Nova would allow using commands such as "nova 
boot ... --nic ep-id= ..." or "nova boot ... --nic 
epg-id= ...".


-Bob

Thanks
Gary

From: Robert Kukura <mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List <mailto:openstack-dev@lists.openstack.org>>

Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List <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 proj

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Gary Kotton]

Hi,
Is there any description of how this will be consumed by Nova. My concern is 
this code landing there.
Thanks
Gary

From: Robert Kukura mailto:kuk...@noironetworks.com>>
Reply-To: OpenStack List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, August 5, 2014 at 5:20 PM
To: OpenStack List 
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 c

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Robert Kukura]

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 

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[loy wolfe]

+1 mark


On Tue, Aug 5, 2014 at 4:27 AM, 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.
>
>
> 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
> [3]
>
> ___
> 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

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Armando M.]

Hi,

When I think about Group-Based Policy I cannot help myself but think about
the degree of variety of sentiments (for lack of better words) that this
subject has raised over the past few months on the mailing list and/or
other venues.

I speak for myself when I say that when I look at the end-to-end
Group-Based Policy functionality I am not entirely sold on the following
points:

- The abstraction being proposed, its relationship with the Neutron API and
ODL;
- The way the reference implementation has been introduced into the
OpenStack world, and Neutron in particular;
- What an evolution of Group-Based Policy means going forward if we use the
proposed approach as a foundation for a more application-friendly and
intent-driven API abstraction going forward.
- The way we used development tools for bringing Neutron developers
(reviewers and committers), application developers, operators, and users
together around these new concepts.

Can I speak for everybody when I say that we do not have a consensus across
the board on all/some/other points being touched in this thread or other
threads? I think I can: I have witnessed that there is *NOT* such a
consensus. If I am asked where I stand, my position is that I wouldn't mind
to see how Group-Based Policy as we know it kick the tires; would I love to
see it do that in a way that's not disruptive to the Neutron project? YES,
I would love to.

So, where do we go from here? Do we need a consensus on such a delicate
area? I think we do.

I think Mark's intent, or anyone's who has at his/her heart the interest of
the Neutron community as a whole, is to make sure that we find a compromise
which everyone is comfortable with.

Do we vote about what we do next? Do we leave just cores to vote? I am not
sure. But one thing is certain, we cannot keep procrastinating as the Juno
window is about to expire.

I am sure that there are people hitching to get their hands on Group-Based
Policy, however the vehicle whereby this gets released should be irrelevant
to them; at the same time I appreciate that some people perceive Stackforge
projects as not as established and mature as other OpenStack projects; that
said wouldn't be fair to say that Group-Based Policy is exactly that? If
this means that other immature abstractions would need to follow suit, I
would be all in for this more decentralized approach. Can we do that now,
or do we postpone this discussion for the Kilo Summit? I don't know.

I realize that I have asked more questions than the answers I tried to
give, but I hope we can all engage in a constructive discussion.

Cheers,
Armando

PS: Salvatore I expressly stayed away from the GBP acronym you love so
much, so please read the thread and comment on it :)

On 4 August 2014 15:54, Ivar Lazzaro  wrote:

> +1 Hemanth.
>
>
> On Tue, Aug 5, 2014 at 12:24 AM, Hemanth Ravi 
> wrote:
>
>> Hi,
>>
>> I believe that the API has been reviewed well both for its usecases and
>> correctness. And the blueprint has been approved after sufficient exposure
>> of the API in the community. The best way to enable users to adopt GBP is
>> to introduce this in Juno rather than as a project in StackForge. Just as
>> in other APIs any evolutionary changes can be incorporated, going forward.
>>
>> OS development processes are being followed in the implementation to make
>> sure that there is no negative impact on Neutron stability with the
>> inclusion of GBP.
>>
>> Thanks,
>> -hemanth
>>
>>
>> On Mon, Aug 4, 2014 at 1: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.
>>>
>>>
>>> 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 VPNaa

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Ivar Lazzaro]

+1 Hemanth.


On Tue, Aug 5, 2014 at 12:24 AM, Hemanth Ravi 
wrote:

> Hi,
>
> I believe that the API has been reviewed well both for its usecases and
> correctness. And the blueprint has been approved after sufficient exposure
> of the API in the community. The best way to enable users to adopt GBP is
> to introduce this in Juno rather than as a project in StackForge. Just as
> in other APIs any evolutionary changes can be incorporated, going forward.
>
> OS development processes are being followed in the implementation to make
> sure that there is no negative impact on Neutron stability with the
> inclusion of GBP.
>
> Thanks,
> -hemanth
>
>
> On Mon, Aug 4, 2014 at 1: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.
>>
>>
>> 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
>> [3]
>>
>> ___
>> 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
>
>
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Neutron] Group Based Policy and the way forward

[Hemanth Ravi]

Hi,

I believe that the API has been reviewed well both for its usecases and
correctness. And the blueprint has been approved after sufficient exposure
of the API in the community. The best way to enable users to adopt GBP is
to introduce this in Juno rather than as a project in StackForge. Just as
in other APIs any evolutionary changes can be incorporated, going forward.

OS development processes are being followed in the implementation to make
sure that there is no negative impact on Neutron stability with the
inclusion of GBP.

Thanks,
-hemanth


On Mon, Aug 4, 2014 at 1: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.
>
>
> 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
> [3]
>
> ___
> 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

[openstack-dev] [Neutron] Group Based Policy and the way forward

[Mark McClain]

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.


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
[3]
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev