multipoint slice (unbound case and modify) about orca5 HOT 16 CLOSED

Is this related to the cienaNet issue #40 ?

from orca5.

No, a different slice. I believe the two sites picked by the controller didn't include CIENA.

from orca5.

@YufengXin can you please look at this?

from orca5.

1. for now, pls add a rule to disable this type of request: unbounded global MP.
2. It actually works except for the manifest information, I'll try to fix it.

from orca5.

The problem is that when sent to a rack controller, unbound mp request should be fine. At the level of datalog rules I have no way of distinguishing this case from the case above where a request that is too large for a single rack is sent to exo-sm and is therefore split. We can either prohibit it in the code in a different way, or just leave it to fix the manifest problem later.

from orca5.

When I bind the request to specific sites, the slice comes up fine. If I modify (remove) the single VM and add it back, the VM remains unconnected in the manifest. The slice works fine, though.

from orca5.

Probably in this case, I should not combine and split, just assign each nodegroup to a site.

Yufeng

Sent from my Verizon Wireless 4G LTE smartphone

-------- Original message --------
From: Ilya Baldin [email protected]
Date: 01/15/2016 3:21 PM (GMT-05:00)
To: RENCI-NRIG/orca5 [email protected]
Cc: Yufeng Xin [email protected]
Subject: Re: [orca5] unbound multipoint slice (#41)

The problem is that when sent to a rack controller, mp request should be fine. At the level of datalog rules I have no way of distinguishing this case from the case above where a request that is too large for a single rack is sent to exo-sm and is therefore split. We can either prohibit it in the code in a different way, or just leave it to fix the manifest problem later.

Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-172080752.

from orca5.

I think this one is less important at the moment, compared with the closed model issue. The only downside to this one right now is that it doesn’t display properly. Even if we can’t prohibit it through rules, it isn’t a huge deal.

from orca5.

Agreed, I will work on the closing issue first.
You are right, it is related to the inter rack modifying which we havenot extensively tested.

Yufeng

Sent from my Verizon Wireless 4G LTE smartphone

-------- Original message --------
From: Ilya Baldin [email protected]
Date: 01/15/2016 10:11 PM (GMT-05:00)
To: RENCI-NRIG/orca5 [email protected]
Cc: Yufeng Xin [email protected]
Subject: Re: [orca5] multipoint slice (unbound case and modify) (#41)

I think this one is less important at the moment, compared with the closed model issue. The only downside to this one right now is that it doesn't display properly. Even if we can't prohibit it through rules, it isn't a huge deal.

Reply to this email directly or view it on GitHubhttps://github.com//issues/41#issuecomment-172150178.

from orca5.

@YufengXin - is this what your latest patch was about?

from orca5.

@YufengXin is this problem what b86d7d8 (the latest commit) is supposed to fix?

from orca5.

no, the latest was about modifying the Inter-rack MP request by adding new branches to it.

from orca5.

@hinchliff is any of this addressed by the current merge?

from orca5.

This has not been fixed. Running in a test environment, Orca currently returns something like this:

2017-12-18 09:24:01,695 [main] DEBUG controller.OrcaXmlrpcHandler-(OrcaXmlrpcHandler.java:423) - createSlice(): returning result Here are the leases: 
Request id: f29e19bc-1332-4c3c-9bd6-5a948f070fa9
[   Slice UID: f29e19bc-1332-4c3c-9bd6-5a948f070fa9 | Reservation UID: 51c9b196-335d-42ac-ab1e-819377aae862 | Resource Type: ion/vlan.vlan | Resource Units: 1 ] 
[   Slice UID: f29e19bc-1332-4c3c-9bd6-5a948f070fa9 | Reservation UID: 6fbf2f1f-2c84-4f43-9426-c4f84359f65a | Resource Type: rciNet/vlan.vlan | Resource Units: 1 ] 
[   Slice UID: f29e19bc-1332-4c3c-9bd6-5a948f070fa9 | Reservation UID: f75500a7-ea97-4fc4-98d5-46e8ff137d7a | Resource Type: nlr/vlan.vlan | Resource Units: 1 ] 
[   Slice UID: f29e19bc-1332-4c3c-9bd6-5a948f070fa9 | Reservation UID: 8b7e4a0f-5205-4f6d-9b84-0e7cb52e1c07 | Resource Type: ben/vlan.vlan | Resource Units: 1 ] 
[   Slice UID: f29e19bc-1332-4c3c-9bd6-5a948f070fa9 | Reservation UID: 3cb4f1cf-641c-4175-8750-1fe1dc2acad8 | Resource Type: rcivmsite/vm.vm | Resource Units: 32 ] 
[   Slice UID: f29e19bc-1332-4c3c-9bd6-5a948f070fa9 | Reservation UID: e24641a9-2900-4a2e-8282-f460c058b161 | Resource Type: pscvmsite/vm.vm | Resource Units: 33 ] 
[   Slice UID: f29e19bc-1332-4c3c-9bd6-5a948f070fa9 | Reservation UID: fd5f36c7-d182-4b84-8e07-d7370d94e98d | Resource Type: pscNet/vlan.vlan | Resource Units: 1 ] 

from orca5.

The same exact thing happens with a single large nodegroup (64 units), connected to a broadcast link -- the large NodeGroup is split, and the resulting leases contain reservations with e.g. "Resource Units: 32". The fact that the original request was MultiPoint and joined together doesn't seem necessary to replicate this bug.

It looks to me like the problem is that the function generateVCConnection() doesn't add the necessary NodeGroup information to the ComputeElements that are created by this function.

from orca5.

I believe the Modify portion of this ticket is a known issue, where MultiPoint modify doesn't work because departure drive AM policy does not support it.

from orca5.