 OK, hi, everyone. Sorry for the delay. I visited the wrong stage. They changed something in the program. And yeah, I wasn't aware that I'm here. Yeah, so this talk is about, initially, it was about intent-based holistic data center management. And I had this talk in Frankfurt at the Cloud Expo, and then I renamed it a little bit. And it's more at the moment about intent-based infrastructure management with a focus on data centers. It's the target to manage full data centers in the future. But we are not yet there at the moment. So my name is Christian Bernd. I'm working with OpenStack for over 10 years. So I started with the second release, with an production deployment for SAP. And then I founded the OSISM company five years ago. And so we are OpenStack experts here from Germany. And at the moment, we are heavily focused on the Soren CloudStack project here in Europe to help Europe to gain on Soren CloudStack based on OpenStack and Kubernetes and so on. And the OSISM is a fundamental part of this stack for the reference implementation. So what's the problem we try to solve? So normally, you start with a new OpenStack environment on a green field. And you build something where you think it's a good idea to build it this way. And so you normally do not ask a lot of other people. You just do something that makes sense for the current requirement at the current time. But the problem is that the requirements will change over the time. And you have an infrastructure. So this is the infrastructure, this legal counsel. And this is your starting point. And then you have changes in the requirements. You have a new hardware type. You have new GPUs, or you have GPUs, or a new switch vendor, or a new data center, or so something changes. And one of the changes could be a scale up of the environment, new hardware is coming in, or a scale down. You have to remove some hardware. And the environment will change. And there is something called a flexibility corridor. So it's not a big deal to change smaller pieces of an environment. So you can scale it, or you can add a new service, or you can remove in service. But you have a problem. When you want to transform the whole environment to something totally different, so you want to rebuild the castle, you have your Lego pricks, and you want to rebuild them, you want to transform them after maybe three years. Because your base infrastructure layer changed from OpenStack to something else. And this is the problem that you then have to do this transformation of your existing infrastructure to another time frame, with another flexibility corridor, and then you have to change it another thing. And to be able to enable this, you have to master the scale, the flexibility, and the transformation of the underlying base infrastructure. And so what is required to be able to do this? You need a data center. Yeah, so we are focusing on Cloud Service Providers. So this is the data center from Hetzner in Falkenstein. And you need physical resources. So in the end, we always consume compute resources, storage resources, network resources. This never changed in the past. It was only a little bit different. But in the end, we always have those three types of resources. And then a good decade passed. We invented OpenStack, and we established a good infrastructure as a service layer to abstract the underlying physical resources with virtualization. Then we have Kubernetes today to abstract the infrastructure as a service layer, using Kubernetes as a service layer to be able to consume Kubernetes. We have something as a service, as in addition to the Kubernetes as a service, for example, database as a service, or messaging as a service, or as free storage as a service. And on top of this, we can run our Cloud-native workload today. And this is required to also be able to transform the underlying physical resources. So in order to enable the high dynamics on the workload, you have to build a long-term, reliable infrastructure with a high quality that does not change every then and then. So what we want to achieve is we want to have a railway as an infrastructure layer where you can build your Cloud-native workload on top of it and where you can change small pieces or can rebuild everything, but so that you do not have to rethink everything every day. And we started to implement this five years ago with our own Cloud. So the company has another name before, and we wanted to build an public Cloud. And we thought this is super easy. And yeah, it's not so easy. And then we invented this deployment framework and it's based on color and color and self-enabled and some other tools. And we started to use this tool for our own environment. There's a unique, not one-time engineer, but very unique. And yeah, this is good. It worked, but it's pretty bad for other customers. So then some other customers came and asked us to build on-premise something like our Cloud. And yeah, it was a nightmare in the end. And so what you have to do is you have to standardize the components. They have to be changeable and scalable and repeatable and understandable. This is really important. And you have to be able to integrate them with layers atop of them on the button. And when you have such an approach, then you can simply change the underlying components and can build something totally different from the same pricks. And yeah, to do this, we started with our physical resources and with pricks or components and plan what to do with the pricks. And then we decided to just use the ironic service as one part to manage the physical bare metal resources, to make the firmware management, to make burn intests and cleanups and so on. And we wrote something in Python so that we are able to manage network resources so that we can deploy configurations on any switch type. We can make the switch configuration. So we simply log in by SSH and we generate the whole configuration based on a state in the net box. And then we can control this via Ansible. And we can deploy them on the compute or storage resources. For example, an OpenStack cluster or in SIF cluster or in VMWare cluster or in Proxmox cluster. You can also mix them so that you can have one bare metal control plane for all physical resources in the data center. And then you can decide what you want to build with those physical resources. And this is the OSISM framework. So this means open source infrastructure and service manager. So a short term is OSISM. And this is simply consuming a net box as a single point of truth. And in this net box, we have the current state that is deployed on the physical environment. So the connections to the switches and what is deployed on a system and so on and so on. The current power state, is it already deployed or not? Is it in a good state or in a bad state? Do we have to apply another firmware and so on? So the whole live state lives in the net box. But the net box is, in the end, just in representation of what we have on the physical layer. And we consume it as an API layer. So this is not the point, so the single source of truth. So we make a difference there. We have a single point of truth on API layer for the view on the physical layer. And we have a source of truth, which is based on Git. So we have everything in a Git repository. We have a representation of the possible states of the physical resources. And then we say, ah, we want to have this state. This is applied by the OSISM framework. And then the current state is stored in the net box. And then we deploy everything on the bottom layer. And this way we can establish and Git ops workflow. So we can just push our descriptions or our configurations to the Git. And then the mechanism will take care of the new state. And this is what we are meaning with intent-based infrastructure management. So we have our resources. And we just say this system should be in Compute node in an OpenStack cluster. And then the system will take care of this and will transfer the physical resource to Compute node and will add it to the OpenStack cluster, for example. And this way, so this is now our environment. And to be able to be safe in the future, you have to transform your underlying infrastructure resources to something else. So today, we deploy our infrastructure with OpenStack. In the future, we maybe deploy it with Kubernetes. And then we will maybe deploy it with an serverless framework. But we thought it's a good idea to not think every single day about what could be the technology in the next day. We just want to be able to have our data center infrastructure resources. And we want to have a framework for the next decades that can just transform our underlying infrastructure to something else. And we do not want to reinvent the wheel every single day. So we do not want to think about how to resolve node firmware management, for example, in Kubernetes. We can resolve it with an OpenStack layer. This works with ironic. This works pretty good. So we think this is not necessary to change the next 10 years or so. And to do this, we have our GitHub's workflow. So when we want to do a transformation, we say in the configuration repository data and system should change. And be committed to the OS-ISM framework. And the OS-ISM framework will move the new required state in the NetBox and will then say to ironic, ah, you have to do something. And then the price and ansible part will take care of it. So it will remove the existing system from the compute cluster, will deploy something different on it. Maybe it will clean up the system. And when it's finished, it talks back to the NetBox and says, ah, here is the new state. We are finished now. And then it's always checking if the current state is reached. And this way, you can simply transform your data center resources in something else. Yeah. How does it in too much in detail? So this is the current framework. So we have on the bottom a lot of repositories for the current state, the inventory, the configuration repository. And we have some external services like ticket service where we store our state and so on. And we have external registries for the container images or for the packages we want to deploy on the resources. Then we have an OpenStack, what is just an ironic bare metal control plane, which can communicate with the out of band management interfaces. And then we can deploy on this at the moment compute nodes for OpenStack or storage nodes for SEV. Or we can deploy resource nodes, of course, for customers where we can then add and proc smokes on the Ember or something else. And we can also control the network resources. So when we say a compute node should be in this cluster, then the network configuration for the switch is generated on the state of the system. And we can just push out the network configuration. One of the things we want to archive is that we have a central change management. So we decided to not use Kubernetes as the base layer for OpenStack, because we think the infrastructure layer should be rock solid. So we do not want to have something there what makes dynamic changes. So we only want, when we haven't changed, we make a pull request or a git repository, we approve it, we merge it, and then the framework will do something. But we do not want to have self-healing or stuff like this. This can work when you have a bigger team or so, but we are focusing on, for example, supercomputers or for some critical infrastructure, where we think it's better when the infrastructure is in a state where we know this is the current state and exactly this is the state. And to be able to make this possible, we have a GitOps workflow based on then Ansible and container images based on Collinezible and self-ansible and we just deploy everything and then everything is fine and we do not touch it. And when it does not work, we have to heal it on ourself. So we have monitoring around and we have operators, but we think this is better for the infrastructure layer. And then we have a central secret management to be able to rotate the secrets in the infrastructure and we have a teleport. So it's what's boundary before and now we have teleport to access the deployed systems for the actual, so for the operators in this case. And of course, we expose some interfaces and APIs and data exchanges. So data exchange is for example, from a source for the metrics or exposed APIs is done for the Ansible or for the OSIS itself. Exposed interfaces is the rapid MQ management interface or the internal horizon dashboard or some other internal admin interfaces. So for the actor that they can access the infrastructure environment. Yeah, of course, who not? And yeah, so this is a way to get in contact with us and yeah, that's it, if you have questions. So the net box is an internal component which we use to represent the internal state. So we do not plan to have too much details in the net box because most of our customers already have a data center management tool or an asset management tool and so on and so on. So it should just be the source of the single point of truth for the internal state of the machine. And so we have integrated the Python layer and that's it. And we generate, for example, the Ansible inventory in something static and stored in a Git repository. And so we do not use some dynamic block ins that connect to the net box. Everything is static and stored in a Git repository in the end so that you can have a review of it, you can audit it and so on. Now everything is static. So we do a full description of what we expect to have in the net box. So the net box is in the end just a few on the state that is stored in the single point of truth. It's just a tool. So we do not want to make changes via the net box. So when you want to change an IP address, for example, from system, you make this change in the source of truth and the Git repository and then we will change the IP in the net box based on the state in the repository. And the net box is just there to have an API for our YAML files. Yes. So we fetch the current state from the net box and we generate then an Ansible inventory and then we use this Ansible inventory to identify changes. Yes. But only the current states. Yeah, exactly. So it depends if it is Ansible or Pison to access these switches. So for example, we implemented it for Microtik devices and there it's not so easy because it's not an enterprise switch and they have not a diff feature. So you have to calculate the diff yourself and have to apply the comments yourself on the switch and for example, there we use Pison to access the switch but for other switches we can use the Ansible modules for it and can just use an Ansible playbook that's generated. And this configuration that's generated is also stored in the Git repository so that you can add there and change management that somebody from the network operation team can have a look first on the network and we plan to integrate there, for example, a bed fish to validate the network configuration before we deploy it to the network switches so that we can pre-validate them and that they really work and it's not broken. Okay, so thank you for your time and enjoy the evening. Thank you.