[C 6.2] Time scheduling resources (same vlan) fail

[juztas]

See comment here: https://github.com/esnet/StackV/issues/1141#issuecomment-2149994151

Looks like once second is added - it does either clean first/or second ports and switching subnet info.

[juztas]

So the problem is the following (not a quick fix):

1. Request (1) for A to B submitted to start at +15m, finish +15m; lets say vlan 3600;
2. SiteRM keeps track of all unique URIs for switchPorts and serverPorts (as they need to be unique)
3. Agent's and Switch retrieval will use those URIs, once reporting information back inside the model. So any vlan on a specific switch/port or server and vlan3600 interface (ip, mac, etc) will use that unique URI.
4. Request (2) for A to B submitted to start at +60m, finish +15m; lets say same vlan 3600; In terms of timing - they do not overlap and can run.
5. Once Request (2) is accepted/added into the model - SiteRM parser get's confused and flip-flop things around. So it get's uniq uri for dellos9_s0/hundredGigE_1-32 to be urn:ogf:network:ultralight-dev.org:2013:dellos9_s0:hundredGigE_1-32:conn+3db5332f-62a1-4e15-8fbe-94eb4dfdcf07:vt+l2-policy-Connection_1:vlanport+3630 from Request (1), but continue parsing, it also get's urn:ogf:network:ultralight-dev.org:2013:dellos9_s0:hundredGigE_1-32:conn+3db5332f-62a1-4e15-8fbe-94eb4dfdcf07:vt+l2-policy-Connection_1:vlanport+3630.

[juztas]

#547

[juztas]

2 tests ongoing right now. One already started and it did not remove another delta information. Now it will use timing to identify which URIs are active; Looks to be working perfectly

[xi-yang]

One problem remains. Both instances got READY as scheduled. When the first schedule is activated, the second switchingSubnet lost its two VLAN sub interfaces. This resulted in manifest and viz rendering problem.

The first:

The second:

[juztas]

This was tested under 'test' release, deployed only on the ultralight-dev instance. I am working on a few small fixes which I expect to be done in the next hour.

Moving forward, see #557, I will have a separate instance (total 3) just for a development release. (that is for the next development cycle)

I will let you know once this fix is deployed on SoCal.

[xi-yang]

This was tested under 'test' release, deployed only on the ultralight-dev instance. I am working on a few small fixes which I expect to be done in the next hour.

Moving forward, see #557, I will have a separate instance (total 3) just for a development release. (that is for the next development cycle)

I will let you know once this fix is deployed on SoCal.

Sounds good. Let's keep this issue open. I will check it off from the StackV issue.

[juztas]

New tests succeeded: 180b719a-18a2-4b9f-993c-3b6d72a703cb and 7b412894-da37-4927-9125-9df44823ca02.

Closing. Lets reopen if this happens again