[NEUTRON-2] ISSUE in Bulk Neutron Requests Created: 12/Jun/14  Updated: 19/Oct/17  Resolved: 20/Feb/15

Status: Resolved
Project: neutron
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: Ankit agarwal Assignee: Unassigned
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: Linux
Platform: PC

Attachments: Microsoft Word Bug1191_investigation.docx    
Issue Links:
Blocks
blocks NEUTRON-3 Support for adding network/ports/subnets Resolved
External issue ID: 1191

 Description   

Bulk requests for creating network, subnet, port are not implemented as per the neutron v2.0 spec, as the bulk requests are atomic.
Following are two issues:

1. Negative cases of bulk request

For the cases, where the bulk request is able to add a network/port/subnet successfully, there are no issues. But, if any of the requests fails, there is no logic in ODL which can delete the previously created networks/subnets/ports.

For example: If a request for creating 5 networks is failing at creating the 3rd network, there should be tear down of the first two networks.
So canCreateNetwork method will check whether network can be created or not for the bulk request.
After that addnetwork method will add the networks to the local cache. and when it fails at creating 3rd network there should be logic that deletes the previously created networks.

2. Support for adding network/ports/subnets

In NeutronNetworksNorthbound class we are using INeutronNetworkAware interface for implementing canCreateNetwork and neutronNetworkCreated but there is no method for adding network wherein the plugins extending the neutron APIs can actually add or create the network. A support for the same should be provided.

 Comments   
Comment by Priyanka Chopra [ 15/Jul/14 ]

Fix for NEUTRON-2

https://git.opendaylight.org/gerrit/9007

Comment by Ryan Moats [ 22/Jul/14 ]

part 2 of the original defect has been split off into enhancement request 1404 and this bug focused on part 1 only

Comment by Priyanka Chopra [ 22/Jul/14 ]

Hi Ryan,

Both the issues mentioned above(1191 + 1404) are related to one another and fix for them have already been commited : https://git.opendaylight.org/gerrit/9007
Request you to please review the same.

Also below is the detailed explanation:
Presently if any bulk request fails, post canCreateNetwork() ie while actually creating the network(by any southbound plugin in underlying framework), the same logic cannot be implemented/extended in any southbound plugin.

Present implementation:
networkInterface.addNetwork(test);

Suggested fix:
Object[] instances1 = ServiceHelper.getGlobalInstances (INeutronNetworkCRUD.class, this, null);
for (Object instance : instances1) {
INeutronNetworkCRUD service = (INeutronNetworkCRUD) instance;
boolean status = service.addNetwork(test);
if (!status) {
Iterator<NeutronNetwork> j = bulk.iterator();
while(j.hasNext()){
NeutronNetwork tempNetwork = j.next();
if(tempNetwork.getNetworkUUID().matches(test.getNetworkUUID()))

{ networkInterface.removeNetwork(tempNetwork.getNetworkUUID()); break; }

service.removeNetwork(tempNetwork.getNetworkUUID());
}
return Response.status(500).build();
}
}

With above fix the plugin will be able to cater the create network request as well as return a boolean status thereby confirming whether the network creation was successful or not. Based on the status if the network creation fails the same can be deleted right away.

Comment by Ryan Moats [ 22/Jul/14 ]

I did review the patchset and -1'd it because while the two items are related, one is a defect and the other is an enhancement. I understand the defect and don't want to hold that hostage to the fact that I don't yet agree with the enhancement implementation

Comment by Priyanka Chopra [ 23/Jul/14 ]

Attached is the detailed investigation report.
Can we schedule a follow-up call to discuss the same(We are in IST timezone)

Comment by Priyanka Chopra [ 23/Jul/14 ]

Attachment Bug1191_investigation.docx has been added with description: Investigation Report - for followup discussion

Comment by Ryan Moats [ 17/Feb/15 ]

Moving from current project to neutron

Comment by Ryan Moats [ 20/Feb/15 ]

This is not a bug and the suggested patches are incorrect because they are attempting to modify the I*Aware construct without properly publicizing those changes.

A service is supposed to create/update/delete the downstream item when its *Created, *Updated, or *Deleted method is called. There is no need for separate blocks of code for specifically creating downstream items, and those blocks of code would have to be part of the I*Aware contract if added.

Once a service says yes to the can* method, it no longer gets a nay vote to stop the process - it now takes responsibility for "doing what it can"

Generated at Wed Feb 07 20:25:17 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.