-
Notifications
You must be signed in to change notification settings - Fork 352
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deprecate Openshift specific features #5771
Comments
as the main motivation is the difficult to have an openshift cluster to test it, I agree on the option to mark for deprecation, there is time for affected users in the future to accommodate for the deprecation. I suggest to have the deprecation notice for at least 2 releases. |
As there was no objection around this, I'm moving ahead with the work to deprecate the features in next minor release. However, it is very plausible we maintain these features (with deprecation notice and policy in place) until moving to next major (3.x). |
* S2I (users are invited to use Jib instead) * Route (users are invited to use Ingress instead) Likely to drop support in next major release to minimize potential compatibility issues. Closes apache#5771
* S2I, use Jib instead * Route, use Ingress instead Likely to be supported until a new major release. Closes apache#5771
* S2I, use Jib instead * Route, use Ingress instead Likely to be supported until a new major release. Closes apache#5771
* S2I, use Jib instead * Route, use Ingress instead Likely to be supported until a new major release. Closes #5771
Camel K has a couple of specific features enabled when the application is running on Openshift (mainly S2I and Route configuration). Although they are both a nice addition to the project, they contribute to an extra maintenance effort and a more difficult release process. In order to effectively release and support on Openshift we'd need to run the suite of e2e tests on an Openshift cluster. Unfortunately there is no easy way to do that in public, neither the local tools (ie CRC) are really working in Github Actions in order to perform this action automatically.
Both those feature may be deprecated and replaced by vanilla Kubernetes options, making the development, test and release process easier and less error prone.
I was wondering if there is any objection around this possibility so that we can start planning the deprecation process during the next releases.
Feedback are very welcome.
The text was updated successfully, but these errors were encountered: