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

Reply via email to