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...
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...
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.
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...
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...
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...
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...
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...
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...
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....
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...
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...
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...
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,...
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...
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...
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...
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...
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...
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...