stitcher merge links using clientid plus component_manager

[ahelsing]

Stitcher currently tries to merge links in manifests using the client_id and checking that there is a vlan tag on the link (as a measure that this AM is involved with the link).

Technically the same slice could have 2 links with the same client_id at different AMs. Ugly, but I think possible to do.

So the current code does not handle this, and should.

However, at a given AM the client_id will be unique. If we assume that the listing of a given component_manager on the manifest of a link is accurate regardless of which AM reports that, then we can construct a set of IDs for links that all uniquely identify the link - the combination of client_id and component_manager.

Then, if a link on man2 shares one of these IDs with the link in man1, then we are talking about the same link. From there, do all the current logic of combineLink to do swaps or merging of missing elements.

See around line 554 in src/gcf/omnilib/stitch/ManifestRSpecCombiner.py

However, see also the construction of template_link_cids around line 398, and it's use around line 431. The mere presence of the same client_id is not enough any more. It must be the same clientID-AM pair. That is

   If cid is in template
      if no combo-id from this manifest is in the template, and no combo-id from that link in the template is in this manifest, then this link from this manifest is new and must be added
  else if this cid is not in the template, then add it

[ahelsing]

Test this with a link between an IG and an EG AM.

[ahelsing]

My note to Jon said:

assume that if 2 AMs report a link with the same client_id, and 1 of the 2 says the other AM is on that link, then they are talking about the same link.  That is, the client_id + component_manager pair uniquely identifies a link, and a link therefore can have multiple IDs (1 per AM on that link). If any one of the IDs match between 2 manifests, then it is the same link.

If the 1st manifest has a sliver_id on the link, then assume that the set of component_managers and interfaces listed on that link is a minimum set. Only add new interfaces / component_managers to the link.
So if:
Man1 Link "mylink" says that there is an interface named "iref1" and component_manager "AM-A", then we can assume that is true. We have a link with ID mylink-AM-A.

So if Man2 lists a link also named "mylink" that includes "iref1" and "AM-A", then this is the same link - it also has the ID mylink-AM-A. So if Man2-mylink also lists "iref2" and "AM-B", then add those to your definition of "mylink". This same link also has ID mylink-AM-B.

If Man3 lists a link named "mylink" that includes "iref3" and "AM-C" and "iref4" and "AM-D", but none of "AM-A" or "AM-B" or "iref1" or "iref2", then this is really a distinct link. The IDs on this link are mylink-AM-B and mylink-AM-C which do not overlap with our other IDs.

I haven't specified what to do if there is partial overlap. (Man3 lists "iref1" but not "AM-A", or lists "iref1" and "AM-A" but not "iref2" or "AM-B".). I suspect we should treat partial overlap like complete overlap. This assumes that if 2 AMs talk about the same link ID and agree partially on who is involved, then the link must be up and must really be the same link. If Man4 lists "mylink" and AM-E and iref4 and AM-A but not iref1, then I think we assume this is the same link; not guaranteed, but likely.