Details
Minor Description
It would be useful to have tunable parameters on the MGS to enable/disable new filesystem registrations, as well as new MDT and OST registrations to an existing filesystem, so that it isn't possible to accidentally add new targets into an existing filesystem.
There should be a top-level parameter, like mgs.allow_register, that controls whether a new filesystem can be registered. There should be a per-filesystem parameter, maybe mgs.FSNAME.allow_register (or part of mgs.MGS.live.{{FSNAME?) that controls whether a new MDT or OST target can register with the filesystem.
The allow_register parameters should have a few different states:
- disable all new registrations, which is the most secure, but may be inconvenient for some sites/users if they are not aware of this
- configurable time-limited window for registrations (e.g. 1h) sufficient for configuring a new filesystem, but then reverting automatically to the "disable all new registrations" mode.
- allow all new registrations, which would be equivalent to the current behavior. This may just be a long window (e.g. 2^30s) to simplify the state management.
This would be similar to the WiFi Protected Setup (WPS) button on a WiFi router, to allow new connections for a short window, while keeping the system in a "default secure" mode most of the time.
It seems reasonable to have the top-level default for be "1h since MGS was formatted/writeconf", and the filesystem default be something like "1h since the filesystem configuration was added on the MGS". This should be enough time to add all of the new MDTs/OSTs to a filesystem, to avoid causing issues for admins that are not aware of this parameter.
If the registration window has expired and a new target attempts to join a configuration, then the MGS should print a very clear message on the console for what parameter needs to be set in order to register a new filesystem or target.
For Lustre configuration tools, they could set allow_register with a short window for the occasions a new OSTs/MDTs is added, and then (optionally) manually disable it again after the configuration change was completed if the window had not expired. This would be more robust than enabling allow_register permanently and then disabling it afterward, in case the tool itself had a failure in the middle and was unable to disable it.
For new MDT/OST registrations, one addition to a time-based window setting, which acts as a "timeout", could be that an enabled allow_register is automatically disabled as soon as a client mounts the file system. This could allow a longer time-limited window since it guarantees that the setting is not accidentally left enabled.