Opened 11 years ago

Last modified 11 years ago

#167 new

Experimenters should be allowed to change the dataplane IP address

Reported by: lnevers@bbn.com Owned by: somebody
Priority: minor Milestone:
Component: Experiment Version: SPIRAL5
Keywords: Cc:
Dependencies:

Description

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.

Change History (9)

comment:1 Changed 11 years ago by ahelsing@bbn.com

killing the neuca process as a workaround is ugly

comment:2 Changed 11 years ago by 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.

comment:3 Changed 11 years ago by ahelsing@bbn.com

Priority: majorminor

comment:4 Changed 11 years ago by 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.

comment:5 Changed 11 years ago by 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.

comment:6 Changed 11 years ago by 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?

comment:7 Changed 11 years ago by 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.

comment:8 Changed 11 years ago by 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?

comment:9 Changed 11 years ago by 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.

Note: See TracTickets for help on using tickets.