Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qa/tasks/mgr/dashboard/test_health: update schema #30507

Merged
merged 2 commits into from Sep 23, 2019

Conversation

tchaikov
Copy link
Contributor

@tchaikov tchaikov commented Sep 22, 2019

see 351a3b9

Fixes: https://tracker.ceph.com/issues/41947
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 crimson perf
  • jenkins test signed
  • jenkins test make check
  • jenkins test make check arm64
  • jenkins test submodules
  • jenkins test dashboard
  • jenkins test dashboard backend
  • jenkins test docs
  • jenkins render docs

@tchaikov
Copy link
Contributor Author

this should address the failures of "Test failure: test_full_health (tasks.mgr.dashboard.test_health.HealthTest)" in http://pulpito.ceph.com/kchai-2019-09-22_03:04:52-rados-wip-kefu-testing-2019-09-20-1945-distro-basic-mira/

it's a property of "standby" object, not an element of
"available_modules".

it's a follow-up fix of 351a3b9

Signed-off-by: Kefu Chai <kchai@redhat.com>
@tchaikov
Copy link
Contributor Author

@alfonsomthd
Copy link
Contributor

jenkins test dashboard backend

@sebastian-philipp
Copy link
Contributor

Is there any other way of how can we guarantee API stability for (or reliably announce API changes to) the dashboard without creating this kind of pain?

@epuertat
Copy link
Member

Is there any other way of how can we guarantee API stability for (or reliably announce API changes to) the dashboard without creating this kind of pain?

Fully agree:

  • We shouldn't break any test for simple/additive changes to data structures that do not compromise any API contract. Generally speaking: we shouldn't break any test for a change that is not breaking anything at all (overzealous testing?).
    • If we still don't want additive changes to pass to Ceph-Dashboard API consumers, we should then stop behaving pass-through in Ceph-Dashboard back-end and start to strictly cherry-pick the data we want to pass from the back-end.
  • If we still decide to break tests for innocuos changes, we shouldn't wait until end-to-end tests to do so. This could be easily caught during build/CI checks.

So, can we turn on allow_unknown in the schema definition?

Copy link
Contributor

@alfonsomthd alfonsomthd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ran jenkins test dashboard backend:

2019-09-23 08:31:22,230.230 INFO:main:test_full_health (tasks.mgr.dashboard.test_health.HealthTest) ... ok

Another test failed but it is unrelated to this PR.

@tchaikov
Copy link
Contributor Author

tchaikov commented Sep 23, 2019

@tchaikov tchaikov merged commit b6dc4b0 into ceph:master Sep 23, 2019
@tchaikov tchaikov deleted the wip-mgr-features-in-mgrmap branch September 23, 2019 15:18
tchaikov added a commit to tchaikov/ceph that referenced this pull request Sep 23, 2019
tests/functionalities are not broken if we add more fields to mgr_map.

see also ceph#30507

Signed-off-by: Kefu Chai <kchai@redhat.com>
@tchaikov
Copy link
Contributor Author

@epuertat see #30517

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants