Decide on configuration (and hash) structure

[julianstirling]

To uniquely identify each Nimble Configuration we need to have some sort of unique "hash" for that configuration.

We first need to understand exactly what the possible configurations are. The way we currently pass the components into the orchestration is a list of the devices in the order they go into the rack.

I think we will also want a way to add rack options. Options like the screw sizes, or the total rack height to match the peli-case/container being used (we can pad out the excess with stuff shelves, or blanking plates).

I think our inputs are then:

{
    "devices": [
        "device_id1",
        "device_id2",
        "..."
    ],
    "parameters": {
        "parameter1": "value1",
        "parameter2": "value2"
    }
}

Are there other things we will need?

Hashing strategy

We can just add these as a string (with parameters sorted as @jmwright has in example code) or we can pass them into a hashing function. My gut feeling is to lass it into a hashing function to keep the names shorter, but it may also obscure them.

Implementation

I think that the hashing should be a property method of the NimbleConfiguration class. The way I see it working is that the server or any other generation script can generate a configuration object as:

from nimble_orchestration.configuration import NimbleConfiguration
config = NimbleConfiguration(['NUC10i5FNH', 'Raspberry_Pi_4B'], parameters={"rack_height":21})
hash = config.hash

From here the server/script can check the build directory if a zip is available with a matching hash. If not it can use OrchestrationRunner to create everything that is needed and zip it up.

[jmwright]

I think this is probably baked-in to the hashing methods you have mentioned, but it would be good to preserve the relationship between a configuration and a hash. That way we can do a naive sort of caching where if a configuration has already been generated and the server has not been rebooted (wiping out the temp files), we just send that zip to the user rather than burning the compute time to regenerate it.

My memory is that the rack height is calculated dynamically based on the number of shelves and the total height of those shelves combined. How will that work if you pass the rack_height as a parameter?

[julianstirling]

we just send that zip to the user rather than burning the compute time to regenerate it.

100%. Also more than that I think we need to hash or otherwise identify each shelf/rack component. As if you want a rack with 8 shelves and a height of 21. And we have already generated 7 of those shelves previously and a rack of the same size, then we should be copying over the rack components, and the 7 shelves from the cache and just generating 1 new shelf.

How will that work if you pass the rack_height as a parameter?

Not yet implemented but my thought is that there are fixed sizes of peli-cases. So if you have 3 shelves and a tiny rack it will wobble around in the peli case and get damaged. So you probably want to be able to pick your rack size.

If your shelves need a larger rack you get an error. If you rack is bigger than your number of shelves you are told to print some blanking plates to cover the excess space.

Probably if you don't choose a rack size explicitly then it will default to a custom height rack as it currently does.