• 16 Dec, 2025

  Unlocking Collaborative AI: Integrating the A2A Protocol with LightSpeed Stack

  The rapid proliferation of specialized AI agents has marked a significant turning point in automation. While these agents excel at specific tasks, their true potential is unlocked only when they can collaborate, combining unique capabilities to solve complex, multi-faceted problems. The challenge lies in enabling this collaboration without creating a tangled web of custom, point-to-point integrations. The Agent2Agent (A2A) protocol emerges as the standardized solution, providing a common language for diverse agents to communicate effectively. This article explores how we...

• 26 Mar, 2025

  Stock Recommendation AI Agents with OpenShift, OpenShift AI, and Hyperscalers

  Authors Sharon Dashet Luis Tomás Bolívar Preface As we transition from initial Generative AI proofs of concept (POCs) and chatbots to production-ready AI systems, AI Agents and Agentic AI are emerging as the driving force behind intelligent automation in enterprises. These agents, capable of collaborating, understanding complex tasks, retrieving information, and making informed decisions, are transforming how teams operate. In this demo, we will explore how to build and fully operationalize AI Agents using Red Hat OpenShift, Red Hat Developer...

• 26 Mar, 2025

  Infrastructure Deployment for Stock recommendation AI Agents and Hyperscalers

  To deploy the infrastructure needed for the Stock Recommendation AI Agents with OpenShift, OpenShift AI, and Hyperscalers blog, you have two options: Use the Developed Validated Pattern: This is the recommended approach for a streamlined deployment. Manually Deploy All Dependencies: This option provides more control but requires more effort. Both options start from a base OpenShift installation, which can be obtained by following the instructions here. How to Install the Validated Pattern First, clone the validated pattern repository and check...

• 21 Oct, 2024

  Automating RAG Deployment with OpenShift AI and Validated Patterns

  Creating demos that are easily reproduced is key for collaboration and knowledge sharing. This blog post covers the steps followed to create automations, in a GitOps fashion, to deploy a Retrieval-Augmented Generation (RAG) demo on top of OpenShift, including the OpenShift AI infrastructure and its dependencies. Why Validated Patterns? We have opted for using the Validated Patterns framework. This represents an evolution of how applications are deployed in hybrid cloud environments. Validated Patterns automatically deploy a full application stack using...

• 17 Jul, 2024

  Quantizing Models with GPTQ utilizing Marlin kernels

  In this post we cover the steps to quantize (4-bit) a big model using GPTQ and then using Marlin kernels to achieve better inference performance. Let´s first cover some of the basic before getting into the steps for quantization. What is GPTQ? GPTQ is an accurate post-training quantization technique that allows for efficient deployment of large language models (LLMs) like GPT on consumer hardware. The key points about GPTQ are: Layerwise Quantization: GPTQ quantizes the weights of the LLMs one...

• 4 Jun, 2024

  Unleashing the potential of Function as a Service in the cloud continuum

  Excited to share the article: Unleashing the potential of Function as a Service in the cloud continuum! The PHYSICS project has successfully concluded, highlighting remarkable collaboration and innovation. Red Hat engineers and partners have made significant strides in evolving Function-as-a-Service (FaaS) in the cloud continuum, advancing multicluster automation, energy efficiency, and autoscaling.

• 22 Dec, 2023

  Deploy OpenStack on OpenShift with Networker Nodes

  In this post I’ll cover the steps to deploy an environment with install_yamls, with two edpm computes where one of them acts as a networker node, instead of having them either distributed in all the compute nodes or in the controllers. This means that the N/S traffic for VMs without Floating IPs will be centralized in that networker node. Deploy CRC Following the steps detailed at install_yamls the first step is to clone the repository and deploy CRC: $ git...

• 19 Dec, 2023

  Deploying OVN BGP Agent with DevStack

  DevStack is a nice tool for developers to easily test, debug and code for different OpenStack projects. We have recently added support for the OVN BGP Agent so that we can deploy a testing OpenStack setup with the agent. It won’t connect to any peer but it is sufficient to test if the wiring is done properly, as well as if FRR is configured as it should. And you could create another testing VM in the same bridge if you...

• 29 Nov, 2023

  Leveraging Knative, Submariner and OCM at PHYSICS EU Project for multicluster orchestration

  PHYSICS is a high-technology European research project with a consortium of 14 international partners, including technology producers, research centers, and universities. The main goal of PHYSICS is to unlock the potential of the Function-as-a-Service (FaaS) paradigm for cloud service providers, platform providers, and application developers, and foster its wide deployment. PHYSICS enables application developers to design, implement, and deploy advanced FaaS applications using new functional flow programming tools that leverage proven design patterns and existing libraries of cloud/FaaS components. The...

• 9 Jan, 2023

  How to make the OVN BGP Agent ready for HWOL and OVS-DPDK

  Currently, the OVN BGP Agent depends on Kernel networking capabilities (ip rules and ip routes) to redirect traffic in/out of OpenStack OVN Overlay. This blocks the option to speed up the connectivity to the VMs exposed through BGP, i.e., it won’t work for Hardware Offloading (HWOL) or OVS-DPDK. This blog post describe how we can make it HOWL and/or OVS-DPDK ready by leveraging OVN capabilities. Main Idea The main idea to make the BGP capabilities of OVN BGP Agent compliant...

• 10 Jan, 2022

  OpenStack with BGP accelerated with eBPF/XDP

  In a previous blog post we described how the ovn-bgp-agent works and how the traffic gets routed to the nodes (through BGP) and then redirected to the OVN overlay by leveraging kernel routing (more information about the traffic flow details here). Once the traffic reaches the node where the VM is, the kernel is in charge of redirecting the traffic to the OVN overlay by using a: Set of ip rules to enforce using the routing table created for the...

• 1 Oct, 2021

  OVN BGP Agent: Interconnecting Kubernetes pods and OpenStack tenant VMs with EVPN

  In a previous blog post I presented the OVN-BGP-Agent and its EVPN capabilities. Now we are going to use it to showcase how it can be leveraged to provide connectivity in a multicloud environment without the needs for floating IPs. Note the agent codebase was moved from my personal github account to an upstream opendev project: https://opendev.org/x/ovn-bgp-agent Multi Cloud Environment The environment is composed of 2 OpenStack environments. The main objective is to test the tenant to tenant multicloud connectivity...

• 25 Jun, 2021

  OpenStack Networking with EVPN

  This is a continuation of the previous blog post series regarding OpenStack Networking with BGP. Now we are covering the multitenancy aspects by using BGP in conjunction with EVPN/VXLAN. One of the main use cases for this is allowing connectivity between tenants/VMs running on different edges/clouds – on top of OpenStack or not. EVPN at OVN BGP Agent In order to add support for EVPN, we have extended the functionality of the OVN-BGP Agent, with a different “mode” for EVPN....

• 4 Feb, 2021

  OVN-BGP Agent: Testing Setup

  The basis of the OVN-BGP Agent was explained in a previous blog post. This blog post will cover how to set up a testing environment where you can play with the OVN-BGP Agent. The physical topology consists of a spine-leaf architecture where each server has Layer-2 connectivity to the leafs on the rack they are connected to. BGP will be running on the fabric, i.e. servers, leafs and spines. Each server will be connected to two leafs for both high...

• 4 Feb, 2021

  OVN BGP AGENT: In-depth traffic flow inspection

  In the initial_blog post we explained how the OVN-BGP agent works, and in the follow up blog post we explained how to set up a testing environment. Now we make use of that environment to check that the connectivity works and how the traffic gets redirected with the several rules/routes that the OVN-BGP Agent creates. By default, devstack already creates a public shared provider network, as well as a private one. So, let’s reuse the public one for creating the...

• 4 Feb, 2021

  OpenStack Networking With BGP

  With the increment of virtualized/containerized workloads it is becoming more and more common to use pure layer-3 Spine and Leaf network deployments at datacenters. There are several benefits of this, such as reduced complexity at scale, reduced failures domains, limiting broadcast traffic, among others. The goal of this blogpost is to present the ongoing effort to develop a new agent in charge of exposing OpenStack VMs through BGP on an OVN based deployment. The connectivity between the OpenStack controller/compute nodes...

• 31 May, 2018

  Superfluidity H2020 EU Project: One network to rule them all!

  The SUPERFLUIDITY project was a 33 months European (H2020) research project (July 2015 - April 2018) aimed at achieving superfluidity on the Internet: the ability to instantiate services on-the-fly, run them anywhere in the network (core, aggregation, edge) and shift them transparently to different locations. The project especially focused on 5G networks, and tried to go one step further into the virtualization and orchestration of different network elements, including radio and network processing components, such as BBUs, EPCs, P-GW, S-GW,...

• 25 May, 2018

  Deploying OpenShift with Kuryr on a DevStack multi node environment

  In this post I will describe the steps I followed to be able to install (with openshift-ansible playbooks), test and play with an OpenShift deployment with Kuryr SDN on top of a developer OpenStack environment built using a DevStack multi node running on 3 VMs. I will cover the next steps: Creation of the 3 VMs Installation of the Controller Devstack node (it will also be used as worker node) Installation of the Compute Devstack nodes Creation of needed resources...

• 19 May, 2017

  OpenShift with Kuryr on top of OpenStack VMs: step by step set up

  As motivated in previous blog posts (Superfluidity series) there is a need to handle both containers and VMs at the Edge Clouds. There are several reasons to do so, among others: VMs are more secure than containers, but containers are faster to boot up and quick reaction is needed at the edge, but so is multi-tenancy. Not all the applications can be containerized, definitely not at the same time; the hardware resources at the edge are more limited than at...

• 9 May, 2017

  Kuryr Ports Pool: Speeding up containers booting time on Neutron networks

  As described in the previous blog post series: Superfluidity: Containers and VMs in the Mobile Network, kuryr enables both side-by-side and nested kubernetes and OpenStack deployments, where containers can be created and connected to Neutron networks either on baremetal hosts or inside OpenStack VMs. One of the main advantages that containers offer over VMs is that they boot up faster. However, when containers are connected to Neutron networks through Kuryr, the communication between the Kuryr controller and the Neutron server...

• 29 Jan, 2017

  Side-by-side and nested Kubernetes and OpenStack deployment with Kuryr

  Kuryr enables both side by side Kubernetes and OpenStack deployments, as well as nested ones where Kubernetes is installed inside OpenStack VMs. As highlighted in previous posts, there is nothing that precludes having a hybrid deployment, i.e., both side by side and nested containers at the same time. Thanks to Kuryr, a higher flexibility for the deployment is achieved, enabling diverse use cases where containers, regardless they are deployed bare metal or inside VMs, are in the same Neutron network as other...

• 24 Jan, 2017

  Superfluidity: Containers and VMs deployment for the Mobile Network (Part 2)

  Once we have the ‘glue’ between VMs and containers as presented in the previous blog post, an important decision is what type of deployment is most suitable for each use case. Some applications (MEC Apps) or Virtual Network Functions (VNFs) may need really fast scaling or spawn responses and require therefore to be run directly on bare metal deployments. In this case, they will run inside containers to take the advantage of their easy portability and the life cycle management, unlike...

• 16 Jan, 2017

  Superfluidity: Containers and VMs in the Mobile Network (Part 1)

  Among other things, we, at the Superfluidity EU Project (http://superfluidity.eu/), are looking into different deployment models to enable an efficient network resource management in the mobile network. This post describes our findings and focuses on the Mobile Edge Computing (MEC) use case, as well as the technology project, called Kuryr, which enables it. What is the Superfluidity EU Project about? First, we will introduce the Superfluidity EU project and its main objectives. Superfluidity, as used in physics, is “a state in...