Closed xi-yang closed 10 months ago
(From https://github.com/esnet/sense-rm/issues/14#issuecomment-1636295188)
jmacauley here are the example TTLs you wanted. I stood up a fresh stub ONSA server to keep things focused and captured three snapshots:
base.txt
- Fresh domain without any connections.scheduled.txt
- An instance (1c67088b-0883-421d-bf98-9fb02213a67a
) has been created and scheduled, and is not yet activated.active.txt
- Another instance (c5a4398b-2ad0-4235-9474-09cab217d8b0
) has been created, scheduled, and is now active. At this time the previous instance has expired, and you can see the elements associated from it are no longer in the model.base.txt scheduled.txt active.txt
Let me know if you need/want any more references, or have any questions on the model code.
For SENSE-RM I whipped up some example TTLs from the new NSIDriver using a stub ONSA server, so feel free to reference the example resources and ask me any questions about the current process of generating the network status or modeling details.
Further details and code examples follow later on in the linked issue thread. They're less plug-and-play as this is a python project but the flows are quite simple so they should be easy to follow. Always happy to discuss further, so keep me posted.
Reporting implemented for network devices: https://github.com/sdn-sense/siterm/pull/315 The next step will be for agents (servers). API already in place
Auto dir creation for ansible: https://github.com/sdn-sense/ansible-templates/commit/453dae30f378df55092af65fa4d6cb1c3785de28
The same delta can have multiple requests behind it, and each apply is independent. Calculate top-level delta state fix is here: https://github.com/sdn-sense/siterm/pull/317/files
Network status pull request from agents is here: https://github.com/sdn-sense/siterm/pull/320
The service instance will constantly run into UNSTABLE status now. We may have some timing issue here.
My theory is that when the first audit hits, the RM hasn't finished collecting / adjusting the activation status. Then the instance becomes unstable. The next auditing is disabled because of the unstable status, so the service instance will stay unstable, until we manually check those boxes on the Auditor UI add-on page.
@R-Jimenez Maybe we can quantify the timing here. Also check if some unwanted transit status was caught in between.
Sorry, was holding off on a comment while I attempted to see if this was a quick patch, but will likely take some more work towards the weekend.
If you're seeing this with scheduled services (which is the point of the issue), then that's actually expected given the code. Nothing is technically broken, just incomplete; since the site-RM is still using the SENSE-RM driver, we aren't actually capturing any lifetime data for orchestrator scheduling metadata. This means that now that we're scheduling SENSE-RM instances there are lead-periods where the service isn't active, but without scheduling data the orchestrator falls back and assumes immediate start, end in a year or when drifted
as with our other legacy services.
Given the relative simplicity of the SENSE-RM driver, I can tackle adding the lifetime parsing and schedule construction with a pretty quick turn-around I'd assume, and should have this set by tomorrow evening.
@R-Jimenez, is there anything you identified as an issue or missing feature from SiteRM?
It all looks great, nothing functional struck out at me. I ran a limited suite of scheduling orchestration tests using the Site-RM and was able to pass, but then I got pulled away by this Modify sprint. I'll redo the suite and then some this evening with the latest code and see if there's any other blockers I can find.
I imagine at this point the only adjustments you'll have to make would be modeling consistency, which is something Xi would speak too during his testing (though again, likely at a later date after he settles the Modify/RUCIO work).
That sounds great. Keep me posted.
@R-Jimenez Have we verified all the scheduling scenarios? Or we need to wait for the metadata patch to the SENSE-O RMDriver?
Also as we discussed yesterday, it is fine if we only cover the L2 model statements for now.
Metadata patch is already in and functional. The above statements are made using our basic DNC test profiles (I believe simple L2 circuits?).
Can we check off all the scenarios described here? https://github.com/esnet/SENSE-Testbed/issues/92
Am running into issues now getting ultralight instances to READY. No matter what timeframe or duration it never verifies a single element of the instance scaffold. I'm just using a barebones P2P DNC profile (that functioned before) between :sdn-dtn-1-7.ultralight.org
and sdn-dtn-2-11.ultralight.org
; perhaps I need to be establishing things differently, or perhaps something has changed externally?
@R-Jimenez, which delta uuid or something I can map it back? If you put full delta here, it would help to map it. Checking some deltas, it was this one:
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-27:vlanport+3873:service+bw>
a <http://schemas.ogf.org/mrs/2013/12/topology#BandwidthService> ;
<http://schemas.ogf.org/mrs/2013/12/topology#availableCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#granularity>
"1000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#maximumCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#priority>
"0" ;
<http://schemas.ogf.org/mrs/2013/12/topology#reservableCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#type>
"guaranteedCapped" ;
<http://schemas.ogf.org/mrs/2013/12/topology#unit>
"bps" .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1:vlanport+3873:service+bw>
a <http://schemas.ogf.org/mrs/2013/12/topology#BandwidthService> ;
<http://schemas.ogf.org/mrs/2013/12/topology#availableCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#granularity>
"1000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#maximumCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#priority>
"0" ;
<http://schemas.ogf.org/mrs/2013/12/topology#reservableCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#type>
"guaranteedCapped" ;
<http://schemas.ogf.org/mrs/2013/12/topology#unit>
"bps" .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-23:vlanport+3873:label+3873>
a <http://schemas.ogf.org/nml/2013/03/base#Label> ;
<http://schemas.ogf.org/nml/2013/03/base#labeltype>
<http://schemas.ogf.org/nml/2012/10/ethernet#vlan> ;
<http://schemas.ogf.org/nml/2013/03/base#value>
"3873" .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-27:vlanport+3873:label+3873>
a <http://schemas.ogf.org/nml/2013/03/base#Label> ;
<http://schemas.ogf.org/nml/2013/03/base#labeltype>
<http://schemas.ogf.org/nml/2012/10/ethernet#vlan> ;
<http://schemas.ogf.org/nml/2013/03/base#value>
"3873" .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-23>
<http://schemas.ogf.org/nml/2013/03/base#hasBidirectionalPort>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-23:vlanport+3873> .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1:vlanport+3873:service+bw>
a <http://schemas.ogf.org/mrs/2013/12/topology#BandwidthService> ;
<http://schemas.ogf.org/mrs/2013/12/topology#availableCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#granularity>
"1000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#maximumCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#priority>
"0" ;
<http://schemas.ogf.org/mrs/2013/12/topology#reservableCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#type>
"guaranteedCapped" ;
<http://schemas.ogf.org/mrs/2013/12/topology#unit>
"bps" .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-23:vlanport+3873:service+bw>
a <http://schemas.ogf.org/mrs/2013/12/topology#BandwidthService> ;
<http://schemas.ogf.org/mrs/2013/12/topology#availableCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#granularity>
"1000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#maximumCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#priority>
"0" ;
<http://schemas.ogf.org/mrs/2013/12/topology#reservableCapacity>
"1000000000"^^xsd:long ;
<http://schemas.ogf.org/mrs/2013/12/topology#type>
"guaranteedCapped" ;
<http://schemas.ogf.org/mrs/2013/12/topology#unit>
"bps" .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1>
<http://schemas.ogf.org/nml/2013/03/base#hasBidirectionalPort>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1:vlanport+3873> .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:service+vsw>
<http://schemas.ogf.org/mrs/2013/12/topology#providesSubnet>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:service+vsw:conn+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+l2-policy-Connection_1:vlan+3873> .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1:vlanport+3873:label+3873>
a <http://schemas.ogf.org/nml/2013/03/base#Label> ;
<http://schemas.ogf.org/nml/2013/03/base#labeltype>
<http://schemas.ogf.org/nml/2012/10/ethernet#vlan> ;
<http://schemas.ogf.org/nml/2013/03/base#value>
"3873" .
<http://schemas.ogf.org/mrs/2013/12/topology#SwitchingSubnet>
a owl:Class , rdfs:Class , rdfs:Resource ;
rdfs:subClassOf <http://schemas.ogf.org/mrs/2013/12/topology#SwitchingSubnet> , rdfs:Resource ;
owl:equivalentClass <http://schemas.ogf.org/mrs/2013/12/topology#SwitchingSubnet> .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1>
<http://schemas.ogf.org/nml/2013/03/base#hasBidirectionalPort>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1:vlanport+3873> .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-27>
<http://schemas.ogf.org/nml/2013/03/base#hasBidirectionalPort>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-27:vlanport+3873> .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1:vlanport+3873:ipv4-address+172.18.3.2>
a <http://schemas.ogf.org/mrs/2013/12/topology#NetworkAddress> ;
<http://schemas.ogf.org/mrs/2013/12/topology#tag>
"urn:ogf:network:service+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+ip-policy::Connection_1" ;
<http://schemas.ogf.org/mrs/2013/12/topology#type>
"unverifiable" , "ipv4-address" ;
<http://schemas.ogf.org/mrs/2013/12/topology#value>
"172.18.3.2/30" .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-23:vlanport+3873>
a <http://schemas.ogf.org/nml/2013/03/base#BidirectionalPort> ;
<http://schemas.ogf.org/mrs/2013/12/topology#tag>
"urn:ogf:network:service+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+l2-policy::Connection_1" ;
<http://schemas.ogf.org/nml/2013/03/base#belongsTo>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:service+vsw:conn+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+l2-policy-Connection_1:vlan+3873> ;
<http://schemas.ogf.org/nml/2013/03/base#hasLabel>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-23:vlanport+3873:label+3873> ;
<http://schemas.ogf.org/nml/2013/03/base#hasService>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-23:vlanport+3873:service+bw> ;
<http://schemas.ogf.org/nml/2013/03/base#isAlias>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1:vlanport+3873> .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1:vlanport+3873:ipv4-address+172.18.3.3>
a <http://schemas.ogf.org/mrs/2013/12/topology#NetworkAddress> ;
<http://schemas.ogf.org/mrs/2013/12/topology#tag>
"urn:ogf:network:service+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+ip-policy::Connection_1" ;
<http://schemas.ogf.org/mrs/2013/12/topology#type>
"unverifiable" , "ipv4-address" ;
<http://schemas.ogf.org/mrs/2013/12/topology#value>
"172.18.3.3/30" .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1:vlanport+3873>
a <http://schemas.ogf.org/nml/2013/03/base#BidirectionalPort> ;
<http://schemas.ogf.org/mrs/2013/12/topology#hasNetworkAddress>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1:vlanport+3873:ipv4-address+172.18.3.2> ;
<http://schemas.ogf.org/mrs/2013/12/topology#tag>
"urn:ogf:network:service+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+l2-policy::Connection_1" ;
<http://schemas.ogf.org/nml/2013/03/base#hasLabel>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1:vlanport+3873:label+3873> ;
<http://schemas.ogf.org/nml/2013/03/base#hasService>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1:vlanport+3873:service+bw> ;
<http://schemas.ogf.org/nml/2013/03/base#isAlias>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-23:vlanport+3873> .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-1-7.ultralight.org:mlx4p1s1:vlanport+3873:label+3873>
a <http://schemas.ogf.org/nml/2013/03/base#Label> ;
<http://schemas.ogf.org/nml/2013/03/base#labeltype>
<http://schemas.ogf.org/nml/2012/10/ethernet#vlan> ;
<http://schemas.ogf.org/nml/2013/03/base#value>
"3873" .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-27:vlanport+3873>
a <http://schemas.ogf.org/nml/2013/03/base#BidirectionalPort> ;
<http://schemas.ogf.org/mrs/2013/12/topology#tag>
"urn:ogf:network:service+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+l2-policy::Connection_1" ;
<http://schemas.ogf.org/nml/2013/03/base#belongsTo>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:service+vsw:conn+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+l2-policy-Connection_1:vlan+3873> ;
<http://schemas.ogf.org/nml/2013/03/base#hasLabel>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-27:vlanport+3873:label+3873> ;
<http://schemas.ogf.org/nml/2013/03/base#hasService>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-27:vlanport+3873:service+bw> ;
<http://schemas.ogf.org/nml/2013/03/base#isAlias>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1:vlanport+3873> .
<urn:ogf:network:ultralight.org:2013:dellos9_s0:service+vsw:conn+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+l2-policy-Connection_1:vlan+3873>
a <http://schemas.ogf.org/mrs/2013/12/topology#SwitchingSubnet> ;
<http://schemas.ogf.org/mrs/2013/12/topology#tag>
"urn:ogf:network:service+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+l2-policy::Connection_1" ;
<http://schemas.ogf.org/nml/2013/03/base#belongsTo>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:service+vsw> ;
<http://schemas.ogf.org/nml/2013/03/base#encoding>
<http://schemas.ogf.org/nml/2012/10/ethernet#vlan> ;
<http://schemas.ogf.org/nml/2013/03/base#hasBidirectionalPort>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-23:vlanport+3873> , <urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-27:vlanport+3873> ;
<http://schemas.ogf.org/nml/2013/03/base#labelSwapping>
"false" .
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1:vlanport+3873>
a <http://schemas.ogf.org/nml/2013/03/base#BidirectionalPort> ;
<http://schemas.ogf.org/mrs/2013/12/topology#hasNetworkAddress>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1:vlanport+3873:ipv4-address+172.18.3.3> ;
<http://schemas.ogf.org/mrs/2013/12/topology#tag>
"urn:ogf:network:service+4700d4e0-bb7d-4a30-9736-91fa5f2f1852:vt+l2-policy::Connection_1" ;
<http://schemas.ogf.org/nml/2013/03/base#hasLabel>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1:vlanport+3873:label+3873> ;
<http://schemas.ogf.org/nml/2013/03/base#hasService>
<urn:ogf:network:ultralight.org:2013:sdn-dtn-2-11.ultralight.org:mlx5p1s1:vlanport+3873:service+bw> ;
<http://schemas.ogf.org/nml/2013/03/base#isAlias>
<urn:ogf:network:ultralight.org:2013:dellos9_s0:hundredGigE_1-27:vlanport+3873> .
There is no lifetime in it
For layer-3 resources, we current get activate-error. If that is not correct and we want to hold off modeling the activation status for Layer-3, we can just not generate the mrs:NetworkStatus for such resources and keep it only to the L2.
That is kind of the correct state, see below:
urn:ogf:network:ultralight.org:2013:dellos9_s0:service+vsw:conn+e0a61788-0496-4ddd-bee6-2aa41f667120:vt+l2-policy-Connection_1:vlan+3612
"hasNetworkAddress": {
"ipv6-address": {
"type": "ipv6-address",
"value": "fc00:3614:0:0:0:0:0:9977/64"
}
and
"urn:ogf:network:ultralight.org:2013:dellos9_s0:service+vsw:conn+3758edb2-125e-4425-abf1-32ec3f520bfd:vt+l2-policy-Connection_1:vlan+3988":
"hasNetworkAddress": {
"ipv6-address": {
"type": "unverifiable|ipv6-address",
"value": "fc00:3614:0:0:0:0:1:c693/64"
}
So, these 2 IP Ranges overlap. I think there are several issues here:
Ok. The activate-error makes sense. Also below ...
So, these 2 IP Ranges overlap. I think there are several issues here:
- Siterm failed to identify that this IP range is in use.
The first line of defense is propagate check. Propagate should fail if the IP is not applicable.
- Siterm should exclude from available list of IPs/IPv6s if it is in use. Same for Vlans (That was never done yet and it was always reporting same.
Tracking all IP use will be too much for the Site RM. This is unlike VLAN. Eventually (in a few weeks), we should be able to this with the SENSE-O central address management. The RM IP pool in model should stay relatively static. The RM only needs to check the contention during propagate time.
The remaining issues have individual tickets, I am closing this ticket for now. https://github.com/sdn-sense/siterm/issues/362 https://github.com/sdn-sense/siterm/issues/354
This will be similar to Items 3 and 4 for the SENSE-O NSIDriver feature https://github.com/esnet/StackV/issues/1150.
Referene code: https://github.com/esnet/StackV/blob/main/StackV-ejb/src/main/java/net/maxgigapop/mrs/driver/nsi/NSIService.java#L207