JBoss Tools 4.14.0 and Red Hat CodeReady Studio 12.14 for Eclipse 4.14 (2019-12) are here and waiting for you. For this release, we focused on improving container-based development, adding tooling for the Quarkus framework, and fixing bugs. We also updated the Hibernate Tools runtime provider and Java Developer Tools (JDT) extensions, which are now compatible with Java 13. Additionally, we made many UI changes to platform views, dialogs, and toolbars.
Continue reading Red Hat CodeReady Studio 12.14.0.GA and JBoss Tools 4.14.0.Final: OpenShift and Quarkus updates
As part of the Open Data Hub project, we see potential and value in the Kubeflow project, so we dedicated our efforts to enable Kubeflow on Red Hat OpenShift. We decided to use Kubeflow 0.7 as that was the latest released version at the time this work began. The work included adding new installation scripts that provide all of the necessary changes such as permissions for service accounts to run on OpenShift.
Continue reading Installing Kubeflow v0.7 on OpenShift 4.2
In this article, we will see a similar pattern when writing the REST API in any known framework vs. writing an Operator using Kubernetes’ client libraries. The idea behind this article is not to explain how to write a REST API, but instead to explain the internals of Kubernetes by working with an analogy.
To follow along, you will need the following installed:
As a developer, if you have used the REST API with frameworks like Quarkus/Spring (Java), Express (Nodejs), Ruby on Rails, Flask (Python), Golang (mux), etc., understanding and writing an operator will be easier for you. We will use this experience with other languages or frameworks to build our understanding.
Continue reading “Operator pattern: REST API for Kubernetes and Red Hat OpenShift”
A previous article, Debugging applications within Red Hat OpenShift containers, gives an overview of tools for debugging applications within Red Hat OpenShift containers, and existing restrictions on their use. One of the restrictions discussed in that article was an inability to install debugging tool packages into an ordinary, unprivileged container once it was already instantiated. In such a container, debugging tool packages have to be included when the container image is built, because once the container is instantiated, using package installation commands requires elevated privileges that are not available to the ordinary container user.
However, there are important situations where it is desirable to install a debugging tool into an already-instantiated container. In particular, if the resolution of a problem requires access to the temporary state of a long-running containerized application, the usual method of adding debugging tools to the container by rebuilding the container image and restarting the application will destroy that temporary state.
To provide a way to add debugging tools to unprivileged containers, I developed a utility, called
oc-inject, that can temporarily copy a debugging tool into a container. Instead of relying on package management or other privileged operations,
oc-inject’s implementation is based on the existing and well-supported OpenShift operations
oc rsync and
oc exec, which do not require any elevated privileges.
This article describes the current capabilities of the
oc-inject utility, which is available on GitHub or via a Fedora COPR repository. The
oc-inject utility works on any Linux system that includes Python 3, the
ldd utility, and the Red Hat OpenShift command-line tool
Continue reading “Installing debugging tools into a Red Hat OpenShift container with oc-inject”