Hi, working for a company that has 2.x and am working on 3.x.

Can't say too much but it's a big shift. The rewrites are significant; under the hood I know less about.

It's certainly a big focus for RH. I think it's great that they've embraced Kubernetes and Docker, but I can imagine it's going to frustrate early adopters who have already got used to one set of terminologies.

One of the lead developers here - this is a ground up rewrite. In brief, we felt that the Kubernetes process (pods and the way containers were grouped) model "felt right" - it was the right fundamental bedrock concept for running software processes in the cloud. Realizing that, it was obvious that we wanted to be built in a way that benefited from the work we've contributed to Kubernetes, so we decided to rearchitecture on top of Kubernetes as micro service components. There have been a lot of productive discussions about Kubernetes being the "kernel of a cloud OS", and we wanted to bring developer experience / build / hands-off deployment flow pieces on top of that. Combined with supporting Docker images natively, the changes were sufficient to justify a rewrite (as much as we all wanted to avoid that).

Also, we had some pain points around distributing and packaging large Ruby apps into random environments, and so a switch to Go meant we could simplify the model of deploying the system components (clients, masters, node agents) onto systems. The CLI client shares a lot of code with the Kubernetes client, and having that in Go allowed us to deal less with the vagaries of deploying Ruby onto Windows (for Java developers).

And yes, I do realize that we've hit every single HN hot button thread in that list.

I tried Openshift 2 briefly, but didn't adopt it partially because it was too opinionated for my taste. I am excited about Openshift 3 for its adoption of Docker containers and Kubernetes.