RSpecs: Manifest fails to preserve interface IP element

[ahelsing@bbn.com]

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

[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.

[ibaldin@renci.org]

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.

[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.

[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.

[ahelsing@bbn.com]

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

[ibaldin@renci.org]

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

[ahelsing@bbn.com]

Ilia, do you believe this has been fixed?

[ibaldin@renci.org]

I thought that we did.

[ahelsing@bbn.com]

Great. I've asked Luisa to confirm this.

[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. }}}

[ahelsing@bbn.com]

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

[ibaldin@renci.org]

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

[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?

[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.

[lnevers@bbn.com]

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

[ibaldin@renci.org]

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

[lnevers@bbn.com]

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

[ibaldin@renci.org]

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

[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.

[lnevers@bbn.com]

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