dt/license_enforcement: delay disabling trial license #24426
Conversation
Previously the test relied on the fact that the previous major version (v24.2) did not do strict license enforcement. We can no longer rely on that since the head version became v25.1 and the previous major version v24.3 which does do strict license enforcement.
pgellert
requested review from
aanthony-rp and
michael-redpanda
and removed request for
a team
|
ducktape was retried in https://buildkite.com/redpanda/redpanda/builds/59217#019391a9-718e-42f3-91a8-cebe578ca4da |
| @@ -49,9 +49,6 @@ def setUp(self): | |||
| ) | |||
There was a problem hiding this comment.
Previously the test relied on the fact that the previous major version
(v24.2) did not do strict license enforcement.
We can no longer rely on that since the head version became v25.1 and the
previous major version v24.3 which does do strict license enforcement.
Does this allude to a future problem with real clusters and upgrading? If so, "delay" doesn't sound like a robust solution. Is this a test only issue?
There was a problem hiding this comment.
Is this a test only issue?
Yes.
Does this allude to a future problem with real clusters and upgrading?
I don't think so. Do you?
The underlying logic of upgrading from v24.2.x -> v24.3.x is the same (wrt. upgrade blocking) as upgrading from v24.3.x -> v25.1.x. And the test assertions are the same as well. The test needed changing because it needs some initialization (setting up a starting cluster that has an enterprise feature enabled and has an invalid license state). This test initialization logic is what needed changing now that the previous_version moved from v24.2.x to v24.3.x.
Previously the test relied on the fact that the previous major version (v24.2) did not do strict license enforcement.
We can no longer rely on that since the head version became v25.1 and the previous major version v24.3 which does do strict license enforcement.
This fixes the current CI failures on dev.
Backports Required
Release Notes