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." <arma...@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 <aaronoro...@gmail.com> wrote:
>
>>
>>
>>
>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <blak...@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@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
