Remove support of 'years' and 'months' timeunits from CRD

[btaani]

Description

This PR removes the support of y and M time units that are specified in Elasticsearch CRD (yMwdhHms).

/cc @sasagarw
/assign @periklis

Links

• JIRA: LOG-2418

[Red-GV]

/lgtm

[periklis]

This change looks not backward compatible

[Red-GV]

@periklis I don't think we ever supported years or months conversion, at least from what I can tell in the code. So it's not a compatibility issue, but a correction.

[btaani]

Yes we never supported months or years, it was just there in the CRD but whenever, for example maxAge: 1M is used, EO pod displays an error message that this time unit is not supported.

Also, should I remove this from the test file?

elasticsearch-operator/internal/indexmanagement/converters_test.go

Line 82 in d20f9cb

Context("with unsupported units", func() {

[Red-GV]

One quick question. Otherwise, looks good. I think we can keep the test case.

[Red-GV]

/lgtm

[periklis]

Yes we never supported months or years, it was just there in the CRD but whenever, for example maxAge: 1M is used, EO pod displays an error message that this time unit is not supported.

Also, should I remove this from the test file?

elasticsearch-operator/internal/indexmanagement/converters_test.go

Line 82 in d20f9cb

Context("with unsupported units", func() {

Regardless if the two units ever reconciled any jobs properly, the compatibility issue here affects the etcd store. If a user has stored an instance of the Elasticsearch CRD with these values and we remove them, we won't be able to read it back. Removing values here is like removing fields. @xperimental WDYT?

[xperimental]

If a user has stored an instance of the Elasticsearch CRD with these values and we remove them, we won't be able to read it back. Removing values here is like removing fields.

As far as I remember, the validation only happens on the write path, so the CRD should still be readable, but it should no longer be possible to write new resources or update existing ones which have values that don't match the new pattern. While it is true, that removing valid values is a breaking change and so would need a versioned changed, I feel like this does not apply to values that were never usable / resulted in an error.

[periklis]

/approve

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: btaani, periklis

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [periklis]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[btaani]

/retest

[openshift-bot]

/retest-required

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest-required

Please review the full test history for this PR and help us cut down flakes.

[openshift-bot]

/retest-required

Please review the full test history for this PR and help us cut down flakes.

[openshift-ci]

@btaani: all tests passed!

Full PR test history. Your PR dashboard.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.