Quick Question: >From what I understand, GBP is a high level declarative way of configuring the network which ultimately gets mapped to basic Neutron API's via some business logic. Why can't it be in a module of it own? In that way users who want to use it can just install that and use it as an interface to interact with Neutron while the rest continue with their lives as usual.
On Fri, Aug 8, 2014 at 9:25 PM, Kevin Benton <blak...@gmail.com> wrote: > The existing constructs will not change. > On Aug 8, 2014 9:49 AM, "CARVER, PAUL" <pc2...@att.com> wrote: > >> Wuhongning [mailto:wuhongn...@huawei.com] wrote: >> >> >Does it make sense to move all advanced extension out of ML2, like >> security >> >group, qos...? Then we can just talk about advanced service itself, >> without >> >bothering basic neutron object (network/subnet/port) >> >> A modular layer 3 (ML3) analogous to ML2 sounds like a good idea. I still >> think it's too late in the game to be shooting down all the work that the >> GBP team has put in unless there's a really clean and effective way of >> running AND iterating on GBP in conjunction with Neutron without being >> part of the Juno release. As far as I can tell they've worked really >> hard to follow the process and accommodate input. They shouldn't have >> to wait multiple more releases on a hypothetical refactoring of how L3+ vs >> L2 is structured. >> >> But, just so I'm not making a horrible mistake, can someone reassure me >> that GBP isn't removing the constructs of network/subnet/port from >> Neutron? >> >> I'm under the impression that GBP is adding a higher level abstraction >> but that it's not ripping basic constructs like network/subnet/port out >> of the existing API. If I'm wrong about that I'll have to change my >> opinion. We need those fundamental networking constructs to be present >> and accessible to users that want/need to deal with them. I'm viewing >> GBP as just a higher level abstraction over the top. >> >> >> _______________________________________________ >> 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 > > -- Akash
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev