That’s the long term direction, now that many extension points are maturing
enough to be useful. But I’ll caution and say the primary goal is to
reduce maintenance costs, improve upgrade isolation, and maintain the
appropriate level of security, so some of the more nuanced splits might
take much longer.
On Aug 14, 2018, at 6:51 PM, Daniel Comnea wrote:
Hi Clayton,
Great progress!
So am i right to say that *"**splitting OpenShift up to make it be able to
run on top of kubernetes"* end result will be more like openshift distinct
features turning more like add-ons rather than what we have today?
On Tue, Aug 14, 2018 at 6:17 PM, Clayton Coleman
wrote:
> As part of the continuation of splitting OpenShift up to make it be able
> to run on top of kubernetes, we just merged https://github.com/
> openshift/origin/pull/20344 which removes "openshift start node" and the
> "openshift start" commands. This means that the openshift binary will no
> longer include the kubelet code and if you want an "all-in-one" openshift
> experience you'll want to use "oc cluster up".
>
> There should be no impact to end users - starting in 3.10 we already only
> used the kubelet (part of hyperkube binary) and use the
> "openshift-node-config" binary to translate the node-config.yaml into
> kubelet arguments. oc cluster up has been running in this configuration
> for a while.
>
> integration tests have been changed to only start the master components
>
> ___
> dev mailing list
> d...@lists.openshift.redhat.com
> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
>
>
___
users mailing list
users@lists.openshift.redhat.com
http://lists.openshift.redhat.com/openshiftmm/listinfo/users
