4 ms·
From a quick read, this looks like more or less a ground-up rewrite of OpenShift? Is anyone a user of 2.x? How does this feel?
by pquerna 12y ago
From a quick read, this looks like more or less a ground-up rewrite of OpenShift?
Is anyone a user of 2.x? How does this feel?
- zwischenzug 12y agoHi, 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.
- preillyme 12y agoI trust that RH has their reasons for such a large shift. So far they're doing amazing work contributing back to Kubernetes especially all the shepherding that Clayton Coleman is doing for the broader community. As the CEO of Kismatic I'm excited that more companies are jumping on the Kubernetes bandwagon.
- zwischenzug 12y agoIt's the virtuous circle of open source I think :) If google and redhat are getting behind it, I guess they can both sell more stuff off the back of successful products. Otherwise, vendor-specific container and orchestration solutions are more likely to flounder. But as the CEO of Kismatic I'm guessing you know this already :)
- smarterclayton 12y agoYup. It's all about communities and building out on top of things that everyone finds value in. And we don't mind doing some of the boring work (testing, reliability work) to make those communities even more successful.
- tedchs 12y agoI 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.
- smarterclayton 12y agoOne 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.