 Hey folks, my name is David Schmidt, you can find me on various media. I'm currently third, for last year, I've been the technical developer experience of Pop-Up, and we worked on a couple of projects to make the life easier for model developers, just a quick show of hands. One of you has been working or is working on a Pop-Up model that contains native code, all right? Which one of you actually can try the experience? Yeah, I envy your pain resistance. So one of the things we came up with is a new resource API. For all of you who have not been working on those native providers, let me give you a quick introduction on what providers are in the Pop-Up ecosystem. They are basically how Pop-Up knows how to manage small bits of your systems that you want to change. The type defines the shape of the resource, which attributes are there that can be manipulated, what's the name, and what are the positive values for that. The provider itself then allows you to read the state of those resources, and finally enforces a desired state onto that system, and that's how Pop-Up interacts with all resources out there. Pop-Up Core has some well-known providers like file, package user, many models have built-in resources like the AWS model that has built-in resources for EC2 instances, RDS, et cetera, et cetera. Then like Marcus just showed, the KDB key, again, the native provider, where small pieces of really code interfaces between the Pop-Up manifest language and the actual real-world systems. So a quick overview because I don't have much time here. This is how resources look like in Pop-Up 3 and much more, in comparison to those in Pop-Up 4. Up here you define a new type as a snippet of movie that gets passed in world code, then like down here, which defines a property called size with a description in it, and this here says it's generally multiple of 10, 24, and this property is weak only. So there are quite a few problems with this approach that we found over the years. Well, it's movie code. So if another consumer wants to gain an understanding of how that resource type looks like, you need to run the movie code. And to run the movie code, you need to have Pop-Up, which is quite a size of a code base and which makes it very inconvenient to use those resources or even interrogate what resources are available and how to look like from outside of Pop-Up. The other thing is, since the properties down here are also defined as code, if you have specific validation needs like, oh, this actually should only be a number, all of that is usually encoded in regular expressions over a custom code, which again is not directly available outside of Pop-Up itself. And finally, you'll notice that the description here says this property is weak only, which if you have resources that also can show you more state of the system than it's actually able to manage. The only thing that keeps users from trying to push values into that is this sentence there may be a hand-coded check in the provider itself. But again, usually convenient to use or really safe to use. If you have special requirements like a premium property, I was not able to fit that code onto a slide, so I'll spare you the pain of that. Because as I said, Visuals API is now giving up to change that significantly and make one of this much easier. So here we have to shape with a new style resource or since it's the pre-release, you need to require the Pop-Up Resource API on top here and then pass in a data structure into a single function call. Again, to make it currently work with auto loading and because we are still working on the details there, currently this is still really cold, but the core information of that is just a really hash that can easily be loaded from JSON or something else if you want so and that's what we're planning for the next step. But it's just a really hash, it has the name, it has the doc string here, it has some features that your implementation has and then down here it just has a list of attributes, for example the insurer attribute here with the usual definition of present, absent. As you can see here, now this completely supports Pop-Up for a data type, so there is no ambiguity around what positive values go into your provider. Here on the right side, the size attribute from before, this is not an integer and you can specify the read-only behavior here and all of that works out of the box as expected and you don't need any custom code on the provider to make that happen. Since talking about code is boring, I've brought a small demo here. All of this works with Kern code at least with the nightly release of the PDK. So this is the only one fully released piece of software I'll show you. The next version of the PDK will have that built in at least as an experimental feature. As I said, we're using this already internally, but we want to get your feedback on how this works out for you and what you would like to see next in there and what doesn't work for you so that we can make it better over the next few weeks and months. So we'll start out with a new model demo. As of yet, the model also requires a couple of more prerequisites so that the unit test integration works. If you run PDK new provider and the provider name, it will point you to the documentation which is here. You need this sync demo here to install the additional dependency. One of our next things that we want to do is to integrate the Reasons API into the core public agent once we are satisfied that it actually works as we intend. Now, the additional things have been installed here and I can say PDK new provider demo and it creates these profiles. We need for the provider. Let's start it up in the editor here. So this is the model I just created. And as you are used to the exactly what I showed before, the insurer, by default it just creates an insurer and the name property but you can add additional properties here. You can add parameters which are information that's not persistent to the system and just information for your provider how to work. You can have doc strings in here. All of the details of that are explained in detail in the reading of the Reasons API. What's interesting to you is then the provider itself. If you ever have touched on of those plugins, you know that there is quite a bit of data banging going on to get the data from the manifest into a structure that you can actually work with. The instances method, the prefetch method, the property hash and if you touch the word in a few of those, you will likely have found multiple permutations of the same patterns over and over again. It's all very confusing. The Reasons API only requires you to prevent two methods. One is to get method here in the current new provider. It's just as took an example. It runs a command and processes it to stand out. But what you need to do here is just return an array of hashes that have the shape of your resource. So even type this while it has a ring and show method and here we just return hashes of that and all of those hashes that get returned are then visible to Puppet as resources that are currently in the system. In the simplest cases like here in this example, you can inherit from the single provider which gives you a couple of lines of code of base functionality and then you get code down here either with create, update or delete depending on what Puppet wants from you and those methods get passed in a context for loving purposes, the name of the resource that should be acted on and again a hash of the attributes that should be set in the system and this allows you to very easily just have that little snippet of code that you need to either call an extremely applied or run a local command to enforce the state that should be in there. And that's and finally what we also do, we render out a unit test for this provider that provides a high level of coverage for the generated code. One of the since existing types of providers are so deeply tied into the Puppet code base it's always very hard to write proper unit tests for them because you have to guess how Puppet is reacting in all those different method calls that I've listed before. For the resource API, you only have to test that if the get method is called in the context it calls to say an external command and if that external command returns a specific standard out you can provide that in your test like here. I have the command creates an echo command here that was used in the example and then the test is the issue command should receive run and return a standard out with some resources and for example if the return of that command when it's empty get is expected to return empty and if the command returns some output the provider is expected to return those resources. We have still quite a bit of time left so if you have specific questions I'm more than happy to answer them. So the question is whether the PDK is meant just to ease providing providers or whether this year is a completely new type of provider and there are two things going on here one is the resource API channel itself and I have in the slides I will upload them to the first and to the second part later and the resource API channel is basically usable without the PDK but the PDK just makes it easier because it creates those three files for you. The providers that provide this resource API are usable with old Puppet versions that the conversion support that is Puppet 4.7 on works because there are some infrastructure things that the API requires for the Puppet 4.0 data type support. There are also usable with the open source versions of the first 7 on works so they're fully integrated into the Puppet ecosystem there. I've only shown the PDK new provider thing because it makes it easier to get started and in case of those few things to get started without having to type those of course. Yes, I don't see a future where we will remove the old API within the next three to five years, right? There's still loads of content out there it's still very useful to people. Also, there are a couple of things that we currently can't do in the resource API like if you need for some reason access to the catalog very deliberately to avoid entangling the resource API with Puppet itself. The resource API currently doesn't give you access to the catalog so some advanced types currently do that. We're looking into ways to serve data at a different level where you see you can post-process the entire catalog but that's still underrobin' up. But yeah, back to your original question where there is no plan currently to deprecate the existing types of providers, APIs existing providers will work as going forward as before. I would gladly help any who want to port their code to the new API and get rid of approximately a third of the lines of code. I would be happy to help. I'm always on the Puppet resource release or if you're on Slack you can ping as developed. Forgot to mention, linked from the Puppet resource API is also example code of very fully-fledged providers like one of the things I did, I ported over the App Key and App Key management provider in an afternoon. As I said, it has now approximately a third of the lines of code and the unit of coverage went from 20%, which is basically all the commands and the definition statements of Ruby to 100% where really every single line of the providers tested in depth and there's a high confidence in there that actually if you change something in there the unit tests will actually then tell you that other users passing here have spoken or this specific edge case needs fixing. Need to install the channel currently placed in the Puppet server and the Puppet agent channel environment. Since we're still in development, so there's a 1.0 release on the horizon but we're still looking for a real-world validation of what we built here actually works for you folks. So currently we still need to install it. Currently, in turn, it's specking out the Puppet 6 platform release for maybe later this year, maybe not, it's still out here but that would definitely be a point in time when I would aim for getting the users' API integrated in the Puppet proper as a default component and at that point then you would not have to have any additional installs. If you use specific features of the API, then those need to be available on the agents that are running the code but once we get into nurturing of this I would not expect too many more releases. There was another question.