Open Stack

On 08.04.2016 14:47, Assaf Muller wrote:
> 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.
I think that idea of getting rid of devstack configuration is good thing.
Instead of learning how to setup something using internal devstack 
variables, would be good to use targeted values/settings.
But it also shows some kind of problem. We need to have good default 
configuration to setup devstack.
Right now, default All-in-one configuration is done by this [1]:

[[local|localrc]]
disable_service n-net
enable_service q-svc
enable_service q-agt
enable_service q-dhcp
enable_service q-l3
enable_service q-meta
# Optional, to enable tempest configuration as part of devstack
enable_service tempest


That's all what's necessary to run Neutron in devstack. For someone who 
doesn't want to learn about Neutron and how it works, it's enough (yes, 
there are people who don't want know anything about the best project, 
like Neutron :))
When Sean's idea will materialize, it's required to be sure, that we 
have default config, that can be just copy-pasted without thinking.

[1] https://wiki.openstack.org/wiki/NeutronDevstack

dasm
--
Darek Smigiel
>> 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev