jaeger-operator icon indicating copy to clipboard operation
jaeger-operator copied to clipboard

Support rollover for archive storage

Open pavolloffay opened this issue 5 years ago • 6 comments

When --es-archive.enabled=true --es-archive.use-aliases=true are present in the storage options the rollover init (ES storage dependency) and rollover rollover (cron job) jobs should be created.

  • [ ] support rollover for archive
  • [ ] support index cleaner for archive (which works only for archive anyway)

pavolloffay avatar Jul 24 '19 08:07 pavolloffay

General question: What are the implications if the CR enables and then disables these options? (same for normal storage i.e. non-archive).

Do we need the operator to perform any additional actions when enabling rollover where ES cluster already exists - and similarly if moving from using rollover to no longer using rollover?

objectiser avatar Jul 24 '19 08:07 objectiser

General question: What are the implications if the CR enables and then disables these options? (same for normal storage i.e. non-archive).

none, rollover is enabled or disabled purely based on storage options - see my first comment.

Do we need the operator to perform any additional actions when enabling rollover where ES cluster already exists - and similarly if moving from using rollover to no longer using rollover?

migration to/from rollover/daily indices is not supported. Users would have to do that manually. Migration from rollover to daily indices might be challenging and we haven't considered it when we were working on rollover.

pavolloffay avatar Jul 24 '19 08:07 pavolloffay

@jpkrohling Is there any way the operator could prevent such upgrades? i.e. if user goes from a valid to an invalid state - prevent the invalid state being acted upon?

objectiser avatar Jul 24 '19 08:07 objectiser

We should probably have the same check when changing storage backends or strategies.

pavolloffay avatar Jul 24 '19 08:07 pavolloffay

Sort of. We cannot prevent updates to the CR, but we can revert the user's change. Inside the controller's applyElasticsearch, we could place a check and verify this specific case. If the new value is incompatible with the previous, revert the change and continue the reconciliation, so that the updated CR is persisted.

jpkrohling avatar Jul 24 '19 08:07 jpkrohling

We should probably have the same check when changing storage backends or strategies.

We support changing storage backends and strategies.

jpkrohling avatar Jul 24 '19 08:07 jpkrohling