Make Neutron deployment task more granular

Guys, who make network plugins for Fuel has many inconveniences if changes to deployment process of Neutron required.

Problem description

Usually network plugins for Fuel made by one design scheme:

  • in the pre-deployment task:
    • install required packages
  • deploy cluster with most convenient for plugin configuration
  • in the post-deployment task:
    • install or replace plugin-specific packages
    • try to re-configure already configured stuff.

This approach looks non-optimal for all cases. For some cases re-configuration is impossible. For such cases all already deployed Neutron related stuff should be removed and re-deployed by plugin.

Since 7.0 release fuel plugins got ability to make change into deployment graph. Insert his own tasks and replace existing tasks now possible.

But Fuel has Monolitic (one-task based) Neutron granula. I.e. plugin has no ability for change deployment graph for Neutron.

This blueprint provides required changes to deployment graph. Monolitic Neutron task should be separated to set of small tasks. One task per one logically isolated job.

Proposed approach should greatly facilitate the process of network plugins development.

Proposed changes

Current deployment graph for network part looks like:

Proposed graph for network part should be:

Legend of tasks on scheme above:

  • neutron-db – configures Neutrons database access.
  • neutron-keystone – configures Neutrons access to identity service
  • openstack-network-common-config – This task applicable for controller and compute nodes. General neutron packages and common config option configured here.
  • openstack-network-server-config – Neutron-server configuration. Neutron server doesn’t start here, because Neutron-plugin should be configured into his own task.
  • openstack-network-plugins-l2 – Configuration of ML2 Neutron plugin and. Start Neutron server and openvswitch-agent.
  • openstack-network-networks – networks and subnets into Neutron DB creates here.
  • openstack-network-routers – Neutron virtual routers into Neutron DB creates here.
  • openstack-network-agents-l3 – configuration and start Neutron-l3-agent.
  • openstack-network-agents-dhcp – configuration and start Neutron-dhcp-agent.
  • openstack-network-agents-metadata – configuration and start Neutron-metadata-agent.
  • openstack-network-server-nova – server part of Nova configured here for using Neutron as network backend.
  • openstack-network-compute-nova – configure Nova-compute service for using Neutron as network backend. Or configure Nova-network on compute nodes if Nova-network case choosed.

Fuel Library

Are following changes required to Fuel Library puppet manifests:

  • Our wrapper around upstream Neutron module should be refactored.
  • Code from Openstack::Network, Openstack::Network::Create_network Openstack::Network::Create_router, Openstack::Network::Neutron_agents should be moved to corresponded granulas.
  • Manifests Openstack::Network, Openstack::Network::Create_network Openstack::Network::Create_router, Openstack::Network::Neutron_agents should be removed.


Plugin developers should take into account changes of deploing graph. This changes brakes backward compatibility. For all network-related plugins for previous release will not work after this change.

Web UI



Data model





RPC Protocol


Fuel Client



Leave all as is.

Upgrade impact


Security impact


Notifications impact


End user impact


Performance impact

Deployment time may be slightly increased, because amount of deployment tasks are increased.

Deployment impact


Developer impact


Infrastructure impact


Documentation impact


Expected OSCI impact




Work Items

  • rewrite some granulas (puppet manifests) into osnailyfacter module
  • modify deployment graph


Feature Lead: Sergey Vasilenko

Mandatory reviewer: Igor Zinovik, Sergey Kolekonov

Developers: Dmitry Iliyn, Sergey Vasilenko

QA: Anastasiia Urlapova



Testing, QA

No changes. All existing tests should be used.

Acceptance criteria

Acceptance criteria does not different from one for ordinary bugfixes to fuel-library. Standard BVT should be passed for ordinary configurations