[openstack-dev] [devstack][neutron] Eliminating the DevStack layer
assaf at redhat.com
Fri Apr 8 19:47:50 UTC 2016
On Fri, Apr 8, 2016 at 3:37 PM, Doug Wiegley
<dougwig at parksidesoftware.com> wrote:
>> On Apr 8, 2016, at 1:28 PM, Sean M. Collins <sean at 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… 184.108.40.206 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.
>> Sean M. Collins
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev