OSD metadata is an interesting example, because the content is
completely unstructured -- the OSDs themselves are passing up a map of
strings to strings. Similarly, the servicemap is basically freeform.
That is very challenging for external tools then.
I found also difficult structures which are changing the name of it
instead of creating array of a given type.
Services struct {
RbdMirror struct {
Daemons struct {
Num4467 struct {
That kind of struct is impossible to unmarshall :(
I don't get how I'll manage such case ....
ceph-mgr doesn't have to worry about this, because it's part of Ceph.
If something changes in a dump() method, the consuming code in
ceph-mgr can be updated at the same time -- this is one of the key
motivations for implementing functionality inside ceph-mgr modules
instead of trying to build things externally. We rely on testing to
notice any breakage like this, but Noah's work could also make
detecting such changes cleaner.
So that's means that a ceph-mgr will never be able to manage several
versions of Ceph.
I understand the logic but that means that no tool will be able to
manage several version of Ceph when considering reading the json outputs.
In the container context, a single instance of a tool will have much
difficulty to inspect several containers from different ceph releases :(
I wonder how my generic analyzing tool will be able to handle that and
if that doesn't mean that I shouldn't try to represent the Ceph cluster
in a generic manner. :(
