Bug 1042434

Cloned from launchpad blueprint https://blueprints.launchpad.net/neutron/+spec/nvp-async-backend-communication.

Description:

Currently the NVP plugin receives requests from the Quantum API layer, performs all the relevant operations on the NVP plugin, and then updates the database when they're successfully completed.

This has a few disadvantages:
- GET operations always hit the NVP platform, and the only info retrieved from there which is not already in the Quantum DB is the status of the resource; this makes GET operations considerably slow.
- POST/PUT/DELETE operations do not return if the operations on NVP are not completed. Some are fairly slow
- There is a lot of orchestration code in the plugin logic
- The plugin has to explicitly deal with rolling back NVP resources in case of failures

The above listed disadvantages cause several downsides in the NVP plugin:
- excessive chattiness between Quantum and NVP
- slow API execution (especially when VMs are booted)
- hard to maintain (and hence error prone) code

For this reason we are proposing to migrate to a different model, which shall have the following benefits:

- All operations on Quantum terminate on the Quantum DB and responses are immediately returned to the user
- Resources' statuses are retrieved asynchrously (periodic tasks) - the backend might also provide notifications; appropriate mechanisms might be put in place to ensure 'stale' state information are never returned.
- Extremely reduced chattines between Quantum and NVP
- Simplified code base, with the complexity moved away from the plugin and split across several modules
- possibility of scaling out the Quantum plugin backend.

To this aim POST/PUT/DELETE operations will be performed asynchronously on the NVP backend. It will be up to the plugin ensuring that there's no config mismatch between Quantum and NVP, and if there is, the mismatch should be reported to the user when querying the objects/



More details about the design and the implementation plan will follow.
This blueprint is likely to be split in multiple blueprints after the design will be committed.




Specification URL (additional information):

None