On Tuesday, January 31, 2017 at 10:04:27 AM UTC-6, David Schmitt wrote: > > > The type and provider API has been the bane of my existence since I > [started writing native resources]( > https://github.com/DavidS/puppet-mysql-old/commit/d33c7aa10e3a4bd9e97e947c471ee3ed36e9d1e2 > ). >
Honestly, I've never thought the type / provider system was too bad. Certainly it works pretty well for simple things. Now, I'm more of a Dev who does Ops than an Op who Devs, but from my perspective, the biggest problem with Puppet's types & providers has always been inadequate documentation. The docs in this area are a bit better now than when I started with Puppet around eight years ago, but they have always missed presenting many relevant details about how the host Puppet instance, resource instances, and their associated provider instances interact. This new effort doesn't seem to be targeting any of that. > Now, finally, we'll do something about it. I'm currently working on > designing a nicer API for types and providers. My primary goals are to > provide a smooth and simple ruby developer experience for both scripters > and coders. Secondary goals were to eliminate server side code, and make > puppet 4 data types available. Currently this is completely aspirational > (i.e. no real code has been written), but early private feedback was > encouraging. > > I'm confused and dubious: how is it that the guiding goals for this effort are all about form rather than function? Surely, if you intend for the result to serve any particular function(s) then you need to be guided at least in part by which functions those are. Perhaps for you that's tied up in what you mean by "a type and provider API", but I am confident that some of the details of what that means to you differ from what it means to others. You really need to be explicit with this if you want good feedback. Moreover, inasmuch as you seem to imagine this API eventually supplanting the existing one, it may save a lot of future grief and expense to make sure everyone is on the same page early on. Moreover, none of the goals given are addressed the needs of the API client, which is Puppet itself. Or do you have a different concept of who the client is? If so, then you and I have even more different ideas of what a "type and provider API" is than I had supposed. Furthermore, as wonderful as "a smooth and simple ruby developer experience for both scripters and coders" sounds, I think it's utterly unrealistic. People who aren't good at writing native code or who just want to avoid it have much different wants and expectations from those who are comfortable with writing native code. In fact, Puppet already *has* support for "scripters": this is what defined types are all about. People who don't want to be writing Ruby are unlikely ever to have a smooth or simple Ruby developer experience. The most likely outcome of trying to simplify any more than serves coders well is producing something insufficiently powerful / flexible. > The `Puppet::SimpleResource.implement()` call receives the `current_state > = get()` and `set(current_state, target_state, noop)` methods. `get` > returns a list of discovered resources, while `set` takes the target state > and enforces those goals on the subject. There is only a single (ruby) > object throughout an agent run, that can easily do caching and what ever > else is required for a good functioning of the provider. The state > descriptions passed around are simple lists of key/value hashes describing > resources. This will allow the implementation wide latitude in how to > organise itself for simplicity and efficiency. > > So there is no mechanism for obtaining the current state of an individual resource? That seems a bit of an oversight. There are resource types that cannot feasibly be fully enumerated (e.g. files), and even resource types that cannot be enumerated at all. Also, though you say elsewhere that the provider's set() method receives a list of resources to update, that is not borne out by your example code. > The `Puppet::SimpleResource.define()` call provides a data-only > description of the Type. This is all that is needed on the server side to > compile a manifest. Thanks to puppet 4 data type checking, this will > already be much more strict (with less effort) than possible with the > current APIs, while providing more automatically readable documentation > about the meaning of the attributes. > > I'm not at all convinced that your concept of a resource type definition indeed covers everything needed -- or at least wanted -- on the server side. For example, I'm all for engaging the type system, but 1. The type system does not cover all potential validation needs. In particular, it cannot perform joint validation on multiple parameters. 2. Using the type system for any but pretty simple validity checks will run against your objective of providing a simple interface. Also, if handling types does not involve any server-side code, does that mean that the type system is not engaged to validate parameters until the data reach the client? If so, that in itself is a controversial interpretation of what is and is not needed on the server side. I'm not prepared to offer feedback on the details at this time, because I don't think you've sufficiently established what the effort is trying to accomplish. John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/b1e62075-4341-4c4b-a646-61f96f980177%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
