On Wed, Feb 28, 2018 at 12:26:15PM +0000, John Spray wrote:
Inevitably, we're starting to hit cases where we have to think about
compatibility when making changes to the prometheus output (same
issues will apply to changes to perf counters that are passed
through):
https://github.com/ceph/ceph/pull/20506#issuecomment-368806208
For the moment, we don't have any policy around this, so I anticipate
things changing at will until the point that we make a policy, which
might naturally coincide with introducing the in-tree grafana
dashboards (because at that point the prometheus output will be
demonstrably reasonably complete).
Thinking about what kind of policy we want, the extremes would be:
- Do nothing: all counters can change at will (even though most of the
time they won't)
- Match Ceph protocol interop: all changes would be backwards
compatible through two versions
We will soon have some official grafana dashboards in the Ceph tree,
which I anticipate most people using, but there will certainly be
people who craft their own dashboards too. I'm hoping that the
vendors shipping Ceph-based products will all be working with the
in-tree dashboards, so this is probably more a topic of concern to
large scale users.
I think it's reasonable for people with custom dashboards to expect
that we not knowingly break them with updates to our stable branches:
that's a pretty easy thing for us to accomplish.
No question about this.
The part that's probably more debatable is: should someone with an
external dashboard built for luminous expect it to work seamlessly on
mimic? I would say probably not. Because we make major internal
changes between major releases, it's expected that various performance
counters would go away or change in meaningful ways.
Any thoughts?
I think non-breaking changes within a stable branch and possibly-breaking
changes from one stables release to another is a decent policy. We can probably
add a section to the release notes that lists breaking changes and maybe even
hints as to what which queries can replace non-functioning ones. This should be
straight forward in most cases, since we would usually change metrics to add
functionality, not remove it..
John
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jan Fajerski
Engineer Enterprise Storage
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton,
HRB 21284 (AG Nürnberg)
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
