The Full Moon
OK... Clearly we need to be able to just let people allocate an entire chassis. The requests are starting to come in fast and furious (must be recent trends in datacenter network research). This has been on my plate, and I've been putting it off. So, I have some questions:
- Do we try and represent a chassis as a sort of "mega node" that has all of its connected nodes as subnodes?
I imagine we can't do this in general since the subnode relationship implies you must allocate the parent in order to get any/all of the subnodes. However, maybe we can represent it this way via the mapper using flags when a user asks for the specific type. This is starting to feel kind of like an exotic hack though. Is there some looser form of relationship that exists or that we can "easily" create?
- Representation in the Portal
Mega node or not, we probably need to represent the chassis as some sort of node in the topology that users see and interact with via the Portal interface. At the least, they need a console link they can get to. What we do now with these time-limited console tokens/links is kind of bogus.
- Backup/restore of the switch config
Could be in for some fun here. I don't know if we can prevent users from making config changes that effectively don't lock us out, requiring going through a recovery routine at boot. We can probably just manage this via a social approach where we make clear changes the user must not make lest we deny them future access.
- Audit/reduction of potential impact
I worry slightly that there may be some side effect users might have on bighp1 through exotic port(channel) configuration of the uplink. So far this has not been a problem. Again, maybe best dealt with at the policy level.
- Access to this feature
I think we should vet users of full chassis, at least the first time they request such a resource. That way we can ensure they are doing something that requires the resource commitment, and also do some directed instruction about appropriate use (e.g., assuming we can't prevent them from locking us out). This could be done with existing type access controls, though maybe with a way to add an extra bit of info indicating that the user needs to request access via support@cloudlab.us (or some such).
- Vlan setup via bighp1
Sometimes users have wanted to tie together the two switches in the chassis with a vlan (perhaps OF-enabled and/or stitched). snmpit can setup such things, but I don't think we have good representations to specify and automatically allocate these vlans in the context of full chassis allocation. Needs some thought.
- Bits and pieces
There are little bits and pieces of other state that have to be altered as well, such as having snmpit ignore switches in fully-allocated chassis. Have to think of what else.