chore(superset): add 6.1.0 as supported version

[sweb]

Description

Part of #1504

Definition of Done Checklist

Note

Not all of these items are applicable to all PRs, the author should update this template to only leave the boxes in that are relevant.

Please make sure all these things are done and tick the boxes

• Changes are OpenShift compatible
• All added packages (via microdnf or otherwise) have a comment on why they are added
• Things not downloaded from Red Hat repositories should be mirrored in the Stackable repository and downloaded from there
• All packages should have (if available) signatures/hashes verified
• Add an entry to the CHANGELOG.md file
• Integration tests ran successfully

TIP: Running integration tests with a new product image

The image can be built and uploaded to the kind cluster with the following commands:

boil build <IMAGE> --image-version <RELEASE_VERSION> --strip-architecture --load
kind load docker-image <MANIFEST_URI> --name=<name-of-your-test-cluster>

See the output of boil to retrieve the image manifest URI for <MANIFEST_URI>.

[NickLarsenNZ]

LGTM, left a note about a newer uv, but not a blocker.

[NickLarsenNZ]

Maybe also

Suggested change

	# https://github.com/dpgaspar/Flask-AppBuilder/blob/release/5.0.2/requirements/extra.txt#L7
	# https://github.com/dpgaspar/Flask-AppBuilder/blob/release/6.1.0/requirements/extra.txt#L7

I didn't check the URL.

[NickLarsenNZ]

Sorry, I was thinking Superset version, that's the FAB version.
It should match the one in the constraints (I didn't check that).

Feel free to resolve this once read.

[sbernauer]

To add to this: I think we could do a much better way of documenting where this versions come from. E.g. I have no clue how we ended up with nodejs 20.20.2 and how you validated that is still the correct version to use for Superset 6.1.0

I propose something like

[versions."6.1.0".build-arguments]
cyclonedx-bom-version = "6.0.0"
# flask-appbuilder-version = "5.0.2" # https://github.com/apache/superset/blob/6.1.0/requirements/base.txt#L123 (search for `flask-appbuilder==`)
authlib-version = "1.2.1" # https://github.com/dpgaspar/Flask-AppBuilder/blob/release/5.0.2/requirements/extra.txt#L7 (search for `authlib==`)
python-version = "3.11" # 3.10 - 3.12 are supported. TODO: Document why we choose 3.11 https://github.com/apache/superset/blob/6.1.0/pyproject.toml#L32-L36
uv-version = "0.11.18" # The version should be independent from Superset, so we use the latest available version
nodejs-version = "22.22.2" # https://github.com/apache/superset/blob/6.1.0/superset-frontend/.nvmrc
nvm-version = "v0.40.4" # TODO: Where does this come from?

If you are happy with it it would be great if you could adopt the previous versions as well.
And yes, this means Superset 4.1.4 should propably use nodejs 18.20.1 and 6.0.0 20.18.3. We might uncover a bug here ;)

Meta: Can we bump to Python 3.12?

[sweb]

Meta: Can we bump to Python 3.12?

Superset has Python 3.11 as a requirement. (https://superset.apache.org/developer-docs/#prerequisites)

[sbernauer]

As the pyproject.toml and the docs contradict I think I would trust the pyproject.toml more.
If you git blame the pyproject.toml you find apache/superset#33434. So I think we should give 3.12 a try (another case for better version documentation :))

[sweb]

To add to this: I think we could do a much better way of documenting where this versions come from. E.g. I have no clue how we ended up with nodejs 20.20.2 and how you validated that is still the correct version to use for Superset 6.1.0

I propose something like

[versions."6.1.0".build-arguments]
cyclonedx-bom-version = "6.0.0"
# flask-appbuilder-version = "5.0.2" # https://github.com/apache/superset/blob/6.1.0/requirements/base.txt#L123 (search for `flask-appbuilder==`)
authlib-version = "1.2.1" # https://github.com/dpgaspar/Flask-AppBuilder/blob/release/5.0.2/requirements/extra.txt#L7 (search for `authlib==`)
python-version = "3.11" # 3.10 - 3.12 are supported. TODO: Document why we choose 3.11 https://github.com/apache/superset/blob/6.1.0/pyproject.toml#L32-L36
uv-version = "0.11.18" # The version should be independent from Superset, so we use the latest available version
nodejs-version = "22.22.2" # https://github.com/apache/superset/blob/6.1.0/superset-frontend/.nvmrc
nvm-version = "v0.40.4" # TODO: Where does this come from?

If you are happy with it it would be great if you could adopt the previous versions as well. And yes, this means Superset 4.1.4 should propably use nodejs 18.20.1 and 6.0.0 20.18.3. We might uncover a bug here ;)

Meta: Can we bump to Python 3.12?

So, I looked into this a bit more. First of all, I think having a structured approach here is really good and luckily we have it already for a couple of files, but having it for all would be amazing. I can do this for all supported versions, however you also raised the question of how I validated that 20.20.2 was the right version for 6.1 (which it isn't, I just took the value in the development prerequisites because I didn't find a good source, so good catch thank you very much!).

My approach here was simple: I built the image and started one of the superset demos to see if I could find something that does not work. I also ran the kuttl tests. How should this be extended, or was your question more on having a clear rule for which version to pick?

I guess the nvm-version is just the latest - I found 0.37 (https://superset.apache.org/developer-docs/contributing/development-setup#nvm-and-node) but I'd treat it similarly to uv, so always latest.

For Python, we now just use the newest version mentioned in pyproject.toml? There is also a Python 3.12 Dockerimage Superset publishes - we could also use exactly the versions they use there.

Last question to clarify here from my side: We already have images that use a newer minor version (in some cases even a major) and it did not cause any issues since at least the last release - shouldn't we keep this because it most likely contains bug fixes? Most likely not for majors, but for minor, I could see this.

[sweb]

@sbernauer how do you feel about something like this: a5aaef0#diff-5101f479d9bdf13ecd77113973d4d2d9d74a2a1533b4c28eafb7638f2b661210

[sbernauer]

Last question to clarify here from my side: We already have images that use a newer minor version (in some cases even a major) and it did not cause any issues since at least the last release - shouldn't we keep this because it most likely contains bug fixes? Most likely not for majors, but for minor, I could see this.

I think I would try to stay as close to upstream as possible. Our kuttl tests only test like 5% of the features of our tools. Security people might disagree and I'm willing to do bumps to fix CVEs, but tools have too often broken things in patch level bumps (Just recently Hive 4.0.1 or Hadoop 3.4.3).

how do you feel about something like this:

I like that, thanks! That's all I wanted, so from my perspective we can resolve this thread.

Also thanks for Python 3.12!

[sweb]

Bumped Python to 3.12 (and 3.11 for 4.1.4): a9e0624

I had to update opa-authorizer for this, so scope has increased a bit but I think this is for the better. Kuttl tests passed for all 3 versions, I am now going to test them on a demo.

[sbernauer]

I like the new docs and script. Feel free to let someone else re-approve during the long weekend

[sbernauer]

nit: I would rename it to something like gather-upstream-versions.sh or print-upstream-versions.sh

[sbernauer]

Last question to clarify here from my side: We already have images that use a newer minor version (in some cases even a major) and it did not cause any issues since at least the last release - shouldn't we keep this because it most likely contains bug fixes? Most likely not for majors, but for minor, I could see this.

I think I would try to stay as close to upstream as possible. Our kuttl tests only test like 5% of the features of our tools. Security people might disagree and I'm willing to do bumps to fix CVEs, but tools have too often broken things in patch level bumps (Just recently Hive 4.0.1 or Hadoop 3.4.3).

how do you feel about something like this:

I like that, thanks! That's all I wanted, so from my perspective we can resolve this thread.

Also thanks for Python 3.12!