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