As Ronak said, this thread is starting to move in a lot of different directions, ranging from correctness of the blueprint approval process to nova/neutron integration, which are rather off topic.
In particular it seems things are being skewed towards a discussion around nova parity, whereas actually some people have just chimed in with their honest opinion that with all the stuff still needed to finally be able to make neutron "THE" openstack networking solution, the effort towards adding a new tenant facing API appears to have a lesser priority. I just want to reassure everybody that the majority of the core team and a large part of the community have actually made this their first priority. For what is worth, some of them have even delayed plugin/driver specific development to this aim. So I would invite to go back to the original subject of the discussion, that is to say decide as a community what would the best way forward for this effort. I see so far the following options: - merge the outstanding patches, assuming there are no further technical concerns, and include GBP in Juno. - consider GBP an 'experimental' V3 tenant API (this was mentioned somewhere in this thread) and treat it accordingly - delay to the next release - move the development of the service plugin to stackforge as suggested to this thread. More options are obviously welcome! Regards, Salvatore On 6 August 2014 19:40, Ivar Lazzaro <ivarlazz...@gmail.com> wrote: > Which kind of uncertainty are you referring to? > > Given that the blueprint was approved long ago, and the code has been > ready and under review following those specs... I think GBP is probably the > patch with the least effort to be merged right now. > > Ivar. > > > On Wed, Aug 6, 2014 at 7:34 PM, Joe Gordon <joe.gord...@gmail.com> wrote: > >> >> On Aug 6, 2014 10:21 AM, "Ronak Shah" <ronak.malav.s...@gmail.com> wrote: >> > >> > We have diverged our attention towards nova-network-> neutron parity on >> this thread unnecessarily. >> > >> > Can we discuss and collectively decide on what is the way forward for >> GBP in Juno release? >> > >> > Efforts have been made by the subteam starting from throwing PoC at >> last summit to spec approval to code review. >> > >> > There are usefulness to this feature and I think everyone is on the >> same page there. >> > >> > Let us not discourage the effort by bringing in existing neutron issue >> in play. >> >> > Yes, we has a neutorn community needs to fix that with highest >> priority. >> > But this is orthogonal effort. >> >> The efforts may be orthogonal, but the review team and bandwidth of said >> team is one and the same. Making nova-network the highest priority means >> pushing other blueprints back as needed. And since there is still so much >> uncertainty around GPB this late in the cycle, IMHO it's a good candidate >> for getting deferred. >> >> > If endpoint is not a likeable preferred name than lets propose more >> meaningful alternative. >> > Let us try to find a middle ground on how this feature can be made >> generally available. >> > >> > Thanks, >> > Ronak >> > >> > _______________________________________________ >> > OpenStack-dev mailing list >> > OpenStackemail@example.com >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> >> >> _______________________________________________ >> OpenStack-dev mailing list >> OpenStackfirstname.lastname@example.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > _______________________________________________ > OpenStack-dev mailing list > OpenStackemail@example.com > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStackfirstname.lastname@example.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev