 Yeah, of course time, I think management is the first time to talk about this. I tried to do something, but it's good. These are good words to learn. Alright, thank you for coming. Can I have your attention? Hello? Peace and quiet, yes. Next up, we have Alexandre. We're talking about a conflict management tool called Rutter, and I'll leave him to it. Thank you. Hi, thank you. Welcome here. I'm very happy to make my first talk here on FOSDEM. It's also my first time at the FOSDEM, so I hope that you will enjoy my talk. In fact, I will talk a little bit about Rutter because I know that, I will talk about configuration, proof, compliancy, and because I work for Rutter, of course, I will talk a little bit about Rutter, but there is no demo stuff, no technical too much. It's more about concepts, about configuration, but why concepts? It's very simple. In fact, when we talk about servers, each other, we always thinking about, yeah, I make new things into Rutter, with my systems, and I make new things, and sometimes you have some type of this question, so how are your servers doing? Are they okay? Is it okay? And can you prove it? Because automation right now is most often used for being more speed up, to speed up their system deployment, and so we want to deploy very fast, and so we make automation for that. But firstly, configuration management, if you take back to the origin, it's more about consistency of your systems during time. So it's not always about automation for being more and more speedy, and to reduce your time to market by deploying your new configuration and others. Of course, this is the most used function of configuration management. But when you talk about consistency, then you can understand that there is other things that just automate for automates. So you want to accelerate application, okay, like CI and CD. They were used to do that. Firstly, also by automate. Many things to make it feedback looks very shorter, but because of that, why you are trusting this CI CD chain too is because you have the measures, and so you can know that what you are doing is okay because it's very quick that when you have any failure on your CI CD systems, you're just doomed very quickly. And so if we came back to the DevOps approach and philosophy, you've got the Tom's pillars. And so basically, with configuration management, you've got the automation part. This is classical. We always do that to make less time to do some stuff that we don't want to do. But also, we are talking about measurement because if you do automation without knowledge about where you are going to, without any visibility, so because of that, you cannot know if your automation is right or not, or maybe it's too late to know that. And so when I talk about measurement, in fact, there is a word right now that's very busy word. It's called observability. There is some time now that we talk about this in monitoring systems and why we don't talk about this in configuration management? Because in fact, we are doing the same and why we should need observability in configuration management? Because of the proof, of course. But all we can be sure about what we are talking about. So firstly, it's about causality. If you can trust in your... Can you prove your configuration state? It's because you already know where you come from and where you are. And so if you are not know... You don't have this knowledge, so you don't know the causality, so you cannot know the root problem, your root incident. And it gives you some perspectives because observability, if you don't know that, it's more about making some properties very basic, technical and factual. And with these measures, you can make it... You can appropriate yourself these measures to share with your team and so you can make different perspectives because you got insight directly from the internal systems. And because of that, it makes you agency. This is another buzzword right now and agency is because you can help people to do things with your systems. Because of what? Because of the observability. Because you are giving an insight that they cannot have before that. So I will talk... I am Alexandre Brionceau, so I'm from France. I work for Rother, the configuration management system. So we make configuration basically an audit for six years now. Whereas the only tool, the European tool. So if you don't know how Rother works, you can just grab Google and or print this. It's better for your privacy. And most of my talk will talk about Rother, but it's more conceptual, so it should be very great if you can just make a perspective with your own usage, with your own tool. So Rother, Solve, or MGMT maybe. For James, just a previous talk. What we do in configuration management? Basically, we have a target of a configuration. It's not scripts. It's a target of a configuration. You want that your package is present. You don't want to install a package. You just want it present on your systems. So you have a target state. And because of this target state, you have a configuration to apply. And when it will be applied, you've got feedback. Is it applied or not? Because most of the time you use configuration management to manage multiple nodes. So we call nodes your machines you manage with Rother. So you've got many configurations. And most of the time you're doing something to normalize your systems. And so you've only one configuration target state that will be deployed and processed and the main configuration is needed. And of course you have different feedbacks from your different nodes that are applying this configuration. But observability, as I told you, is about making some internal statements or like a property. And so you can grab it and manage it through an external output. So how we can do that and what's the difference with monitoring systems? If you're looking that... I told you that so you have your configuration statements, you've got your configuration file basically, and after you've got your feedbacks. When you have a monitoring approach so you can know what your target state and you can have, okay, it's green, my job is okay or my configuration is normally applied. So it's like monitoring approach. You know the beginning, you know the end, but you don't know what is in the black box. With an observability approach, the main objective is to have a very fine-grained approach of any thing that's happening in your system so you can know the causality. Is it purple because of the first step or the second step? So now you know that it's the first step. Is it this form because of the second step? And so you can know this only with an observability approach. To have this observability approach, you need to go deep inside your code in your systems. So we are very, very lucky with Rutter as our configuration management was the main purpose, it was for compliancy. So we don't want to make automation simple only like that because many know Rutter because of his web UI but also because we wanted to make it compliant. And so because of this compliancy, we dig into this whole very deeply and we make observability deep inside our management system. So what I'm going to do now, sorry for the, I think it's the edge, do you know it? Not better. Okay, so basically I will present you how we manage this in Rutter systems. So with the Rutter systems, with the Rutter approach sort of, but also it's concept, so you can manage it how you like. You've got people that making stuff in your systems to define a target state. So this is the first step that we want to is defining our configuration. How we do that in Rutter, we call that directive, it's such as configuration basically. So we've got configuration, we don't know what the purpose of this configuration as a business view. We have some just small blocks like managing a packet or managing a line into a configuration file or something like that. It's very small blocks and because of these small blocks don't have any purpose like business view, it's maybe it's for security compliance or maybe it's for your Apache systems. We make rule. So rule is a set of many directives and because you have to apply your configuration to something, a rule is a sum up of directives and a group of nodes. Because of that, you have a whole system that is defined to define your configuration. So you've got configuration you want to apply, you've got group of nodes that you want to apply, so you've got a rule and you have to stick to this rule. Like I told you before, maybe you want to normalize some stuff. So you can have some parameters or variables that you want to define but it should be specific to each group you want to manage. So you also have parameters and this is all that you can set up at each rule you want to apply with further. But it's not sufficient because you also have more globally systems, variables and parameters. So you have to take this into account. We call that environmental context. It's like your global parameters of rudder. For example, with rudder you can work in compliance mode or with remediation. We call that enforce mode. So you have an automatic remediation like all the configuration management tools that have this such functionality, of course. But we also have the audit mode and this is in the same program. So you can set up a global policy mode to audit and so all your nodes will be only in audit mode. But also you can define it per node. So this is why, for example, you've got the policy mode global and one is for node because sometimes you want your more critical systems for Christmas. For example, if you're a vendor, if you're Amazon, such as. So you want this node doesn't move anymore for a freeze period of one week, for example. So all of that are authorized and all of that are set up. So in fact, in our rudder we use a change... So we have a change request for each modification we can have here. In fact, this first group can be called as the name of external events. It's all external modification of your configuration. It's because all of that is due to users even if it's technical or business because maybe it's your manager that wants a new rule for his security compliance or your security team that wants to use them. And so because of that, it could be also an appliance or any other system that use the API to make the configuration change. So every change that could happen even if it's the API or the CLI or the web UI, it's finished in the end on the change request. With that, all the system that defines a configuration is registered and is the right. And so we have a compliance is the right. At least we have the beginning of the compliance. Because after, I'm very sorry about what's... You will get grabbed the slide later. So the second part is about processing the configuration target state. So we have our target state defined, and so we know and we can prove what we want it firstly to do. But after, there is all the magic of the system that making each file to each node because each node we have his own system, his own configuration file. So each one is generated for each node with a special ID and is the right, of course. Also, you can have some external file because you want to use some ginger to templates or mustache templates or any external file like a war or anything that you want to put into your servers. And so all is the rise also in rather. But this is totally automatic. So you cannot change anything. External manipulation and action were just at the upper downer. It's only about automatic change. And so because it's automatic, and we exactly know what it will be applied to this node. So we can predict and have expected reports. As I told you, at the end we have got feedback. And so before to have this feedback, this real feedback, we can have a predictive feedback because we already know what was before, what will be, and so we can anticipate this and have an expected report of is it normal that I have my feedback or not. So this is on the rudder root servers, so the main servers, and this is on the agent. And the agent will get the config basically and after getting this config, it will apply the configuration. And next we have a report to the feedback. And because of that, this last part will compare both. So due to these systems, you can know if there is any problem during your generation, or it was directly by someone that makes a mistake when you make the configuration, or maybe it's the node that don't have the last version of the configuration, for example, or if there is any change because there is a man in the middle that will attack here and he wants to change the report and believe you that the configuration is okay and if it's not. So all is just arrived and compared. And so because of that, you can grab the causality and just be to the business level, to the tech level and knowing exactly why your configuration is not okay. All is signed and with an integrity because of that. So it's normal. I think I will be in time even more quickly. So it's okay. This is globally how we manage that. So we have the first part as a definition of the target state. As I told you, we manage all the objects that define your configuration. So because of that, we know that all the external influence to the configuration and what was the purpose of that. The second one was the configuration creation. Basically the file that will be applied by the system. Because of that, we trace everything and we can predict what's happening. And so when the agent, because it's agent-based, if you don't know that, most of the configuration management is agent. And so do I and do I. After the execution, we have all the feedback and we can compare between our expectation and what was really done. So this is the third major category that we could find. But it missed one. It missed directly on the nodes. In fact, when the servers are making the configuration up, so I said, okay, we can have the feedback, but we only have the feedback. What's about the own observability of the agent itself? Rutter is based on PowerShell DSC for the Microsoft part and on CF Engine for all the Linux and Unix part. And because of that, the observability is not well as it should be done to have the exact observability and the causality of why there is a configuration that is not okay or not. This is something that we want to enhance. Like for example, just a previous talk, it was about MGMT, so MGMT is more efficient on this part of observability system. And so maybe why not move on to this agent. Also, observability should be completely agnostic. We cannot presume about the purpose of what we measure. Of course, we can have some KPI after that because of the measurement that we do, but observability basically just are properties, factual properties. And so because of the numbers and figures, you can make any sense of this matrix. And this is the major advantage of observability and this is why observability should be largely used into configuration management software. Because of that, you can make any orientation of your measurement. So as I show you, it was on three different levels from the more technical to the more business side. And because of the observability, you can make anything you want to making some meaning about your measures. For example, Inwerder, I told you that Git was used to make PR at each change. So we can make a change validation request. And so even if it's in interns or because you're working on very critical systems, you want to make a validation before it's applied. Or you can make rollback to your systems due to this measurement and your historization of anything. Or we have some users that are using Rutter to help them to their audit like PCI DSS or BS security stuff or CIS. And so because of this proof, it's more easy for them because they can find causality of any change that was not prepared and anticipated. But it's not sufficient. For now, we have more as we can say that very agnostic stuff but for our own stuff. What we need to do is to be normalized with a protocol that could be used like for tracing and other external processors that could process our measurement because we cannot presume of any business usage of Rutter for that. And in Rutter, we use this for some features but also we use this for dashboards, global dashboarding. This is one of the major features of Rutter is when you automate some stuff. So you've got the rules like business-oriented vision of your configuration and you can know the compliance of your role. So you can know that only 83% is okay as compliant to your configuration statement. So this is the first level of external usage of observability. But there is some others. If you have a protocol normalization then you can have data mining because you can use Kafka and others to make data mining to your data. So you can have some prediction to what's happening in the next few months, for example, or next few hours or next minutes. It depends on when you're expecting something. And because of that, you can grab to a next level to predict. So I'm pretty sure that you already know IBM with his AI systems. But for now they're trying to dig something without the proper tool to manage their observability systems to make this prediction. So we hope to participate to this approach by making really objective and factual observation to your systems from internal states using data mining and after using AI to predict what change should be happening in the next few time. It's finished for me. I hope that you enjoyed the talk. I'm available to discuss with you maybe about proof maybe about also observability in configuration management. It's very quick because there is a lot of talks that happening in the configuration management camp that during Monday, Tuesday and Wednesday. So I will be very pleased to talk with you over there or here if you have any time. Thank you. Maybe there is some question or something like that. If anybody has a question, I don't think so. I don't see any.