Opened 11 years ago
Closed 11 years ago
#1100 closed (fixed)
SCS picked same tag for 2 paths through same interface
Reported by: | Aaron Helsinger | Owned by: | Aaron Helsinger |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | MAXSCS | Version: | SPIRAL5 |
Keywords: | Cc: | lnevers@bbn.com, xyang@maxgigapop.net | |
Dependencies: |
Description
I had a request for 2 links from the same interface. The SCS seems to have picked the same VLAN tag for both.
Attachments (3)
Change History (11)
Changed 11 years ago by
Attachment: | ln-test-4links.xml added |
---|
Changed 11 years ago by
Attachment: | scs-result.json added |
---|
comment:1 Changed 11 years ago by
Cc: | lnevers@bbn.com xyang@maxgigapop.net added |
---|---|
Owner: | changed from xyang@maxgigapop.net to Aaron Helsinger |
comment:2 Changed 11 years ago by
Seems that all stitching attempts today are failing with the error below. May be related to changes in this ticket:
$ stitcher.py createsliver lnstitch ./stitch-ig-gpo-ig-utah.rspec 13:20:52 INFO stitcher: Loading config file /home/lnevers/.gcf/omni_config 13:20:52 INFO stitcher: Using control framework portal 13:20:52 INFO stitcher: Checking that slice lnstitch is valid... 13:20:53 INFO stitcher: Slice urn:publicid:IDN+ch.geni.net:ln-prj+slice+lnstitch expires on 2013-09-12 17:19:34 UTC 13:20:54 INFO stitcher: <Aggregate urn:publicid:IDN+utah.geniracks.net+authority+cm> speaks AM API v3, but sticking with v2 13:20:54 INFO stitcher: <Aggregate urn:publicid:IDN+instageni.gpolab.bbn.com+authority+cm> speaks AM API v3, but sticking with v2 13:20:54 INFO stitcher: <Aggregate urn:publicid:IDN+emulab.net+authority+cm> speaks AM API v3, but sticking with v2 13:20:54 INFO stitcher: Stitched reservation will include resources from these aggregates: 13:20:54 INFO stitcher: <Aggregate urn:publicid:IDN+utah.geniracks.net+authority+cm> 13:20:54 INFO stitcher: <Aggregate urn:publicid:IDN+instageni.gpolab.bbn.com+authority+cm> 13:20:54 INFO stitcher: <Aggregate urn:publicid:IDN+emulab.net+authority+cm> 13:20:54 INFO stitcher: <Aggregate urn:publicid:IDN+ion.internet2.edu+authority+am> Traceback (most recent call last): File "/home/lnevers/gcf-2.4dev/src/stitcher.py", line 193, in <module> sys.exit(main()) File "/home/lnevers/gcf-2.4dev/src/stitcher.py", line 174, in main text, item = call(argv) File "/home/lnevers/gcf-2.4dev/src/stitcher.py", line 165, in call return handler.doStitching(args) File "/home/lnevers/gcf-2.4dev/src/omnilib/stitchhandler.py", line 173, in doStitching lastAM = self.mainStitchingLoop(sliceurn, self.parsedUserRequest.dom) File "/home/lnevers/gcf-2.4dev/src/omnilib/stitchhandler.py", line 360, in mainStitchingLoop lastAM = launcher.launch(self.parsedSCSRSpec, self.scsCalls) File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/launcher.py", line 51, in launch agg.allocate(self.opts, self.slicename, rspec.dom, scsCallCount) File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 387, in allocate self.requestDom = self.getEditedRSpecDom(rspecDom) File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 671, in getEditedRSpecDom path.editChangesIntoDom(domNode) File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 147, in editChangesIntoDom hop.editChangesIntoDom(domHopNode) File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 2020, in editChangesIntoDom self._hop_link.editChangesIntoDom(child) File "/home/lnevers/gcf-2.4dev/src/omnilib/stitch/objects.py", line 2280, in editChangesIntoDom vlan_range[0].appendChild(Document.createTextNode(newVlanRangeString)) NameError: global name 'Document' is not defined $
comment:3 Changed 11 years ago by
The fix has been reverted. There is no quick solution for this. In most cases, randomization help avoid contention. I will find a better solution for this.
Leave it open for now.
comment:4 Changed 11 years ago by
Hello Xi, Aaron said the latest error was actually a stitcher bug and that he would be providing a fix soon. So your fix may have brought up the error, but was not the problem.
comment:5 Changed 11 years ago by
The problem with my fix was that all <vlanRangeAvailability> elements became empty.
I think that element needs to be populated with originally advertised vlan range.
comment:6 Changed 11 years ago by
SCS has been updated with a new fix.
<vlanRangeAvailability> will not be empty now. Instead, any "suggested/assigned VLAN(s)" for prior paths in the same rspc will be excluded from <vlanRangeAvailability> in subsequent paths.
Re-assign to Aaron and Lusisa for testing.
Changed 11 years ago by
Attachment: | scs-result-new.rspec.xml added |
---|
Example SCS result rspec after fix.
comment:7 Changed 11 years ago by
I've tried a few times and haven't reproduced the bug today. And the sample result rspec you attached looks reasonable to me.
comment:8 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Still can't reproduce. Looks fixed.
In SCS core code (mxtce), layer2 links have avaiableVlanRange, suggestedVlanRange and assignedVlanRange.
The original code only excluded assignedVlanRange from being dup provisioned.
A revision has been made to treat suggestedVlanRange the same as assignedVlanRange. This might not be the best solution but it should work for now.
Re-assign to Aaron and Luisa to test more.