Adding here the chat/answer regards the third question made by [~lfitzgerald] in the chat now.
h4. If we use the OCP ouath how to provide an alternative for the user which is running it in Kube?
First, at all, I'd like to highlight that the best approach in POV should use the ks8 to setup the OAuth which should make it works for both as the following references.
* https://appscode.com/products/voyager/9.0.0/guides/ingress/security/oauth/
* https://alikhil.github.io/2018/05/oauth2-proxy-for-kubernetes-services/
* https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md
However, if we move forward with the approach to use OCP oauth then we can describe in the README that is a pre-requirement install the OAuth OCP proxy in kube. See the [doc|https://github.com/openshift/oauth-proxy] which is telling that will work in both.
IMHO, we should not use OCP API at all since the Kubernetes API will keep it compatible for both, however, if we are not able to do it some specific point of for some detail in the future we can add manual steps to make work with kubernetes and/or at least ir will be fewer changes to be made in the project.
Another point is that OCP shows move forward to use the Kubernetes resources instead of their specifications in order to reach full feature parity then I am afraid that we can face a scenario where the OCP API used cannot so longer work on it as well.
For example:
bq. The long-term goal in OpenShift Container Platform is to reach full feature parity in Kubernetes deployments and switch to using them as a single object type that provides fine-grained management over applications.
REF: https://docs.openshift.com/container-platform/3.11/dev_guide/deployments/kubernetes_deployments.html#kubernetes-deployments-vs-deployment-configurations
c/c [~dffrench] |
|
