 So welcome to the talk generic config API beyond cloud runtime and CPI configs. So my name is David. I work at SAP in Waldorf in Germany, and I'm part of the Bosch and OpenStack CPI team, which is made up of developers from both SUSE and SAP. Okay, so I think you have read this already multiple times throughout the conference, so we can skip this one and right jump into the contents. So in Bosch, there are three built-in configuration types and namely cloud runtime in CPI. And when I started half a year ago as a Bosch developer and Bosch operator at SAP, it took me some time to get familiar how these Bosch config types are getting used. So here's what we will learn in the next 30 minutes. We will first recap existing config types. We will then reveal shortcomings of the current config approach. We will introduce the generic config API and its new functionalities such as versioning of configuration files, diffing as well as splitting a config type into multiple named files. We will do a short demo presenting the new Bosch CLI version three commands and then present a couple of new use cases where Bosch and also you as a Bosch operator could make use of the generic config API. Okay, so let's recap the existing config types. So the cloud config defines infrastructure specific configuration and you see a snippet of an example cloud config on the left. So the value of the cloud properties key, everything what you see in green is infrastructure dependent and the different infrastructure CPIs define their own schema for the cloud property section. So for example the AWS CPI defines that there must be a key called availability zone with a value being a string in this case US East 1A whereas the GCP CPI causes just zone rather than availability zone and the name what you see in black here so in this case Z1 is actually a name given to Bosch and this name gets later referenced from the deployment manifest because the deployment manifest defines in which availability zones its instances will run. So the cloud config is there to define infrastructure specific configuration once and to then reference it multiple times and it allows us to keep the deployment manifest infrastructure agnostic. So we use the Bosch CLI commands cloud config and update cloud config. So cloud config just lists you or just shows you the latest cloud config and update cloud config you can create or update current cloud config on the director. So the runtime config defines configuration that applies to all VMs in all deployments and this is useful for security agents, antiviruses, monitoring or logging tools. The runtime config itself is infrastructure agnostic and you see an example runtime config on the left it basically knows the concept of an add-on so an add-on is a release job that is co-located on all VMs managed by the director and in this case we have just a simple runtime config with a job called user add which adds a backup user and it's public SSH key onto all VMs managed by the director so that the operator can SSH into those VMs. And again we have the Bosch CLI commands runtime config and update runtime config for downloading or uploading a runtime config to or from the director. So the CPI config defines multiple CPIs with properties how to communicate to a given infrastructure section. So by infrastructure section we mean something like an AWS account or OpenStack tenant or vSphere data center. And in most cases having a Bosch director using a single CPI and therefore a single infrastructure section is sufficient. However in production it might make sense to use multiple YAS sections and therefore multiple CPIs for availability, isolation or scalability reasons and multi CPI and therefore having a CPI config is totally optional. So at deploy time that is when deploying the director with the Bosch createNF command we use an ops file for a single CPI. And then at runtime that is why once the director VM is up and running we could then optionally upload a CPI config with further infrastructure sections. And these infrastructure sections are then referenced from the cloud configs availability zone section. So here in this case you see a CPI called OpenStack one and this CPI is then referenced from the cloud config az section. So here you see that two references just a CPI OpenStack one rather than a cloud property section. And then we say here that it's of type OpenStack which means that the Bosch director calls the OpenStack CPI binary and we pass some properties how to communicate and authenticate to the given infrastructure. And having a CPI config is a pretty powerful concept because it enables you running instances from one deployment on multiple infrastructures. Okay and again we have the Bosch seal I command CPI config for listing the latest CPI config and update CPI config for uploading one. Okay so what do the config types have in common? So in the beginning there were no cloud runtime or CPI configs at all. So everything was specified in the deployment manifest itself. And over the time the concept of the different configs got introduced. So all existing configs have in common that operators can create, read, and update them. And so it makes sense to consolidate them into a single generic config API. So based on feedback from USC community we observed the following weaknesses of the current config approach. So originally there was no different update which means when you didn't update cloud config you didn't see a diff in the beginning. So operators were unable to delete configs. There was no versioning which means you were unable to track down how the configs evolved or you couldn't diff different versions or switching back to previous versions. And there was custom functionality available only for certain config types. For example splitting a config type into multiple files and giving each file its own name this was only available for the runtime config. And what was happening then on the Bosch deployment on the director the latest named files for a particular config type are getting merged into a single file again. And also extensibility is a bit difficult because for each new config type we would need a new HTTP endpoint, new CLI commands, and new database tables. Right. So the Bosch and OpenStack CPI team at SAP and SUSE has therefore developed generic configs and given that the functionality of creating, updating, deleting, and diffing across config types is very similar. The director now provides a consolidated CLI and API functionality. So users are able to do versioning so they can see how the configs types evolved over time. They are able to diff configs and a single config type can now be given multiple names. And one use case of having named configs is that for example different teams can maintain their own configuration files. And all of this may sound to you like we did some refactoring here added some functionality which is true. However the real cool thing about the generic config API is that it pays the way for new config types and use cases. So that's why the following slide is in yellow because it's the main message I would like to convey in this talk. So the generic config API is the building block for new configuration types and therefore new use cases. And here we differentiate between director built-in types and user defined types. So director built-in type means that Bosch understands and applies the content of the configuration. So the user needs to comply with the structure of the YAML file for each type. And so beyond cloud, runtime, and CPI this allows further types like resurrection, tasks, and Chrome config. So we will explore those in a second. Then there are user defined types which means that the user can upload any file containing valid YAML to the Bosch director and assign any name to the type. For example Bosch operators can use the generic config API to manage other configuration files for other cloud foundry services. So we will see an example in a second in the demo. Okay so let's jump to the demo and then we will explore the generic config functionalities and see an example of a user defined type. Okay. So can you see that? Should I do it bigger? That's good. Okay. So I was setting up a Bosch light director here. And as you can see we use the Bosch CLI, sorry, Bosch CLI version three, and we got some new commands here. Okay so what is new is config for listing a current config, config for listing multiple configs. We can delete configs, diff configs, and now also have the update config command for updating further config types. So let's do some examples. We could first upload a normal cloud config. So we now pass a type to it, namely cloud. We must provide a name so we can use any name. Let's use default. Then we upload a cloud config. So we can do this either this way with update config or with update cloud config. So we see the diff. Everything is new. We just upload it. And then let's change something in the cloud config YAML. So for example let's use availability zone Z2 rather than Z1 for the compilation VMs. So if you now update this again, so we use the same type and same name, we see a small diff. Upload this one. And if you do a Bosch config, we see the latest version. And if you say dash dash recent equals two, we see now that we have two versions of the same cloud config. And what we can now do is that we diff those configs with Bosch diff config command past the IDs of the configs. So the IDs are just database IDs that we expose here. And so they start with 14 because I already uploaded some configs beforehand. So we get the diff. And what is also new is delete config CLI command. So now we were deleting the older version and see only the new one. Right. So what is also new is that we can split the config type now into multiple named files. So let's say we have another cloud config called cloud configs Z3. And this just specifies the third availability zone because maybe only one team needs that. Then we can upload this one. So again, it's of type cloud, but we just assign a different name to it. So we say name is Z3. And if you now say Bosch configs again, we see that we have two cloud configs actually with different names. So this enables that different teams maintain their own configuration files. And in future, we would like to provide another CLI command, which is called Bosch merged config, which will show you the result of the merged configuration files of the same type, basically. Right. Then one example of a user defined config type could be, for example, that you as an abacus operator need to upload like pricing plans or metering plans to the abacus API. And so abacus, I think you know it, it's the cloud foundry service providing usage metering. And you could beforehand maybe store those configuration files in Bosch if you would like to get those functionalities versioning, diffing, client set interpolating out of the box. So in this case, you would just say, wash update config again, assign any type to it that you want. We can just say, in this case, abacus metering, for example, assign a name to it, analytics, and then upload the config. And then we see an example of a user defined type here. So I was just making this up, but you could use it for any configuration files. This just need to be valid YAML files. You can upload it to the director, either manually or automatically in your pipelines, and you get those functionalities out of the box. Right. So let's continue with the presentation. Right. So now let's explore some director built in types, which will be then the future. So let's start with the resurrection config. So far it was possible to switch resurrection on or off globally across all deployments. So we could do this either in the deployment manifest by setting the resurrector enabled property of the health monitor to true, or we could use the CLI command Bosch update resurrection to set it on off globally. So what IBM was doing is that they implemented a built-in health monitor config type called resurrection. And there's a PR open in the Bosch repo, which will hopefully get emerged soon. And it allows operators to enable or disable resurrection per deployment or instance group level. So you see an example here. And this example basically just says that resurrection is disabled for deployment step one. However, it is enabled for the instance group API of deployment step one. Then another example of a director built in type is tasks config. So under heavy load in production scenarios, Bosch tasks might queue up on the director and operators may want to prioritize or rate limit certain tasks. And again, IBM was implementing a director built in type called tasks. And it allows operators to define the following rules. So options can be either rate limit in this case, which defines the maximum number of tasks running at a time, or priority, which is just an integer and determining the relative priority between tasks. So then there are those include and exclude keys. And they allow rules for deployments and task types. So in this example, it means that no tasks should be processed for deployment step one. And that the task types VMs and SSH and logs are prioritized over other task types. So this could be useful that if your Bosch director is under heavy load, operators can still do some root cause analysis. Then another use case, which is in our backlog, but not yet implemented is a crew config for scheduling regular jobs or director tasks. And examples would be to do regular Bosch cleanup, or to do a Bosch stop in the evening, Bosch start in the morning. Maybe this is useful on deaf landscapes for saving some resources that you want to stop your jobs overnight. Or you could schedule regular Bosch SSH commands and doing some checks on the machines. And here again, you would upload this config with the Bosch update config command and pass the type crone to it. And the Bosch director will pick it up and understand and applies this configuration file. So in future, we will provide the Bosch merged config command, giving a preview of all the latest named configs for a specific type. And we try to provide more convenience for working with configs. So for example, the deployment manifest is nothing else than another configuration file of how your deployment looks like. So in future, the deployment manifest could be just another config type, which would make the Bosch manifest CLI command obsolete. And then for the output of the Bosch deployments command, what you see here, the idea is to have a configs column showing all configs referenced by the deployment, including the deployment manifest itself. So here for example, you see the deployment depth one references the deployment config, deployment depth one, one cloud config, and two runtime configs. And operators will then have consistent user experience being able to see versions and diffs between deployment configs. Right. So the key takeaways of this session are that the generic config API enables new director built-in types like resurrection config, tasks config, cone config, or deployment config. And that you as a Bosch operator can use the generic config API for everything where you need to manage configuration files, because it provides you versioning and different functionalities out of the box. Okay. Then if you would like to work open source on Bosch or other topics, you can check out this link here. So thank you for joining the talk. And it would be interesting to share your ideas about new config types for your use cases, whether you have something in mind. So are there questions? Yeah. So the question is whether these new config types are already incorporated or coming. So they are coming. There are two PRs open for resurrection config and tasks config. And cone config is we have not yet started to implement it. This is just an idea. And hopefully this will come over the next few months.