Ad Rspec: stitching extension issues

[ahelsing@bbn.com]

There are a few issues with the stitching extension as implemented. See email from Tom Lehman with details.

• Only include the stitching element once
• Only include 1 aggregate in that extension
• Ensure consistent node/port/link IDs and references to nodes and links in the main body
• If you don't support scheduling, say scheduled=false in the stitching extension
• trim excess whitespace

Tom Lehman's comments on making IDs match:

i) Main Body of Advertisement RSpec Link Element Population (for links which connect to External Aggregates):
-there must be a link element for each connection to an External Aggregate.
-these link elements will each have two interface_ref component_id
-one of the interface_ref component_id references a local node->interface component_id
-the other interface_ref component_id is equal to a  link--->interface_ref component_id  in a link element of the External Aggregate 
-both of the peering Aggregates need to point to each other in consistent manner within their mainBody:link elements


ii) Stitching Extension Element Population:
-There will be one Stitching Extension with a single aggregate element per Aggregate
-Identify all mainBody:link elements which have a link->interface_ref component_id which is for an External Aggregate.'
-A stitch:node element must be created for each of the nodes associated with the above identified mainBody:link elements
    Note:  only the mainBody:node elements which are part of a connection to an External Aggregate must be included
                in the Stitching Extension.  However, Aggregates may include other mainBody:node elements if they desire.
-The stitch:node elements are populated as follows described below:
   --stitch:node id==mainBody:node component_id
   --stitch:port id==mainBody:link->interface_ref component_id (which equals a node->interface component_id)
   --stitch:link id==stitch:portid with ":some-descriptive-term" appended
   --stitch:remoteLinkId==the stitch:link id from the External Aggregate stitching extension
-both of the peering Aggregates need to point to each other in consistent manner with  their stitch:link and stitch:remoteLinkId elements

[ibaldin@renci.org]

i) Currently we don't allow stitching to external aggregates (anything we stitch to has an NDL definition). For this reason there are no external advertisements. So this is only likely to get fixed when we implement stitching to external non-Orca aggregates.

The exception is a 'node-on-a-vlan' feature we just finished. In that one it will show stitching to a VLAN on a set of ports. But that's a manifest issue, not an ad. For mesoscale VLAN we will define a null aggregate in ORCA.

ii) This may be tricky to fix, but I will see what I can do. We don't consider them one aggregate, so there are multiple stitching extensions in the translation.

[ahelsing@bbn.com]

On i), do you have a plan for when you hope to implement stitching to external non-Orca aggregates? And per your comments on ticket #26, is the problem largely at the ExoSM, where the individual racks are easier?

[ahelsing@bbn.com]

I've created a bunch of more specific tickets. See tickets #36, #37, #38, #39, #40, #45

[ahelsing@bbn.com]

for clarity, close this in favor of the more specific tickets