Thank you, let's welcome Francesco on the present and future of the app.
Okay, thanks everyone. This session is about Obestac and self-integration.
With our quick glance to the Kubernetes world, it is a quick agenda.
I'm going to talk about what would have been the integration with SAF in the Obestac system,
in the Obestac community in general, what's the status of the app,
what has been changed with the SAFADM in the Bermedal world and what means having Kubernetes in this picture.
There is also a demo which is, I'm not going to show the demo, but it's linked in the session,
so you can feel free to take it later.
So, for reasons not familiar with the Obestac project, it's just pretty old at this point.
It's infrastructure as a service.
As you can see on the right side, there are a lot of projects being part of the Obestac ecosystem.
Each of them provide interfaces to each other and they cooperate together to provide processing, storage, network resources.
You basically can build your cloud infrastructure using all these projects together.
It's open source, it's now 10 years, 13 years old, so there are a lot of projects that are stable now.
And SAF is part of this picture in the sense that you can probably don't see this picture very well,
but in both computes, in the storage part, we have SAF that basically can be used as a backend
for NOVA, which is the compute processing component, so we can provide ephemeral disks using SAF as a backend.
We have Manila providing object, there is a good providing file.
Swift providing object, there is a long story with the integration with Radus Gateway.
Glance for images, so basically all these components you see there in the storage area,
they can use SAF as a backend and this is a justification to have this integration with these two technologies.
So, why the integration and why it's relevant?
There is the HCI, I will convert the infrastructures.
Operators can save hardware resources, co-locating the compute part of the infrastructure and OSD nodes.
This means that you can save hardware, you can have both technologies together serving as a full operational infrastructure.
This is funny, I just asked chat GPT, why SAF is relevant and why the integration of these two projects is interesting.
I just put there, you can not see probably this part on the right, but it's basically my marketing sentence on why this thing makes sense.
And there is scalability, resiliency, scalability and all this kind of keywords that we like a lot.
But this session is about orchestrating services, deploying object stack and SAF together.
There have been a lot of deployment tools and strategies over the past and I want just to focus on Cefantibol and Cefadm
because Cefantibol has been the official tool, the most useful tool in the past and now it's FADM.
Things have changed a bit, especially in the object stack ecosystem.
So, previously the approach was I need my infrastructure as a service, I need to deploy object stack and SAF.
I want to describe my entire cluster with a lot, a ton of variables and I push that magic button that makes it so.
So, Cefantibol was there in this picture during the deploying of object stack.
There was this particular part where Cefantibol was triggered to deploy SAF behind the scene.
So, the drawback of the solution is that if you need to change anything in your Cef cluster, you have to run again the playbook,
the Cefantibol playbook, because there is this Ansible layer that manage everything for you and it needs to stay consistent with the status of the cluster.
So, basically variables and the human operator is supposed to provide variables and maintain those variables, which is a bit different.
Also, it affects scale down, scale up operation and day-to-operation, especially day-to-operation.
I want to change something in my Cef cluster, I need to run the deployment again because I can rely on the Ansible hidden potency, basically.
But with CefADM things are a bit different, the status of the cluster is not made by tons of Ansible variables.
There is CefADM, which is able to keep the status of the cluster, watch the cluster and take an action.
I want to deploy a new SD whenever I attach a new disk.
I can do that and I don't have to run deployment again or do any fancy day-to-operation with my tool that is supposed to manage my infrastructure in general,
which is made by both Opestuck and Cef.
And this changes a bit because we had the Cefantibol word where we describe all our cloud infrastructure.
We pushed that magic button and everything was deployed and sometimes broken.
But now, operators are more aware about the steps, so things have changed because you have to provide networks.
And networks means that you want to manage your hardware, you want to build your networks, you want to use...
This is specifically for the triple project where we integrated Cefantibol in the past and now we're moving to CefADM.
And now people should provide networks, should provide metal, the description of the nodes and they are just separated steps.
The storage Cef is deployed first, so you can start deploying the Opestuck infrastructure with a minimal Cef cluster already deployed.
And when you deploy Opestuck, you can say, I have Cinder, I need Volumes, I need the Volumes pool and I can finalize my cluster,
creating and configuring the Cef cluster accordingly.
I have Manila, I need CefFS, I can deploy MDS, doing other stuff behind the scene.
But you're basically aware that according to the service you're deploying in your Opestuck infrastructure, you can enable pieces in your Cef cluster and you can just tune it accordingly.
At that point, we still have the Ansible layer managing Opestuck and all the infrastructure in general, but at that point the Cef cluster is seen as a separated entity.
So it's like having an external Cef cluster, even though you have the same tool deploying both technologies together.
And CefADM and the manager, the orchestrator, is the piece in Cef that is supposed to provide interfaces where the operators can interact with.
And it's basically the slide. We still have Ansible doing everything on top, but the orchestrator interface is what you can rely on to make changes in your cluster
without having to redeploy everything again around the Ansible that can take a lot of time if your infrastructure is large.
And we don't have any, the operator is not supposed to keep and maintain any variable in the Ansible system.
You can just interact with the CefADM CLI, create a spec which is a little definition of the Cef service that will be translated by the orchestrator and it will be deployed as a new demon in the Cef cluster.
So this is about why it's so easy. Because you have Ansible, at some point you can just bootstrap a minimal Cef cluster with this command,
bootstrap, providing a monitor IP address because networks are already there at that stage.
And you can create a spec file that is basically the description of the nodes that should be enrolled in Cef and you can just apply them.
It's even easier rather than running Ansible with a lot of roles, execution time, which is long enough.
And data operation are complicated.
Are complicated because not just because of this slide and this is the interaction with the CefADM CLI, you can query the cluster and see the health status.
You can see where demons are placed, you can list the hosts and manage their labels and assign roles to these hosts.
You can do a lot of things.
But the real point here is that with CefADM we don't have the need to run again all the deployment of the Opesta infrastructure.
An example of this, of how projects are impacted by this change is Manila.
It's not just because we need a new version of LibreVD, we need to be compatible and we are changing from CefAnsible to CefADM,
but just because we are doing architectural changes to the use cases provided by Opesta.
Manila is that service that curves out CefFS volumes and provides them to the virtual machine within tenants,
which means that you have a dedicated network that you can use to mount your shares.
And behind the scene we have CefFS or NFS with Ganesha.
In the past, Manila was supposed to use the bus to interact with NFS Ganesha.
And it was complicated because we had to run privileged containers.
We had to use this interface to update and manage shares using Ganesha as a gateway.
And from an architectural point of view, we had an active passive model made by Peacemaker and SystemD.
So you basically had Peacemaker honing the virtual IP as an entry point and then one active Ganesha,
even though you have more than one instance.
And with some constraints with SystemD.
Now with CefADM there is an interface with the manager, with the NFS cluster,
and Manila can use a new driver to interact with this component.
We don't have to do the bus anymore, we don't have to do the bus to the Ganesha container anymore.
And that's the new model where we rely on the Ingress Demon provided by CefADM,
and this Ingress Demon is made by HAProxy and KIPaLiveD.
KIPaLiveD honing the V as an entry point, HAProxy for load balancing across the,
and distributing the load across the NFS Ganesha server.
It's a better approach, we still have some limitation on this area,
because considering that Manila is an infrastructure service for Obestac,
but providing shares within the tenant, virtual machines, with a dedicated network,
we need client restrictions to avoid other tenants mounting the same share.
And there is an effort doing the proxy protocol in Ganesha to make sure that we can
use client restriction with this new model, which is the current limitation basically.
Or at least there is some effort to provide floating stable IP addresses to the Ingress Demon
and skip the HAProxy layer, which is always an additional hope.
And in terms of performance, this can be something that has an impact, of course.
Lastly, at this point we had Cefansible, we have CefADM, what Kubernetes means in this world.
We have Rook as a way to deploy Cef within Kubernetes, regardless of how Obestac is deployed,
we have several combinations of these two things together.
You can have converged infrastructure where Obestac control plane is virtualized,
or it can be containerized, so basically using the same model,
the same approach to deploy both, it can be useful,
because it's a unified approach to manage your infrastructure.
It's easy, deployable and reproducible, because Kubernetes poses a standard approach to deploy things,
so we don't have anymore that flexibility that today is triple O, but it's easier from that point of view.
And the same Cef cluster can be shared between Obestac and Kubernetes.
We have different workloads.
Kubernetes is PVC interfaces provided by Rook. Obestac is mostly RBD and your workload runs virtual machines,
and it's usually outside, so you have to reach from the compute node the Rook cluster,
the Cef cluster deployed by Rook within Kubernetes,
which poses some networking challenges that they can be managed using host networking through,
so you're using Kubernetes as a platform to deploy your Cef cluster,
but you're still relying on the host networking to reach it and provide RBD to the outside workload,
and that's the point of this slide.
There are some things that are not mentioned here, like some tuning in Rook,
that is supposed to be done to make sure that there is Kubernetes in the middle,
so it's not natively, the native Cef cluster we usually have.
So at this point, the thing is that we should do some tuning, especially in the HCI world,
because Iverconverged is still one of the most popular use cases,
and HCI is provided out of the box by Kubernetes.
You can tag your infra nodes, you can deploy Rook, you can assign those nodes for OSDs.
That's it, that's it.
But at that point, you have to make sure that both your cluster and the connection is valuable for the outside workload.
So this can be done, it's done by this demo.
I'm not going to show this, but it's all there, it's all described,
it's all I was describing in this slide.
So you can have your OB-STAC infrastructure deployed with DevStack or TripleO,
and it's still bare metal, and it can consume a Cef cluster deployed by Rook using RBD.
You can still use the CSI, actually, to provide PVC interface.
It's not something that it's mutually exclusive, but it's just a good exercise to see how these two technologies can work together in the future, probably.
And yeah, just some additional resources for those interested in looking at these slides offline and some contacts for people in the OB-STAC world
if you want to dig more into these experiments.
And that's it. Thank you very much.