>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.
How does a separate project fix this? It seems to me like it just incurs all of the extra overhead of an extra project and doesn't do anything to improve the parity efforts. On Wed, Aug 6, 2014 at 7: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 > > -- Kevin Benton
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
