[network] agent and common recipe cleanup

Registered by Mark Vanderwiel

Because of the current layout of the network recipes all using a shared common recipe, several issues have come up.

See this wiki page for the status of the Neutron plugins: https://wiki.openstack.org/wiki/Neutron_Plugins_and_Drivers

We need to seriously consider removing ALL non-ML2 support and focus on doing ML2 with OVS/LB better.

- The neutron-server will start on nodes which run neutron agents (like openvswitch), this means neutron-server will run on compute nodes. The neutron-server service resource is defined in 3 places, common, server and openvswitch.
-- A possible solution is to generate configure files in common recipes and restart services in component recipes using subscribes notification. This will prevent starting unnecessary services on some nodes.
Having the neutron-service resource only in the server recipe.
-- Another idea would be to use a different common recipe for agents then for the server.

- The recipes for non-ML2 plugins, like cisco and brocade, are all empty and being handled within common and server.
-- Remove these is really not needed, or at least fix them to set the core_plugin attribute and include the server recipe to make them useful.

- Doc the recipes and sample usage in the README correctly

- Add specs for at least one other non-ML2 plugin?

- [~alanmeadows] I would like to see us also support ML2+OVS+TUNNELS+VLANs in our basic approach for example by classifying nodes as "VLAN" based nodes (and thus require the appropriate bridges set up - based on a role) and those that are using an overlay - this allows the Enterprise to deploy hybrid clouds that support both VLANs for latency sensitive applications in a separate availability zone and ML2+OVS+TUNNELS for an SDN arm to the cloud

Blueprint information

Status:
Complete
Approver:
JJ Asghar
Priority:
Low
Drafter:
Mark Vanderwiel
Direction:
Approved
Assignee:
None
Definition:
Superseded
Series goal:
Accepted for liberty
Implementation:
Not started
Milestone target:
None
Completed by
Jan Klare

Related branches

Sprints

Whiteboard

I think any plugin specific config (plugin ini files) should go in that plugin's recipes. The neutron-server service, as defined in a single recipe (probably server) should then subscribe to each of these config files, as well as the main neutron.conf that is laid down in common.

Similarly, where the plugin has it's own service (which would be defined in the plugin recipe), this service should subscribe both to it's own ini file as well as the main neutron.conf.

Personally I think that having the services subscribe to the relevant config files is the cleanest way.

-Darren Birkett (mancdaz)

Gerrit topic: https://review.openstack.org/#q,topic:apache_ssl_spec,n,z

Addressed by: https://review.openstack.org/140891
    Incorporate ssl_certificate cookbook for more robust SSL support

Gerrit topic: https://review.openstack.org/#q,topic:rebase,n,z

Addressed by: https://review.openstack.org/141459
    Refactor Neutron Cookbook to Remove common.rb

Network cookbook was completely refactored during mitaka cycle.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.