On 08.04.2016 14:47, Assaf Muller wrote:
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.
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-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
__________________________________________________________________________
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
