Edgar Magana wrote: > This is a very solid plan. Maybe to fair on the current state of the devstack > with neutron functionality, what will be the disadvantage(s) of this change > from your perspective? >
A user's local.conf will probably get a little bigger - and I think a lot of the issues about Neutron's inability to run out of the box will be exposed. I mean let's face it - Neutron, installed from source, with no configuration Does Not Workâ˘. There are not enough settings that have defaults set, for it to actually run. This was made painfully obvious to me when I had to make new revisions to the Neutron DevStack refactor, where I had to add more inisets, in order for Neutron to finish stacking correctly. Did you know, for example, that we rely on DevStack[1] to set the list of mechanism_drivers? Without this, you'll get an empty mechanism_driver list and nothing will ever be wired up. I'm sure there is an argument that can be made about why there is no default for mechanism_drivers in ML2, since there are lots of options. But, I think that we can at least enable the ones that we have in Neutron's main tree. Packagers who make packages for each mechanism driver (LB, OVS, etc..) already had to handle things like mechanism_drivers in the Ml2 configuration already, so it shouldn't really impact them since we're only setting a default if nothing is set, and their packages should explicitly set it. [1]: https://github.com/openstack-dev/devstack/blob/master/lib/neutron_plugins/ml2#L27 -- 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
