oc cluster up is more targeted at quick start use cases.  I feel like moving into the space of advanced configuration conflicts with our desire to push for Ansible as the method for configuring and installing real clusters.  SDN configuration would fall into the advanced use case category for me.

Granted, the result is that for features relying on underlying implementations (like NetworkPolicy) this means they are not usable with oc cluster up.  

I'd rather document the purpose of oc cluster up than try to support things like this.

Thoughts here Cesar?

(In reply to Paul Weil from comment #1)
> SDN configuration would fall into the advanced use case category for me.

There's not any configuration to it, other than setting networkPluginName. And SDN is the default for "real" OpenShift installs, so if it isn't going to be configurable, then it seems like "you get ovs-multitenant and you can't change it" is a more reasonable default than "you get kubenet and you can't change it"...

(Although I guess for this particular customer use case they'd need to be able to specify that they wanted the Tech Preview redhat/openshift-ovs-networkpolicy plugin rather than the standard multitenant one.)

OTOH, this would add another dependency (openvswitch), and probably even more dependencies in the future (OVN).

Regardless of whether it should be done or not, the biggest technical limitation I see is that afaik installing our networking plugin requires restarting Docker. Cluster up is simple in that we can connect to any Docker and get a cluster started without knowing much more about the machine that Docker is running on. Doing something like this would require us to know a little bit more of the machine which is getting more into the realm of what Ansible should do. Maybe what we should do is focus on getting the Ansible experience of setting up a single node cluster to the level of ease of use of cluster up.

We don't require restarting docker any more (as of 3.4)

Thanks Dan, that is really good to know. Without looking, as far as the required binaries, are those shipped inside any Docker image? Are they inside the origin image?

Yes, they're in openshift/node. (It looks like openshift/origin is targeted at the all-in-one use case and doesn't have support for SDN or storage plugins, while openshift/node is targeted at separate master/node installations and supports everything.)

There's also openshift/openvswitch, which runs *just* openvswitch, and is used as part of the containerized atomic-host install. Not sure if that would be easier to integrate with cluster up.

Closing this for now, we can reconsider in the future if this is something that more folks would find useful