Open Stack

+1
On Aug 6, 2014 7:07 PM, "Salvatore Orlando" <sorlando at nicira.com> wrote:

> I was asked beforehand what I mean with
>
> * consider GBP an 'experimental' V3 tenant API (this was mentioned
> somewhere in this thread) and treat it accordingly
>
> The group based policies, although implemented as a service plugin, are
> quite different from the ones we have now. Things like firewall, load
> balancer, etc. add something that will be run alongside the "core" API.
> This service plugin instead define a different kind of abstractive
> (declarative vs imperative as it has been mentioned several times) and it
> won't be wrong to say it can replace the core API. To this aim I think it's
> fair to consider it an experimentation around a new tenant API.
>
> In this hypothesis, how should this be treated? The decision ultimately
> does not lie with me.
> I would merely point out that:
> 1) The neutron core team should not stop innovation. If a consistent part
> of the community feels that a declarative base model is that way forward
> and we should experiment with it, than we should do everything we can to
> help this part of the community.
> 2) On the other hand, innovation and experimentation should not deprive
> the core team of significant resources which should be directed first and
> foremost to address the areas identified by the TC as in need of improvement
> In the light of the above, and reflecting on the ultimate question which
> is whether this code should be merged or not. Allow me to say that my final
> thought is that I don't care whether is merged in the main neutron repo or
> somewhere else, as long as it does not constitute additional burden for the
> core team in terms of reviews, maintainability, gate failures (it won't be
> the first time I or other core team members had to chase failures for some
> service plugins digging into logs), and future design decisions (ie: having
> to ask the question - "what about group policy" for every future API
> decision)
>
> Salvatore
>
> PS: did I make post #100?
>
>
>
> On 7 August 2014 00:47, Kevin Benton <blak111 at gmail.com> wrote:
>
>> I think we should merge it and just prefix the API for now with
>> '/your_application_will_break_after_juno_if_you_use_this/'
>>  On Aug 6, 2014 4:41 PM, "Armando M." <armamig at gmail.com> wrote:
>>
>>> This thread is moving so fast I can't keep up!
>>>
>>> The fact that troubles me is that I am unable to grasp how we move
>>> forward, which was the point of this thread to start with. It seems we have
>>> 2 options:
>>>
>>> - We make GBP to merge as is, in the Neutron tree, with some minor
>>> revision (e.g. naming?);
>>> - We make GBP a stackforge project, that integrates with Neutron in some
>>> shape or form;
>>>
>>> Another option, might be something in between, where GBP is in tree, but
>>> in some sort of experimental staging area (even though I am not sure how
>>> well baked this idea is).
>>>
>>> Now, as a community we all need make a decision; arguing about the fact
>>> that the blueprint was approved is pointless. As a matter of fact, I think
>>> that blueprint should be approved, if and only if the code has landed
>>> completely, but I digress!
>>>
>>> Let's together come up with pros and cons of each approach and come up
>>> with an informed decision.
>>>
>>> Just reading free form text, how are we expected to do that? At least I
>>> can't!
>>>
>>> My 2c.
>>> Armando
>>>
>>>
>>> On 6 August 2014 15:03, Aaron Rosen <aaronorosen at gmail.com> wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <blak111 at gmail.com>
>>>> wrote:
>>>>
>>>>> >I believe the referential security group rules solve this problem
>>>>> (unless I'm not understanding):
>>>>>
>>>>> I think the disconnect is that you are comparing the way to current
>>>>> mapping driver implements things for the reference implementation with the
>>>>> existing APIs. Under this light, it's not going to look like there is a
>>>>> point to this code being in Neutron since, as you said, the abstraction
>>>>> could happen at a client. However, this changes once new mapping drivers
>>>>> can be added that implement things differently.
>>>>>
>>>>> Let's take the security groups example. Using the security groups API
>>>>> directly is imperative ("put a firewall rule on this port that blocks this
>>>>> IP") compared to a higher level declarative abstraction ("make sure these
>>>>> two endpoints cannot communicate"). With the former, the ports must support
>>>>> security groups and there is nowhere except for the firewall rules on that
>>>>> port to implement it without violating the user's expectation. With the
>>>>> latter, a mapping driver could determine that communication between these
>>>>> two hosts can be prevented by using an ACL on a router or a switch, which
>>>>> doesn't violate the user's intent and buys a performance improvement and
>>>>> works with ports that don't support security groups.
>>>>>
>>>>> Group based policy is trying to move the requests into the declarative
>>>>> abstraction so optimizations like the one above can be made.
>>>>>
>>>>
>>>> Hi Kevin,
>>>>
>>>> Interesting points. Though, let me ask this. Why do we need to move to
>>>> a declarative API abstraction in neutron in order to perform this
>>>> optimization on the backend? For example, In the current neutron model say
>>>> we want to create a port with a security group attached to it called web
>>>> that allows TCP:80 in and members who are in a security group called
>>>> database. From this mapping I fail to see how it's really any different
>>>> from the declarative model? The ports in neutron are logical abstractions
>>>> and the backend system could be implemented in order to determine that the
>>>> communication between these two hosts could be prevented by using an ACL on
>>>> a router or switch as well.
>>>>
>>>> Best,
>>>>
>>>> Aaron
>>>>
>>>>
>>>>>
>>>>> _______________________________________________
>>>>> OpenStack-dev mailing list
>>>>> OpenStack-dev at lists.openstack.org
>>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> OpenStack-dev mailing list
>>>> OpenStack-dev at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>>
>>>>
>>>
>>> _______________________________________________
>>> OpenStack-dev mailing list
>>> OpenStack-dev at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140806/5cc65683/attachment-0001.html>