You might have read about the architectural changes and enhancements in Red Hat OpenShift 4 that resulted in operational and installation benefits. Or maybe you read about how OpenShift 4 assists with developer innovation and hybrid cloud deployments. I want to draw attention to another part of OpenShift 4 that we haven’t exposed to you yet…until today.
When Red Hat acquired CoreOS, and had the opportunity to blend Container Linux with RHEL and Tectonic with OpenShift, the innovation did not remain only in the products we brought to market.
An exciting part about working on new cloud-native technology is the ability to redefine how you work. Redefine how you hammer that nail with your hammer. These Red Hat engineers were building a house, and sometimes the tools they needed simply did not exist.
OpenShift 4 represents new features, methods, and use cases that had not been attempted before with its upstream components (Kubernetes). A lot of the development process was around building internal tooling that would enable OpenShift to be successful as a distribution of Kubernetes and as an application platform. There were three specific results of that tooling work that resulted in some exciting improvements that you might already be using, but didn’t realize it just yet.
Over The Air
One of the technology concepts we leveraged from CoreOS is called “over the air” updates (OTA). If you are like me, you are probably thinking “Why is that considered important. We have been doing yum, docker, apt updates over the air for years!” This is different in some pretty significant ways.
We created an entirely new software distribution system to intelligently suggest and apply Kubernetes cluster upgrades. This software component runs as a SaaS service from cloud.redhat.com and it allows us to help OpenShift 4 clusters to automatically upgrade.
By combining Red Hat’s deep experience in managing software lifecycle with Kubernetes-native configuration, automatic management with Kubernetes Operators, and a deep feedback loop between cluster health and software rollout, we can help reduce the complexity and risk in updating your production clusters while you can increase the speed at which you can roll out critical security fixes. Upgrade at the “click of a button” without stress.
This SaaS service has knowledge of what it is doing. Imagine if you had more than 1,200 lines of business (LOBs) and each one deployed up to 250 OpenShift clusters. They installed on multiple and different infrastructures. But they all used your software to do so.
You could start becoming aware when some organically updated before others and you could observe success rates and issues. If you found a common pattern you could stop the upgrade from reaching clusters that had not been upgraded yet. This allows Red Hat to more deeply partner with our customers to help shoulder the responsibility of running OpenShift.
OpenShift 4 introduced an optional component called telemeter. When enabled, we can have immediate awareness and feedback when a piece of OpenShift isn’t functioning properly so we can create a fix for your issue before you even know the problem is there.
We take care of updating the operating system and the platform together. You no longer need to cycle them on two different maintenance windows and we no longer have to suffer from a configuration skew or poor target system while updating the layers on top of the stack.
All four of those benefits combine to form over the air updates (OTA). OTA is more than pushing software around. It’s about us reaching out to you and declaring that we want to do more for you. Enabling over the air updates in OpenShift may help you keep your OPEX as low as possible.
Continuous Improvements
OpenShift 4 has been streaming continuous fixes for a few weeks. Hopefully you have noticed by now that OpenShift 4 has been able to release 8 z-stream patches in 11 weeks. That is almost one per week, and that is our goal. In OpenShift 3 we would typically release a z-stream patch once every 3-5 weeks. Why have we done this? We did this for two reasons:
With the OTA upgrade framework in place we can have a scientifically higher confidence probability of success.
You do not have to take all the z-streams when they are released as they are cumulative, but by allowing them out each week when they are ready, you also don’t have to wait. If you are being affected by an issue, you can now have the lessons learned from other customers at your fingertips.
When you are moving around that much software across public cloud and datacenter OpenShift deployments, you need strong automated testing solutions. Building that to the scale (1,000s of clusters per week) and diversity (AWS, Azure, GCP, IBM Public, vSphere, OpenStack, RHV) needed for OpenShift 4 was a large engineering project.
In this new world of OTA coupled with continuous improvements, we refined how we were leveraging CI/CD to the point of extending its checkpoints all the way down to our customers.
Nightly Builds:
Starting today, we have decided to expose our customers and partners to an opportunity to gain access to our nightly builds.
In the past, we would have had to run a high touch beta to give our customers this level of access. By leveraging the new tooling built for OTA and the above continuous improvements, we are now in a position where we can expose nightly builds for a future release of OpenShift (in this case OpenShift 4.2).
These are the caveats of nightly builds: they are not for production usage, they are not supported, they will have little documentation, and not all the features will be baked in them. But we intend for them to get better and better the closer they get to a GA milestone. The documentation should slowly grow as well.
What they do offer is the ability to get the earliest possible look at features as they are being developed. That can help during deployment planning and ISV level integrations. It is for those reasons we feel our customers and partners will truly enjoy this new opportunity.
It’s About Working as a Community:
We believe that a transformation in software development is beginning with our continuous contributions in open source, our new Kubernetes over the air upgrades, and the automated integration, testing and rollout that makes these nightly builds available.
We have extended the classic continuous feedback loop used in agile software development to reduce the time it takes to bring fixes and innovation from customer to community to Red Hat back to the customer. The health of production clusters is assessed and translated directly to critical interventions and fixes that rapidly make their way out to the fleet.
A software loop that in the past might have only been available to hosted services is now available for users and customers of OpenShift. We see this as a true evolution in open source software and I’m excited about where it is going to lead us…together.
To find out more go to try.openshift.com. Log in and select your infrastructure. Then look for the new developer preview link!
The post Introducing Red Hat OpenShift 4.2 in Developer Preview: Releasing Nightly Builds appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift
Published by