> On Sep 17, 2015, at 10:03 AM, Colin Walters <walt...@verbum.org> wrote: > >> On Wed, Sep 16, 2015, at 07:23 PM, Clayton Coleman wrote: >> >> We don't want to encourage local host paths in the future. For now it's fine > > Are you planning to use Docker volumes then? Or how else to enable > persistence > in the single-host scenario? > > (reads farther down) > >> The bulk will move into etcd and be defaulted, the remainder >> (connection info, admin secrets) is probably going to have to come >> from the host. There will probably have to be a "slurp in config" >> option on master startup forever. > > Interesting. Hmm. And etcd will run as a separate container then I'm > assuming, rather than the all-in-one? If we're storing private keys in etcd, > then that needs to be secured, which means we need keys... > > Maybe we say that for production use, we expect to use an external > CA, and for non-production use (e.g. local Vagrant dev), the defaults > are insecure, and we expect your VM to be behind NAT or a firewall. > >> It's going to be a while before Kube supports pure additive function. > > Yeah, I understand that. I think broadly speaking too what OpenShift > has been doing with shipping earlier versions of some important > features is good - it gets them more real-world use before they go > upstream. > >> similar to >> https://github.com/openshift/origin/blob/master/examples/ha/openshift-ha.yaml). > > Wait...is that running OpenShift inside an existing Kubernetes cluster, > or is it a self-referential OpenShift?
Could be either. We've talked about bootstrap nodes and master running ha setup
