Sounds good, thank you for feedback. On Wed, Aug 15, 2018 at 2:47 AM, Clayton Coleman <[email protected]> wrote:
> 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 <[email protected]> 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 <[email protected]> > 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/open >> shift/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 >> [email protected] >> http://lists.openshift.redhat.com/openshiftmm/listinfo/dev >> >> >
_______________________________________________ dev mailing list [email protected] http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
