I don't think people are choosing because of the shortest route but rather these may be two different items that are not completely exclusive but different enough. Nova parity addresses the scope to have existing well understood and stable api currently supported in nova to be supported in neutron and a dash to make that code stable. The goal is to move quickly to enable replacement of nova networking. While group policy is offering additional abstractions which are richer that enables easier usage of networking.
Both teams have been working diligently towards that goal. As pedro points out there are several people from different organizations working on GBP to ensure stability and closely reviewed code is checked in. I think both nova parity and GBP can go in parallel, hence my choice of option 1 On Wed, Aug 6, 2014 at 6:13 PM, Armando M. <arma...@gmail.com> wrote: > On 6 August 2014 17:34, Prasad Vellanki < > prasad.vella...@oneconvergence.com> wrote: > >> It seems like Option 1 would be preferable. User can use this right >> away. >> >> > People choosing Option 1 may think that the shortest route may be the > best, that said the drawback I identified is not to be dismissed either > (and I am sure there many more pros/cons): an immature product is of good > use to no-one, and we still have the nova parity that haunts us. > > I think this could be another reason why people associated GBP and > nova-network parity in this thread: the fact that new abstractions are > introduced without solidifying the foundations of the project is a risk to > GBP as well as Neutron itself. > > > _______________________________________________ > 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
