Konveyor Sandbox Submission Follow Up


Greetings Alois Reitbauer, Jennifer Strejevitch, Hongchao Deng, Alex Jones, Thomas Schuetz (chairs and tech leads):

We appreciate the questions and feedback provided about Konveyor we received from the TOC. This topic attempts to answer some of the questions that came up during the sandbox application review. Would you be willing to review the questions and answers below and express whether or not you are supportive of Konveyor being moved into Sandbox status? If you are, I can then share this with the TOC and see if they can consider it.

Question: How or why would the Konveyor project ever move beyond sandbox to a graduated state?
Answer: While it is not always traditionally seen in this light, the Konveyor community believes that application modernization is not a one time activity. It is a constant ongoing operation. The Konveyor project has multiple tools within it currently that address various parts of the operations that would take place over time. For example:
    1. To start users may opt to simply rehost virtual machines to KubeVirt. This would be a low friction way to move workloads to Kubernetes. "Yay, my appliction is no on Kubernetes!"
    2. Once running on Kubernetes they might look at moving that application into containers (or a service of that application, i.e. - strangler pattern). In that case Tackle can help them assess and analyze their application. Shortly it will also create deployment manifests and other needed requirements in an automated fashion.
    3. Once running on Kubernetes they might look at replatforming that application to a newer version of Kubernetes on a different cluster and embracing GitOps. In that case, Crane could help them migrate the application with it's state and also remove environment specific dependencies (service cluster IPs). Crane can also help them move their application from a manual deployment into a pipeline based deployment.
    4. Once all this is done there is still a need for application modernization as they may want to make parts of their application serverless, etc. There is no doubt in my mind future enhancement to Kubernetes and the CNCF projects will create needs to once again modernize the same application. I hope this helps explain where the community sees the ongoing need.

Question: Do the Konveyor projects support non-vendor provided Kubernetes (i.e. OpenShift)?
Answer: The Konveyor projects do work with upstream versions of Kubernetes. While it is true that initially some of the projects had dependencies on OpenShift, the team has removed most of these dependencies and any future dependencies discovered would be fixed to ensure that the projects work with upstream Kubernetes. The community is committed to continually improving this experience and is open to helping others test on various distributions of Kubernetes. For example, this end to end demonstration was done on upstream Kubernetes and did not use OpenShift (except for one small portion that has since been addressed). The community did this on purpose because we wanted to find any issues that were happening and address them. Finally, you'll find the teams are making good progress on upstream documentation to ensure users have a good experience upstream first.

Question: Do you have examples of GitHub issues associated with the project?
Answer: Each project within Konveyor has slight variations to their processes, but we are working in the completely open bi-weekly governance meeting to begin to see how we can bring the teams together in a more standard manner. Also, one example of external contributions is happening on move2kube within Konveyor. You can see the PRs here from external parties below:
https://github.com/konveyor/move2kube/commits?author=akhil-ghatiki (https://github.com/konveyor/move2kube/pulls?q=is%3Apr+Akhil+Ghatiki) https://github.com/konveyor/move2kube/commits?author=vovapi (https://github.com/konveyor/move2kube/pulls?q=is%3Apr+vovapi+is%3Aclosed) https://github.com/konveyor/move2kube/commits?author=MorrisLaw (https://github.com/konveyor/move2kube/pull/617) https://github.com/konveyor/move2kube/commits?author=Jan200101 (https://github.com/konveyor/move2kube/pull/53) https://github.com/konveyor/move2kube/commits?author=alealavi (https://github.com/konveyor/move2kube/pull/451)
https://github.com/konveyor/move2kube-api/commits?author=isabellaliu77 (https://github.com/konveyor/move2kube-api/pull/30) https://github.com/konveyor/move2kube-api/commits?author=burnerlee (https://github.com/konveyor/move2kube-api/pull/22) https://github.com/konveyor/move2kube-ui/commits?author=parkedwards (https://github.com/konveyor/move2kube-ui/pull/16) https://github.com/konveyor/move2kube-ui/commits?author=jams008 (https://github.com/konveyor/move2kube-ui/pull/14
In addition, we are aware of one customer using the Tackle project to assess/analyze applications to move to VMware's Tanzu Kuberenetes Grid (not OpenShift).

Given that Konveyor projects run on upstream Kubernetes, have external contribution, and are important on day-2 and we believe could have a path to graduation we would like your support to recommend Konveyor be granted Sandbox status. Are you supportive?