Yong approach makes sense - we certainly want to leverage DB transaction for the base v2 plugin.
It is also important that the client provides a way for leveraging this API capability - and I will create a related bug report in python-quantumclient for this.
What needs to be discussed and decided is, in my opinion, the following:
- should bulk create/delete part of the core API or an extension?
- do we need a different URI for the requests or can we reuse the existing ones (e.g.: POST /networks with a list of networks in the request body to be created atomically)
- do we want to support bulk updates as well?
It is also my opinion that this fix should concern bulk operations on one kind of resource only. That is to say, we will allow to create a bunch of ports in a single operation, but creating a network with a set of ports and then subnets with allocated IPs in a single operation is certainly out of scope here, and I'm not sure we even want this in the Quantum API.
Yong approach makes sense - we certainly want to leverage DB transaction for the base v2 plugin. quantumclient for this.
It is also important that the client provides a way for leveraging this API capability - and I will create a related bug report in python-
What needs to be discussed and decided is, in my opinion, the following:
- should bulk create/delete part of the core API or an extension?
- do we need a different URI for the requests or can we reuse the existing ones (e.g.: POST /networks with a list of networks in the request body to be created atomically)
- do we want to support bulk updates as well?
It is also my opinion that this fix should concern bulk operations on one kind of resource only. That is to say, we will allow to create a bunch of ports in a single operation, but creating a network with a set of ports and then subnets with allocated IPs in a single operation is certainly out of scope here, and I'm not sure we even want this in the Quantum API.