You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Make Cassandra and DSE version validation a little more forgiving so we don't have to keep revisiting it every time new server versions come out.
Why is this needed?
There are Version validations for Cassandra/DSE that become a little tedious to maintain as the server versions move forward. For example, #542. It would be easier if we didn't have to revisit this when Cassandra 6 comes out or DSE 8, etc...
┆Issue is synchronized with this Jira Story by Unito
┆Issue Number: CASS-21
The text was updated successfully, but these errors were encountered:
It would be ideal to look at this more wholistically, for example, can the version be detected via management API so that the user doesn't have to supply it at all?
In general, we have ongoing problems with the CRDs where we allow specification of a given option in more than one place. This is an example of that, because the version is really set via the image field, and by supplying the version elsewhere we're just forcing the user to give the operator more hints about what version they're using, but there's no guarantee that the real version in the image matches what they're telling us, which could lead to odd behaviour.
What is missing?
Make Cassandra and DSE version validation a little more forgiving so we don't have to keep revisiting it every time new server versions come out.
Why is this needed?
There are Version validations for Cassandra/DSE that become a little tedious to maintain as the server versions move forward. For example, #542. It would be easier if we didn't have to revisit this when Cassandra 6 comes out or DSE 8, etc...
┆Issue is synchronized with this Jira Story by Unito
┆Issue Number: CASS-21
The text was updated successfully, but these errors were encountered: