Experimenters should be allowed to change the dataplane IP address

[lnevers@bbn.com]

If the dataplane address is modified, it then restored to original setting by some process on the nodes. Experimenters should be allowed to change the IP addresses for the dataplane interface on the nodes that are allocated to their sliver.

[ahelsing@bbn.com]

killing the neuca process as a workaround is ugly

[ibaldin@renci.org]

If this is a documented requirement, please point me to it. If it isn't I would rather offer a procedure on how to deal with it as a workaround.

[nriga@bbn.com]

I would argue that this falls under requirement G2: ​http://groups.geni.net/geni/wiki/GeniRacks#G.ExperimenterRequirements

But apart from that, changing the IP address is something that comes up quite frequently; especially in tutorials and classes.

The current workaround is to stop the neuca service, which when the neuca service starts doing something we care about then this workaround will be void. If there is no plan for neuca to ever do anything useful to the experimenter then maybe we can stop it after the node is setup as part of the usual reservation process.

[ibaldin@renci.org]

The issue is that NEuca agent on the node remains active to watch for node state modifications - e.g. new network interfaces appearing or old ones going away, so it continually updates the node network state based on its information. We certainly don't want to get rid of it because it is important for this functionality.

[nriga@bbn.com]

So wouldn't the workaround of killing the neuca service if you want to permanently change the dataplane IP address of your node, interfere with this functionality? Is there a less intrusive workaround?

[ibaldin@renci.org]

Yes, which is why I'm trying to understand how often the requirement to *change* the IP address comes up. We certainly offer an easy way to *set* it initially

As to how to modify it, it will likely be supported via 'Modify' call - that way the manifest will know about it, which means any tools consuming the manifest will know it too. If the user goes and manually overwrites it, it will not be reflected in the manifest and will break such tools.

[nriga@bbn.com]

I am not sure how many people use this feature since we wouldn't necessarily know about it. If that helps currently there are 4 tutorials from GPO that use this functionality and thus can't be directly run on EG.

I am mostly afraid that people come with the expectation to be able to mock with these things and would be surprised when they can't, and using the AM API for such a change seems very cumbersome and un-natural. Are there other things that this script might reset for the user?

[ibaldin@renci.org]

Since this facility is used as a bridge between AM API and experiment request on one side and the configuration/manifest of the experiment on the other side, the amount of state that is kept in sync will likely expand with time.