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 ahelsing@bbn.com

I should have added - don't just preserve that IP element. Also honor it -- or fail the request with an appropriate error message.

comment:2 Changed 12 years ago by ibaldin@renci.org

Owner: changed from somebody to ibaldin@renci.org
Status: newassigned

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 ahelsing@bbn.com

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 ibaldin@renci.org

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 ahelsing@bbn.com

Then that is the bug. The manifest should repeat the IP from the request, but it does not currently.

comment:6 Changed 12 years ago by ibaldin@renci.org

As I said, that will be fixed at next redeploy.

comment:7 Changed 12 years ago by ahelsing@bbn.com

Ilia, do you believe this has been fixed?

comment:8 Changed 12 years ago by ibaldin@renci.org

I thought that we did.

comment:9 Changed 12 years ago by ahelsing@bbn.com

Great. I've asked Luisa to confirm this.

comment:10 Changed 12 years ago by lnevers@bbn.com

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:11 Changed 12 years ago by ahelsing@bbn.com

I wonder if this is because the BBN rack is down?

comment:12 Changed 12 years ago by ibaldin@renci.org

Yes it is. Rack is down. Resources have been undelegated so people won't use it.

comment:13 Changed 12 years ago by lnevers@bbn.com

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 lnevers@bbn.com

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 lnevers@bbn.com

Maybe not, I get insufficient resources when requesting VMs at RENCI via both ExoSM and RENCI SM. Will try again later.

comment:16 Changed 12 years ago by ibaldin@renci.org

Strange - I'm able to create (at least relatively small) slices.

comment:17 Changed 12 years ago by lnevers@bbn.com

I was using a shared VLAN rspec for the failed RENCI requests.

comment:18 Changed 12 years ago by ibaldin@renci.org

I'm able to create a slice (2 vms) on vlan 1750 on renci rack.

comment:19 Changed 12 years ago by lnevers@bbn.com

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 lnevers@bbn.com

Resolution: fixed
Status: assignedclosed

This ticket should have been closed last September, closing now.

Note: See TracTickets for help on using tickets.