Overview of the problem
For the merge appliance work, there’s some need to integrate specialized machines or black boxes (like SBCs). This has some obvious overlap with the IoT work for SPHERE.
I’ve had some discussion with Mike, and we’ve come up with a spectrum of how difficult it is for a Merge facility to manage a hardware device for use in experiments.
There are a few levels of manageability we’ve come up. If you are at one level, you typically can operate at levels beneath it.
4. Can we install an operating system?
Currently, for bare metal, we use Sled to manage the operating system.
(For virtual machines, it’s inherently part of the process.)
Without it, we will figure out a method or process of cleaning an installation (like user accounts or packages or something) without completely reimaging it.
This is the current level of control that Merge assumes for an experimenter node (specifically because of the image constraint).
3. Can we run Foundry or an equivalent?
Foundry brings user accounts, network configuration and the other material that I would describe as “get to a device from an XDC”. Whether it’s done through one of the implementations of foundry (there is currently an essentially, separate foundry implementation for tinycore) or something completely different (like ansible) is an implementation detail.
If we can SSH into the device, it’s possible to have an implementation of Foundry at the facility level that automatically SSH’s into the machine at materialization time to run scripts.
2. Does it DHCP?
If it DHCP’s, then we can control its IP address at least.
1. Can we get a shell or something similar?
The shell could be a serial console, or in the case of IoT testbed, an API to interact with the IoT device.
0. Complete black box
The only thing that Merge knows about it is that it exists on the experiment network somehow and can be theoretically accessed by nodes if everything beforehand is configured probably (like maybe it has a static IP address and you can only send and monitor network traffic to/from it.)
Currently, Merge implements experimenter nodes (whether bare metal or VMs) at level 4.
Examples
IoT testbed devices probably operate around level 2.
Arduinos: fail at step 2, as they are often lacking a network interface, with a network interface, probably level 3 cannot be fully completed.
Raspberry PI: With an ARM sled uroot implementation, probably level 4.
The implications for this is that there’s a desire to be able to model different types of nodes within XIR, both on the facility side and the experimentation side.
For merge appliance work, we’re currently aiming to implement on implementing something nice at level 0, which definitely has overlap with IoT testbed.
Questions
I’m hoping that I’m not missing anything that a facility would want to manage.
I’m also wondering from an experimenter standpoint, what sort of promises should we making to begin with.
For a Merge Appliance, it’s generally assumed that the experimenters and the facility operators are close parties – which mostly means that you can get away with a Merge black box implementation as you can actually make the facility operator/experimenter responsible for the things that Merge would otherwise do. But I’m not sure if that works well when the testbed has a larger audience.
For the very far off multisite materializations, it’s possible that you could have a user plop down a simple facility, consisting of a server and whatever BYOD they would want to plug into an experiment, and maybe modelling their BYOD as a Merge black box, to make the server requirements pretty simple (probably just a Merge provided simple service to handle simple MTZ requests, which would probably just be like canopy and an infrapod).
