Custom Query (1408 matches)

By default, the SCS does not provide a path for links between ExoGENI resources.

Add new options to allow optionally getting GENI stitched paths between ExoGENI resources.

The default would be that you get no GENI stitching path for a link between 2 EG sites, but with a particular option specifying a path by name, the SCS would attempt to generate a GENI path for that connection and return an error if that is not possible. This would be passed under options -> geni_routing_profile -> path_id, where we'd add a new optional argument: attempt_path_finding: True (default False).

In addition, also support:

• A different top level option (not per path, so parallel to geni_routing_profile) that gives this behavior for all EG only links in the request. Call this new option "always_attempt_path_finding (a boolean, default False).

Again, any link in the request for which the SCS cannot find a path causes an error when this option is supplied.

ON the I2 SCS all requests that include GPO as an end-point fail with the error:

StitchingServiceFailedError: Error from Stitching Service: code 3:
MxTCE ComputeWorker return error message '
Action_ProcessRequestTopology_MP2P:
:Finish() Cannot find the set of paths for the RequestTopology. '.

The same topologies work if I use the MAX SCS.

Can the installation of the dynamic refresh of Ads be a source of this problem?

A 9 node topology that uses both AL2S and ION sites reports "Cannot find the set of paths" error even though all sites are known.

A diagram is attached for the topology along with the RSpec used.

According to Xi, the link between Illinois and Chicago (ill-chic-4) caused the failure, and the problem is a known issue which is fixed in 2.0 branch which is running in production and development SCS.

After switching to an SCS with the fix, there is still a problem with the link between Chicago and Rutgers (chic-rut-7). Xi is investigating this problem.