On Fri, Apr 8, 2016 at 3:37 PM, Doug Wiegley <doug...@parksidesoftware.com> wrote: > >> On Apr 8, 2016, at 1:28 PM, Sean M. Collins <s...@coreitpro.com> wrote: >> >> Assaf Muller wrote: >>> I do want to say that ML2's "mechanism_drivers" option probably does >>> not have a default for the same reason we do not have a default for >>> the core_plugin value, we don't want to play favorites. From Neutron's >>> point of view, ignoring the existence of Devstack and upstream CI, I >>> think that makes sense. >>> >> >> True, I do see your point. >> >> I do however think, that if you do pick the ML2 plugin as your >> core_plugin, it should have some mechanism drivers enabled by default. You >> shouldn't have to pick core_plugin, then be forced to pick >> mechanism_drivers. I'd rather see some mechanism_drivers already >> enabled, and if you have a difference in opinion, set mechanism_drivers >> in your local.conf. > > I previously thought that a default there made no sense, but really, how is a > default core plugin of ml2 with a default mech of local going to hurt anyone?
I was playing devil's advocate. I'm fine with picking ML2 and OVS+LB. You will face resistance from people that have an interest in having the ML2 reference implementation gone. > > We had a big argument of whether to have a default DNS resolver… 8.8.8.8 > leaks internal info to a third-party, hypervisor default potentially leaks > infrastructure details. Not having a default there at least has some > security/privacy implications. > > There are likely things that we can start defaulting in a saner way. > > doug > > > >> >> -- >> Sean M. Collins >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev