Opened 12 years ago
Closed 12 years ago
#79 closed (fixed)
RSpecs: Manifest fails to preserve interface IP element
Reported by: | ahelsing@bbn.com | Owned by: | ibaldin@renci.org |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | AM | Version: | SPIRAL4 |
Keywords: | Cc: | ||
Dependencies: |
Description
The IP element on an interface of a node should be preserved from request to manifest.
It appears it is not.
See example RSpecs on ticket #78
Change History (20)
comment:1 Changed 12 years ago by
comment:2 Changed 12 years ago by
Owner: | changed from somebody to ibaldin@renci.org |
---|---|
Status: | new → assigned |
I don't understand. A node will not fail because of a particular selection of an IP address.
And I cannot preserve anything from the request. The elements are (re)created based on the RDF model.
comment:3 Changed 12 years ago by
If the user requests a specific IP, do you ignore the request? Try to honor it? If you honor it but can't complete it, then that sounds like failing the user's request. If you do honor the request, then tell the user that they got this IP address.
comment:4 Changed 12 years ago by
We honor all IP assignment requests.
Currently we never fail a request based on IP address selection.
All slices are layer 2 isolated from each other so you can use just about any IP address imaginable. If you manage to assign an IP address in such a way as to cut off your own access to the resource (ie a conflict with the management IP), that is your problem. If/when we add a feature where we check for such conflicts, there will be an appropriate error produced, but that's not part of the manifest. The manifest will just repeat what the request said.
comment:5 Changed 12 years ago by
Then that is the bug. The manifest should repeat the IP from the request, but it does not currently.
comment:10 Changed 12 years ago by
I tried to create the same sliver that was used in ticket #78, but ram into a problem usually associated with requesting resources from the wrong SM. This is not the case, I am requesting the resources from the ExoSM.
I have tried several scenarios with resources at BBN-only, at RENCI-only, and at both BBN and RENCI, each of the requests for resources at the ExoSM return the failure below.
{{{{ DEBUG:omni:Doing SSL/XMLRPC call to https://geni.renci.org:11443/orca/xmlrpc invoking CreateSliver? WARNING:omni:Failed CreateSliver? for slice test78 at https://geni.renci.org:11443/orca/xmlrpc. Error from Aggregate: code 2: Request id: null Embedding workflow ERROR: 4:No Edge Domain Exist:http://geni-orca.renci.org/owl/700f086c-8b62-44a2-9410-3d7ce84c0159#geni1:http://geni-orca.renci.org/owl/700f086c-8b62-44a2-9410-3d7ce84c0159#geni2. }}}
comment:12 Changed 12 years ago by
Yes it is. Rack is down. Resources have been undelegated so people won't use it.
comment:13 Changed 12 years ago by
I see, this error had been previously reported for wrong/invalid SM. So it seem it also covers SM down.
In one of my attemps, I did get a sliver with a request to the BBN SM, should I have been able to?
comment:14 Changed 12 years ago by
On the attempt to request resources from the unavailable SM, the createsliver had not failed, but I now see that the requested resources are "ticketed".
Now requesting resources from RENCI.
comment:15 Changed 12 years ago by
Maybe not, I get insufficient resources when requesting VMs at RENCI via both ExoSM and RENCI SM. Will try again later.
comment:19 Changed 12 years ago by
Sorry user error. The message reported "Insufficient resources or Unknown domain". I focused on the "Insufficient resources" part of the message, while the error was actually "Unknown domain".
I did Create a sliver with 2 VMs. The RSpec requesting the following address for VM1:
<ip address="172.16.1.1" netmask="255.255.0.0" />
and requesting the following address for VM2:
<ip address="172.16.1.2" netmask="255.255.0.0" />
Once the sliver was created, the sliver manifest showed the following for VM1:
<ip address="172.16.1.1" netmask="255.255.0.0" type="ipv4"/>
and the following for VM2:
<ip address="172.16.1.2" netmask="255.255.0.0" type="ipv4"/>
I believe the problem is resolved, closing ticket. Please re-open if disagree.
comment:20 Changed 12 years ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
This ticket should have been closed last September, closing now.
I should have added - don't just preserve that IP element. Also honor it -- or fail the request with an appropriate error message.