Add basic StatusService

[joshdover]

Summary

Related to #41983
Follows the spec outlined in RFC-0010.

This implements the basics of the StatusService + exposes the core status of the Elasticsearch and SavedObject services. These values are not currently being read by anything in the system yet, but will be in a future change.

Checklist

Delete any items that are not applicable to this PR.

• Unit or functional tests were updated or added to match the most common scenarios

For maintainers

• This was checked for breaking API changes and was labeled appropriately

[elasticmachine]

Pinging @elastic/kibana-platform (Team:Platform)

[mshustov]

That demonstrates why we should use string enum https://www.typescriptlang.org/docs/handbook/enums.html#string-enums or a union of strings.

[joshdover]

Yeah I think the sorting property that I liked from a regular integer enum can be expressed as a utility. String readability is probably more important. 👍

[joshdover]

Actually on second thought, I think we're more often concerned with comparisons than we are with the string output (which is really only needed in the API outputs).

If we move to string enums, we would probably want to include a utility like this:

export const statusComparator = {
  gt: (a: ServiceStatusLevel, b: ServiceStatusLevel): boolean => compareFn(a, b) === 1,
  gte: (a: ServiceStatusLevel, b: ServiceStatusLevel): boolean => compareFn(a, b) >= 0,
  lt: (a: ServiceStatusLevel, b: ServiceStatusLevel): boolean => compareFn(a, b) === -1,
  lte: (a: ServiceStatusLevel, b: ServiceStatusLevel): boolean => compareFn(a, b) <= -1,
  eq: (a: ServiceStatusLevel, b: ServiceStatusLevel): boolean => compareFn(a, b) === 0,
  compareFn,
};

However, I think this will be far less discoverable. Since doing comparisons like esStatus >= unavailable may be very common, I don't think this is an improvement. WDYT?

[mshustov]

However, I think this will be far less discoverable. Since doing comparisons like esStatus >= unavailable may be very common, I don't think this is an improvement. WDYT?

Optional: We can define each level as an object or a class instance with a valueOf method to make them comparable.

const available = {
  toString() {
    return 'available';
  },
  valueOf() {
    return 0;
  },
};

const degraded = {
  toString() {
    return 'degraded';
  },
  valueOf() {
    return 1;
  },
};
const levels = {
  available,
  degraded,
};

console.log(levels.available === levels.available);
console.log(levels.available > levels.degraded);
console.log(levels.available === levels.degraded);
console.log(levels.available < levels.degraded);

but the current implementation is ok for me

[pgayvallet]

const available = {
  toString() {
    return 'available';
  },
  valueOf() {
    return 0;
  },
};

Would love to have java enum class implementation in TS. that would really solves this kind of issues in a graceful way...

[joshdover]

Good idea, switched to this pattern. It doesn't work for array sorting, but I'm less concerned about that being a common use case.

[joshdover]

Updated addressing all comments. The only thing that I think needs discussion is whether we should use integer enums or a string enum.

I prefer the integer enum since it allows for easy comparison between status levels, which is very convenient. As I outlined here we could provide utilities to make this easier with string enums, however I worry that it won't be as easily discoverable.

[pgayvallet]

I'm mixed about the fact to re-emit running status in case of runMigrations({ rerun: true}). OTOH, this should only be used for FTR tests, so I guess that's alright.

[rudolf]

Happy for this to be merge if we've removed the double replay

[rudolf]

We do another distinctUntilChanged and shareReplay in setupCoreStatus so we can remove this one.

[joshdover]

Maybe the shareReplay could be removed but I think we could still produce duplicate statuses since the summary rollup may or may not be the same value.

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: 5471628

History

• 💔 Build #37319 failed 1fef04a
• 💚 Build #34762 succeeded ed6c0801fe328c20e584b6d7226005dce368f8a5
• 💔 Build #34746 failed 8d567b7234e85ec73e67684e471e28329beda2fe
• 💔 Build #33634 failed 8cc03f30dd7ee906addbb88d593270fd9044b4b7

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream