bump open api image to v7.3.0

[DrFaust92]

Bump openapi generator image to latest to generate go (and python) clients with newer dependecies (in go case newer go version as today go 1.13 is used and is very old, while new openapi gen uses newer 1.18 image and depencies)

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in newsfragments.

[ephraimbuddy]

This will cause a lot of breaking changes to the RESTAPI. We should reserve it for the next major

[pierrejeambrun]

I am afraid @ephraimbuddy is right.

On the other hand this starts to be a little blocking. For instance for the go client, and other client issues where we need to manually fix things. (Missing supports for certain keywords in the spec etc...).

We didn't discuss this but maybe we could do a major release for clients, independantly of airflow major release, just an idea, to not have clients stuck for a long long time. Like update the client versionning policy to allow that. I don't think major version needs to match between client and airflow core. (It will be a little harder to handle but worth I believe).

If this sounds like an idea worth discussing, I can bring that to the dev list.

[eladkal]

@pierrejeambrun i think mailing list discussion is required here

[potiuk]

Yeah. I think there are also another reason we should discuss it - namely security/release process for the clients. The "Python API" client we release might be seen as an "official ASF Source package"

Currently we are voting on Python Client and we do not check the provenence of it - because this is code that got genereated by the release manager. and committed - unreviewable and unverifiable.

So IMHO upgrading the client is also an opportunity to update the build and release process - what should happen, we (PMC members) should be able to verify that the build has been generated by the release manager from the API specification and not tampered with. It might be a "reproducible" build or just "verifiable build" - but it boils down to being able to run the build and compare if what comes out of it (providing sufficient external tools we can rely-on - such as official image released by open-api).

I think we can solve both problems at the same time - by improving automation and adding simple-to-add verification step whether the package we are voting on is "really" generated from the specification without being tampered with.

This is part of the security improvement of our release process.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

[ephraimbuddy]

@DrFaust92 , can you rebase

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.