 It's great. I saw that at the other day, I'm like, what is this new software? Leave me off, this doesn't work. What the fuck is that? Okay, everybody, Marcus Raffer, the Electra project, coming to us about Electra and its relationship to Puppet. Thank you. So, thank you for your introduction. So, I will start right off with two questions. First, who has heard the talk yesterday about Electra? Is there someone? Okay, there are quite some. Thank you. And who has heard of Electra before this talk yesterday? Is there also someone? Okay. Oh, there actually are. Oh, perfect. Okay. So, yeah, I will directly dive in. So, as you all know, reliable editing of configuration files is not so easy or not always so easy. And this is not only a problem which is faced by configuration management, but is also a problem faced by applications themselves. In the moment they want to do integration and access other configuration files, they have basically the same problem as configuration management has. The focus of Electra is wider than only to be used by configuration management because of this, but in this talk, configuration management will be the main focus. So, yeah, as you heard in the talk before, for example, OGEAS cannot access some files like YAML. And, yeah, and as you know, there are many incompatibilities between the different platforms. So, the idea and the long-term goal of Electra is to integrate the technologies as there are. And so, we have a lot of brilliant parsers and validators out there which are waiting to be used. And the main goal is that configuration management and other tools should use exactly the same parsers as the applications do. And so, Electra also introduced this specification language. I cannot go into detail during this talk, but so, things that can be done in the specification languages, you can specify which options are there. You can document them. You can specify which defaults are there. So, if I remove the option, what does this actually mean? If no option is there, and so on and so on. So, all this information which is actually needed for doing configuration management should be in this specification. So, that's the long-term goal of Electra. So, and what also can be done because of this, you can also patch through, for example, if you have here a configuration management tool, you'll see this later then. You can patch this through to some specific file, for example, using the Orgea sparser and doing something so you can decide which parts of the configuration maps to which parts of the configuration files. Okay, so to end this high-level overview, this technology integration can be used for configuration management, and the border is quite well defined. So, Electra is something which runs on the nodes, and the distribution between the nodes happens within the configuration management tools. So, Electra doesn't bother about this, about this deployment, but it buzzes about how the configuration works on the individual nodes. And, yeah, and the focus in the talk will be Puppet, but actually you could use Electra with any configuration management tool as, yeah. So, I will talk today about not only one tool about Electra, this will be the first part, but also about Puppet Electra, which is a second project using Electra. So, let us start what Electra is. So, Electra is a small, fast library. It doesn't have any dependencies, but it has many plugins, and these plugins have dependencies. It doesn't introduce a daemon, it doesn't introduce any security problem, and its main abstraction we need for this talk today is the key value abstraction, which is the common structure amongst all configuration files, and any configuration file syntax is mapable to key value pairs. And, yeah, with this abstraction in place, you do not have to care about the concrete syntax, which is in use. So, here we have, for example, so the same configuration is expressed in any and also a little bit more of a pose in XML. And these are some different parsers which are available in Electra today. So, there are also quite some bindings available, so especially relevant is Ruby binding, which we will use later for our puppet integration. Okay, there are currently more than 80 plugins available within Electra. A lot of them are involved in how to manipulate configuration files. Others, for example, can check configuration for validity, and others, for example, can encrypt values within configuration files or can do completely different stuff. There are packages available for Electra in various distributions, and, yeah, it's already used widely in proprietary software, and, yeah, for example, here are some examples. Yeah, but from the beginning of Electra, the goal was to be used by the Floss ecosystem, so I'm here to push this a little bit forward. There was a lot of positive response in the talk yesterday, so I'm looking forward to see more applications electrified soon. Okay, so the second part will be this puppet Electra module, so it basically adds two resource types within puppet. They are called Cardi B key and Cardi B mount, and what they achieve can be shown here. So we have this compiled catalog, which is distributed to the nodes and the puppet agent then uses the LibElectra core, and this Cardi B mount resource type defines this mapping. So we add new, we have new kinds of identifiers, which are called the keys, and we can map these keys with concrete files on the disk and with concrete formats. For example, I was in here. So that's the Cardi B mount abstraction, so this mapping here, and then we have the Cardi B key, which can manipulate individual values within these files. So these are the two main abstractions. And the main idea in the puppet Electra is to have configuration settings as first class citizen, so that we are not manipulating complete configuration files, but we go down to individual configuration settings. And the goal of the project is to bring all features from LibElectra to puppet, so all the passers Electra has, the error messages that are provided by Electra, and so on. So how does it work? So the Cardi B key, so as you know in puppet, you need here a unique identifier, and luckily Electra exactly has this unique identifier. Every key from Electra is a unique identifier for a concrete configuration setting. So we directly write it here, and we automatically fulfill a puppet property with it. Then we have the standard so that we can ensure that something is present, and then we can set a workgroup name. So here we actually edit the Samba configuration and set a specific workgroup. So it's as simple as that. So, and of course, so Electra does not manipulate any other settings. So the rest of the Samba configuration stays completely untouched. And if we want to be sure that some value is not there, so it should be the default, then we can ensure its absence. Okay, so, yeah, the larger goal of Electra, as already said, is that application developers directly use Electra, and in this case, nothing needs to be done. We would just write to this pass that the Samba configuration file would be edited. Yeah, as, yeah, of course, we have to bootstrap to get to this situation. And so if applications do not already use Electra, we can mount them. And for example, yeah, this here mounts the Samba configuration file. So we say at this Electra key, we want to have this configuration file present, and here we can specify a list of Electra plugins to do so. Okay, and, yeah, if we can even go further, we can also add a specification, because in Electra it also has a specification language included, and they can also written down directly in Puppet. For example, here we can define simple checks. For example, a type with short and some range, which is actually then not part of the configuration file, but it will land up in a specification namespace of Electra. And here this is more than imperative Puppet code can do, because we can also have local checks. So these checks happen local on the node before writing out the configuration. For example, we can check if a file exists in a trivial way. Okay, so it's even more comfortable because it tires to manually encode this configuration constraints. And we also have a lot of implicit checks. Some black-ins already know how their data look like. And here's one of the strengths of Electra. For example, from how hosts file look like, you automatically know which parts are IP for four addresses and IP for six addresses and how canonical host names look like. And if you use the hosts plugin as done here, the Carribean Mount, the host plugin, the host plugin actually recommends global network, so that's not really necessary to write it down. It's only here to see the larger picture that more than one plugin is involved to do this. And then we get a complete check that we only write a valid hosts file. So if we have here an invalid IP address, if this master IP address is invalid, we will get a validation on the node where a get address info will be invoked. And it actually check for this operating system if this IP address can be successfully resolved. And otherwise, you get an error message from what get address info says about the IP address. And again, the long-term goal is that application developers, because they know best what configuration actually expects, should write the specification. And it's really simple because also the specification is in key value pairs. You simply say this is an IP for four address and basically you have already encoded all the information we need to know. So what we actually want, we want to go beyond dev ops. Of course it's nice if you have a group of developers and operations working together, but it's not always possible. And the long-term goal is that we have a common language to speak between developers and operations so that we can communicate more efficiently what we expect as well as configuration. Okay, so the last part will be a case in the user study where this puppetry was used. And first we have done a case study. And in the case study, we basically set up the whole infrastructure of LibElectra. So there's this web server, documentation server, many DNS liaises and so on. And also a complete build server, continuous integration and so on. And all these parts were realized with Puppet LibElectra. Some of these applications directly use Electra, then it's of course quite trivial to apply Puppet LibElectra. In two cases, so Bernard was the one who implemented the Puppet LibElectra and did this case in the user study. And he also implemented, for example, two Ruby plugins which pass and write configuration files. Okay, then a little bit more information about the user study we did. So, yeah, we had four Puppet tasks in three different variants. And the Puppet tasks were non-trivers. So you have to manipulate different configuration files in different ways. And the focus was on configuration file editing. And we compared the usability between Cardi B Key, the one Puppet provider talked before, then Argeas, Innis settings and host. And yeah, and we also did time measurements. So the setup was quite sophisticated and robust. Also participated in the study. For example, David, who will have the next talk, also helped us a lot and also participated in the study. Thank you a lot for that. And if you worked with this system, you really saw that there was a lot of effort invested. And doing this setup, we measured how long editing of configuration files needed. And in the first task, we had a host file editing, like shown here. And in the second part, we had modified SAMBA configuration. And, yeah, so here are the median values. And this is a box plot. So if this percentile 25 and 75, and these are the outliers here. So this already gives a quiet, clear picture. But we also used statistics to show if there's a significance and it actually was. So the host is significantly faster than Electra. So it actually pays off even with Electra to write dedicated resource types. And then the any settings was on par with Electra. But as you know, any settings is not generic. It only works for any. And for maintenance tasks, there was not a clear conclusion. We also asked about the usability of the systems. And, yeah, so we asked a questionnaire to rate the usability of the systems, what is best and to what is worst. And also here, the specialized host plugin was liked most. And any settings and puppet Electra are second best use here. Okay, so at the moment, we have a usable solution as shown with the completely Electra.org infrastructure works with this. And for example, with puppet 4 and Debian Stretch, we have a very reliable solution. But in other systems, for example, the Ruby interpreter is not of the system, but another one is used. And here, a Ruby game would help, which does not exist at the moment. And so, yeah, it is still maintained. So Bernhardt is still agreed to maintain it. And I'm also a co-mentainer, but it would be great to have help and bring this tool forward. Yeah, then there is this multi-key support. Electra by itself has transactional support for configuration files, so you can make a large change of many configuration files and Electra makes sure either all configuration files are changed or nothing happens. But in the current implementation, every category key makes an individual invoke within Electra. And, yeah, but for some plugins like Algiers, you can't go far if you need a single, if this is separated. So multi-key support would be great. And we hope to, yeah, the problem was in actually implementing it in a puppet provider. And we hope that there's a better support from puppet. Yeah, but maybe we hear something about in the next talk. So here a picture of some of the people working on Electra. So this is Bernhardt who did the work. He could not come here. Unfortunately, Thomas is here. We will wait afterwards outside. So if you want some t-shirts or stickers and want to talk with me, I will be outside afterwards. So this is a more complete list of people currently working on Electra and on many topics. I can't go into the details of this. So, yeah, yeah, here you can find the puppet LibElectra. And, yeah, and here you can find Electra. And we also have all the data available of this user study. And, yeah, so are there any questions? Okay, so the question was if I have this validation already in the application, let's say if there is some way to export it to Electra without defining it on two places. And, yeah, that's a really good question. And the goal of Electra is to have it only at one place. And the current solution of Electra is that if you have already specified in the Electra, you can generate the code you need in the application. So Electra is also a code generator where you can put everything within the application. Yeah, so thank you. Is there another question, yeah? Yeah, I think it's in a private repo currently because I think the data of the persons participating at the puppet, so you mean this puppet controller and this docker, I think that's currently in the same repo and we cannot publish it because it has nonanomized person data, but on request we can separate it and give you other, so please drop in emails. Thank you, it's a good idea, yeah? Are there some other questions? Okay, let's give it up for Marcus. Yes, okay. So see you outside.