Two related (but slightly different) questions …
1) Is it possible to setup Openshift RBAC such that some specific tenants can only use standard kubernetes APIs/ CLIs and not Openshift specific api/ clis ? This way, a service provider can provide some tenants a pure native kubernetes only service (if some specific tenants prefer this and want to ensure their applications are portable to pure kubernetes environments at all times) and some other tenants can get the full OPenshift API/ CLI access within another project.
2) Any document/ guidelines on what one has to do in order to create a private build in which Openshift Origin 3.6 is built with Kubernetes 1.7 (or similar future combinations). This may be something someone may want to do to pick up a new k8s feature that only exists in a future upstream release but is otherwise completely independent of Openshift Origin. Of course this would not be community supported (private image/ fork or Origin only) but useful if some tenant/ project is using pure kubernetes only functionality and needs the latest upstream kubernetes.
Not today. We hope to do so at some point in the future, but today openshift requires additional compiled in control points that only work when installing origin directly from the binaries we build.
On Aug 22, 2017, at 6:36 AM, Yu Wei <yu2003w hotmail com> wrote:
Now we have existing k8s cluster running workloads.
We also want to make use of features provided by Openshift Origin, for example DevOps etc.
Is that possible to integrate openshift origin with our existing k8s?
Interested in open source software, big data, Linux
dev mailing list
dev lists openshift redhat com