As Erwan mentioned, the ceph-ansible project faced some similar challenges.
Daemons like rgw and rbd-mirror are impossible to predict in
servicemap since they show up with randomly generated ID (cctid IIRC),
also this will change at every daemon restart since the rados context
gets re-initialized.
The main problem is that the data structure uses 'value' as 'key' in
the output which makes the structure impossible to predict/read
correctly.
It'll be nice to improve the returned structure so any tool can easily
consume it, soon Rook will face a similar challenge too.
Thanks!
On Fri, Nov 9, 2018 at 10:46 AM Erwan Velu <evelu@xxxxxxxxxx> wrote:
>
> Noah,
>
> Thanks for you reply.
>
> [...]
>
> > Erwan, I realize that's a lot of brain dump there. I think this is a
> > really important topic as Ceph is integrated into more and more places
> > that need machine readable output!
> >
> I totally agree that an important topic to handle. Ceph is expecting 3rd
> party tools like smartmontools to have a nice json output, we should
> apply this to ourselves too ;)
>
> - I was wondering if you generated this schema manually or if you
> created a tool to make it ?
>
> - I also noticed that some structures I see on the cli side are feed on
> the fly and depending on the state of the cluster, so items pop in/out.
> Does your approach cover that ? Are we sure we don't forgot any
> field/value ?
>
> - There is already some implementation which are almost impossible to
> map to a data structure.
>
> Services struct {
> RbdMirror struct {
> Daemons struct {
> Num4467 struct {
>
> That Num4467 structure is random while it should be an array of a known
> type.
>
> There is also examples where the key is a hostname.
>
> Rgw struct {
> Daemons struct {
> Summary string `json:"summary"`
> CephRgw0 struct {
>
> Some tooling like ceph-nano or ceph-ansible workaround this, but I'm
> also facing this.
>
> It would be nice if we can avoid this by having only pre-defined data
> structures. I'm pretty sure if your PR goes on this item you will face a
> show stopper with it as we can't validate this as a schema.
>
> Changing this will break the output and any users. But I do think we'll
> have to make it at some point for the sanity of the output.
>
>
--
Thanks!
––––––
Sébastien Han
Principal Software Engineer, Storage Architect
"Always give 100%. Unless you're giving blood."
Mail: seb@xxxxxxxxxx
Address: 11 bis, rue Roquépine - 75008 Paris
