Opened 10 years ago
Last modified 10 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 10 years ago by
comment:2 Changed 10 years ago by
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 10 years ago by
Priority: | major → minor |
---|
comment:4 Changed 10 years ago by
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 10 years ago by
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 10 years ago by
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 10 years ago by
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 10 years ago by
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 10 years ago by
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.
killing the neuca process as a workaround is ugly