qa/tasks/mgr/dashboard/test_health: add missing field for test_full_h…

[tchaikov]

…ealth

fix regression introduced by a076260

Signed-off-by: Kefu Chai kchai@redhat.com

Checklist

• References tracker ticket
• Updates documentation if necessary
• Includes tests for new functionality or reproducer for bug

---

Show available Jenkins commands

• jenkins retest this please
• jenkins test make check
• jenkins test make check arm64
• jenkins test submodules
• jenkins test dashboard
• jenkins test docs
• jenkins render docs

[tchaikov]

this should address the failure of http://pulpito.ceph.com/kchai-2019-08-12_14:45:48-rados-wip-kefu-testing-2019-08-12-1306-distro-basic-mira/4211290/

[bk201]

LGTM.
I also tested it locally. Thanks!

[epuertat]

Instead of validating data we're not using here, shouldn't we allow additive/non-breaking changes to core data structs?

[tchaikov]

@epuertat i am all for this. but i am not familiar with dashboard, could you help find a minimal set of fields we are actively using? so we can trim the unnecessary bits and then add allow_unknown=True?

[epuertat]

@tchaikov the issue here is that (some/all?) Dashboard API endpoints are returning raw data right from Ceph calls. IMHO (but that's just mine) Dashboard API should make the validation within the controller (and not only in the QA test) and just return the required subset of the whole data. But allow_unknown makes sense, as long as we're not breaking anything here.

[alfonsomthd]

@tchaikov the issue here is that (some/all?) Dashboard API endpoints are returning raw data right from Ceph calls. IMHO (but that's just mine) Dashboard API should make the validation within the controller (and not only in the QA test) and just return the required subset of the whole data. But allow_unknown makes sense, as long as we're not breaking anything here.

@ceph/dashboard I totally agree as we can find that the API tests has been fixed but the dashboard is broken,
and we (the dashboard team) have to solve this potential problem.

[tchaikov]

@epuertat i see what you mean now! yeah. as the controller is the provider of the raw output of the stats returned by the python bindings offered by mgr. it's its responsibility to validate and probably normalize those output and offer a more consistent API to the view (frontend).