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 <comnea.d...@gmail.com> 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 <ccole...@redhat.com> 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 > dev@lists.openshift.redhat.com > http://lists.openshift.redhat.com/openshiftmm/listinfo/dev > >
_______________________________________________ dev mailing list dev@lists.openshift.redhat.com http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
