Right now we have a baked-in assumption that config option names for
manager modules are "mgr/$modulename/$optionname". This works well enough
for some modules that are clearly optional and map 1:1 to the type
of functionality they provide. For example, the prometheus module
options are "mgr/prometheus/foo" and so on.
In other cases, this is somewhat awkward. For example, we have built-in
modules like 'devicehealth' (that could perhaps be renamed to device?)
that are "always on" and currently handle scraping of metrics from
devices. There are several options here:
'enable_monitoring': True,
'scrape_frequency': str(86400),
'retention_period': str(86400*14),
'pool_name': 'device_health_metrics',
which translate to options like "mgr/devicehealth/enablemonitoring". That
is not too bad, although it bugs me that the "mgr/devicehealth" is there
and fixed but this is really "built-in" functionality (that just happens
to be implemented by the mgr daemon).
Things get weirder with the diskprediction module that prophetstor is
contributing. This module does life expectancy prediction based on health
metrics either via a built-in model/predictor, or via an external
saas service. One of my goals with this is to make the user experience
well-integrated, so it adds commands like
device get-predicted-status <dev_id> Get physical device predicted result
device predict-life-expectancy <dev_id> Predict life expectancy with local
predictor
device set-cloud-prediction-config Configure Disk Prediction service
<server> <user> <password> <certfile>
{<port>}
device set-prediction-mode <mode> config disk prediction mode ["cloud"|"
local"]
device show-prediction-config Prints diskprediction configuration
There are commands here to set most of the relevant configuration options
and a separate command to view them (show-prediction-config), but these
translate to options that also appear when you do 'ceph config dump' or
'ceph config get mgr.x', but as
"mgr/diskprediction/diskprediction_config_mode" (which could be a bit less
redundant, but still includes the mgr/module/ prefix). For someone
looking at the 'ceph config ...' output, these options strike me as
weirdly named and confusing.
We could make this a bit less weird by being careful about how the modules
are named. For example, currently the diskpredition module includes both
the saas mode code and the local predictor. We could separate the local
predictor into a 'localpredictor' module so that any options are
'mgr/localpredictor/foo' and the saas mode code options are
'mgr/saasprediction/bar' (or whatever). Usually this will work out well
enough (e.g., the 'rook' orchestrator module is called 'rook' so the
options will be 'mgr/rook/something').
There is an implementation detail that a module foo can't read or write an
option defined by another module, so for example multiple modules
(localpredictor, saaspredition) couldn't both consume an option
controlling which module implements a feature (say,
mgr/devicehealth/prediction_mode). (I expect this issue already makes the
'mgr/orchestrator_cli/orchestrator' option a bit awkward?)
Alternatively, we could allow arbitrary option names. All of our options
are already kind of weird in that they tend to have mon_ or osd_ or mds_
prefixes but don't necessarily only apply to that daemon (and we can map
them to different daemon types and specific daemons). The 'mgr/' prefix
adds a new variation of weird to it in that it has a / instead of _. We
could instead make the mgr modules allow us to define arbitrary new option
names (without constraints).
Thoughts?
sage
