+1 On Aug 6, 2014 7:07 PM, "Salvatore Orlando" <[email protected]> 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 <[email protected]> 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." <[email protected]> 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 <[email protected]> wrote: >>> >>>> >>>> >>>> >>>> On Wed, Aug 6, 2014 at 12:46 PM, Kevin Benton <[email protected]> >>>> 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 >>>>> [email protected] >>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> OpenStack-dev mailing list >>>> [email protected] >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>>> >>> >>> _______________________________________________ >>> OpenStack-dev mailing list >>> [email protected] >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
