An introduction to the DCI RHEL Agent's architecture, installation, and usage

This blog post showcases the steps needed (with automated examples) to get an Agent-Based Installer (ABI) cluster in a Virtual Lab up and running

This blog post will show you how you can deploy a fully virtualized ZTP environment, where both the hub and spoke cluster will be placed in virtual machines managed with KVM. For this purpose, DCI will be used as key continuous integration tool to support the installation of both the hub and spoke cluster. This is useful for quickly troubleshooting of issues, not depending on a full baremetal infrastructure for that. The differences between the deployment on baremetal and virtualized scenarios (even though DCI works seamlessly in both cases) will be presented, also highlighting the key aspects you need to have in mind when deploying this pipeline with virtual machines. Best practices and lessons learned will be also shared.

One of the OCP deployment use cases getting more attention lately is the GitOps-ZTP. This article describes how to use DCI to deploy an OCP cluster following this methodology.

As Kubernetes continues to evolve, new features are introduced while older, deprecated APIs are phased out. This cycle ensures the platform remains cutting-edge, but it also presents a significant challenge during upgrades, especially for applications relying on deprecated APIs. In this post, we'll discuss Kubernetes upgrade readiness, the complexities of API deprecation, and how we can detect soon-to-be-removed APIs—both statically and dynamically invoked—using Red Hat Best Practices Certification for k8s.

In this post, we share how to deploy an entire Openshift Container Platform (OCP) cluster on a single baremetal server using the Assisted - Agent Based Installer (ABI) in a virtual environment with Libvirt VMs nodes. We highlight the benefits of ABI installation compared to the Installer Provisioner Infrastructure (IPI) installation that was our de-facto method.

This blog post aims to guide DCI users on locating the resources provided by our DCI agents (dci-openshift-agent, dci-openshift-app-agent, and dci-pipeline) on the server used to launch these agents. It also includes an explanation of each piece of installed code. Having this information clearly described is crucial for troubleshooting, as it helps users know where to look in the DCI agents' code.

The DCI openshift agents bring transparent support to use the newly added Image Digest Mirror Sets (IDMS) in OpenShift. The main use of IDMS is in disconnected clusters. The IDMS provides the registry mirroring functionality for images that are not reachable due to network constraints.

A step by step guide on how to setup DCI Openshift agent on libvirt with Assisted Installs.

A step by step guide on how to setup a DCI lab within a restricted network.

This blog post presents practical examples of dci-pipeline usage that can be useful when dealing with testing and troubleshooting of OCP clusters and workloads deployed on top of it with DCI.

A step-by-step guide on how to create a custom catalog source listing discontinued certified operator releases.

This post gives an example of how to apply, using the DCI automation, a typical PerformanceProfile for a Telco use case.

This short post will describe a new feature in DCI, the way to run dci-pipeline with a Podman container. We will see how it is easy to install, configure and use it.

This blog post continues the overview of dci-pipeline and related testing tools, focusing on some useful features that can really help you when addressing testing and troubleshooting with DCI jobs.

An introduction to DCI labs implementation of disconnected environments.

We are addressing DevOps or QA engineers who run and validate heavy test suites with thousands of tests in every JUnit file. These engineers often feel tired from having to manually create a list of failed tests to send back to the developers. While automated validation can help, it's challenging to implement it for real-world needs, such as making sure all tests are working or that all tests beginning with 'network' are passing. In this post, we will showcase an Ansible role that automates this type of validation.

In previous blog posts, we have learned about the OCP on Libvirt project and the benefits it brings to us, with regards to the flexible deployment of OCP clusters where the nodes are virtual machines deployed on KVM. However, we have only covered the case of one single physical server. Can we use multiple physical servers to set up a lab with multiple, distributed deployment on Libvirt-based OCP clusters? The answer is yes! And we will explain the main requirements and challenges in terms of networking in this blog post.

One of the main challenges during the workload migration to OCP-4.12 is the massive deprecation of beta APIs. In this post, we will discuss how to identify the APIs that are going to be deprecated and how DCI could simplify this task for you.

The storage tester role, shipped in the DCI OpenShift Agent, allows the user to test a storage class behavior during an upgrade. It can be seen as an example of resilience testing that can be done with DCI on a cluster.

This post will describe what is a pipeline in the DCI world and how to use it step by step to create workflows in our testing environment.

In previous blog posts, we have learned how to use dci-check-change to effectively test code changes on DCI agents. This blog post aims to bring this knowledge to the next level, learning about specific use cases that may be interesting for testing changes in particular scenarios.

This post is a tutorial on how to install a standard three-masters and two-workers OpenShift cluster on one powerful baremetal server. The idea is to first create all required virtual machines and networks using libvirt KVM driver, and then install OpenShift on that virtual cluster using DCI.

ACM is a tool that allows the deployment and management of OCP clusters and workloads on top of it. In this post, we will go through an example of how to use ACM to deploy an SNO instance in the DCI way.

ACM is a tool that allows deploying, and managing OCP clusters and workloads on top of it. Now the DCI Agent has the support to automate the creation of SNO instances by the integration of the ACM roles.

This post aims to provide an overview of the certification test suites integrated in DCI and help you plan your certification journey.

When a pod fails to contact another network resource, logs might provide some hints, but sometimes the ultimate evidence of what is happening can be seen from a tcpdump packet capture; however, not all pods have tcpdump tools or even a shell to interact with. This blog post demonstrates how to use certain tools available in OpenShift and GNU/Linux to overcome those challenges and use tcpdump to validate network traffic in pods deployed on top of OpenShift clusters.

The dci-openshift-agent is complex and any code changes could potentially break it. It's important that all code changes are tested. Since there are multiple ways to install OpenShift using the dci-openshift-agent it may take several test runs to properly verify. This blog post summarizes the different ways and environments used to test your code.

DCI components are really useful for establishing efficient CI workflows with partner workloads. This blog post will cover the full workflow that a partner should follow, from creating the components to deploying DCI jobs using these components.

Using the features of Quay to handle Access Management

dci-queue: a simple resource management system in DCI

This post has some practical information about running Preflight certification suites with DCI. You will learn how to run the tests, debug using log files, and submit the results for certification. All this is an embedded functionality offered by DCI.

Prefixes allow you to control the inventory and settings of different DCI environments from a single central directory. We hope this article will convince you of the convenience of using prefixes in your DCI labs and will serve as a solid foundation for you to start leveraging their potential.

Good practices in naming for DCI jobs

Developing for the OCP ecosystem can be a daunting task, developing for the ecosystem that tests this can become even more so but, fear not, we have tried to make it as painless as possible.

Everydays, Red Hat DCI platform runs hundreds of jobs from different teams and partners, with all our products, with different purposes: debugging, certifications, tests, daily activities, etc. You may need to build a dedicated dashboard to follow your own specific activity, display graphical results, study some specific data or identify specific job behaviors. For such requirements, Google spreadsheet can provide you facilities to implement your ideas in a few minutes. In this blog post, you will learn how to quickly build a dashboard with Google spreadsheet by requesting DCI data, getting it dynamically and sending a pdf report by email periodically.

The dci-openshift-app-agent enables Cloud-Native Applications and Operators in OpenShift using the Red Hat Distributed CI service. It also includes the possibility of running a set of certification tools over the workloads deployed by this agent, including the Red Hat Best Practices for Kubernetes test suite (former CNF Cert Suite), which allows CNF Developers to test their CNFs readiness for certification. This blog post summarizes the main points to have in mind when running the certsuite with the dci-openshift-app-agent, also providing an example.

Components are the artifacts used in a DCI job, these are the elements that distinguish jobs. They are the elements to be tested on each job. This post will discuss their use and an example of how to automate them to be continuously tested.

Single Node OpenShift (SNO) was introduced officially in OCP 4.9, available documentation describes the ways to deploy it using Assisted Installer through the Red Hat portal in order to generate an ISO and install it using virtual media or ACM. This article illustrates how we leverage some of those features and highlights the most relevant aspects of the installation using DCI Openshift Agent.

In a previous post, you have been introduced to Red Hat Distributed CI (DCI) infrastructure and how it enables Red Hat partners to integrate into Red Hat CI workflow. Now, we will be focusing on how to interact with DCI through the Python API.

Openshift Cloud Platform is meant to be the standard for modern Telco infrastructure. One of the goals of the Telco Partner CI Lab team is to test the installation of Openshift with all the requirements needed for Telco workloads. For one of our main partners, it means installing/upgrading an Openshift platform, some extra operators to handle specific hardware like SRIOV cards, and external products for storage or load balancing needed to handle CNFs to reduce any risk.

Most, if not all of the Distributed CI repositories, including this blog, are hosted in softwarefactory-project.io. Gerrit is the tool used to integrate the changes to such repositories. On the other hand, GitHub is the most popular service to host and integrate changes these days, this makes most of the developers familiar with GitHub to a certain extent. As such, this article attempts to explain to developers/contributors how to use Gerrit from the perspective of someone already familiar with GitHub.

Red Hat provides mainly infrastructure software like RHEL, OpenShift or OpenStack. These are established technologies for our customers but also for our partners. In order to keep the software as stable as possible, Red Hat works on doing various Quality Assurance and Continuous Integration processes. In this article we are going to focus on one specifically. The CI workflow from the point of view of a Red Hat partner.