Open Stack

I would reword that to:

'/your_application_may_break_after_juno_if_you_use_this/'

in the event of the possibility that it doesn't break. ;-)

On Wed, Aug 6, 2014 at 3:47 PM, 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
>