On 1 March 2017 at 14:12, Erik Dalén <[email protected]> wrote:
> > > On Wed, 1 Mar 2017 at 14:46 Trevor Vaughan <[email protected]> wrote: > >> As always, if I wait long enough, John will more eloquently provide the >> response that I wanted to! >> >> I've added a few responses inline >> >> >> *Big picture items* >> >> *Multiple implementations / implementation selection* >> >> In splitting resources into "definition" and "implementation", the >> proposal adheres to a *form* similar to the current system's, but it >> seems to have fundamentally different design goals. I've always >> interpreted the present type / provider system's separation of resource >> interface from implementation first and foremost as a means to accommodate >> multiple implementations. The one most appropriate to the target system is >> chosen from among those available. I think that's a sound design approach; >> I like it, and it has served Puppet well. As far as I can determine, >> however, the proposal loses that completely -- I see no means to support >> multiple implementations at all, much less means to match an implementation >> to the target system. >> >> >> I hadn't actually caught this, but if not just an oversight, it is indeed >> concerning. The ability to choose from various providers has been a strong >> play in Puppet's favor. >> > > Although in some cases it is a bit annoying, for example not being able to > install a gem and deb with the same name on a host. This specific case was > fixed in https://tickets.puppetlabs.com/browse/PUP-1073 but still exists > for other types than package. > In many cases the providers actually manage different things, not mutually > exclusive variants of the same thing. > But having deb_package and rpm_package would definitely just be annoying > if you wanted a module that works across multiple distros. Putting both > providers into the same implementation file would be a bit ugly, but could > work I guess. > > >> >> >> *Inadequate interface documentation* >> >> As I said earlier, one of the biggest problems with the current system is >> inadequate documentation. As it now stands, the proposal's documentation >> does about as well as the docs of the current system. Missing is >> information about how the runtime environment is intended to use the >> defined objects and methods -- for example, under what circumstances it >> will instantiate / invoke them, how many times per transaction (partially >> addressed in the doc), at what point(s) in the transaction. What may the >> environment do with the object returned by get() and its contents (i.e., >> must implementations assume that the environment may modify them)? Is >> there anything the environment is required to do with them? What may an >> implementation do with the object passed to set() and its contents? Is >> there any expectation about relationships between the objects provided by >> get() and received by put()? >> >> >> This is definitely true. Gary's blog has been the seminal resource for >> figuring out how to write types and providers and, instead of a new >> interface, it might be good to finish the original docs. That said, I think >> I remember David saying that part of the intent of this is to provide a >> language-agnostic interface to managing the system so that users aren't >> tightly bound to a particular implementation. I think that this is a good >> goal *but* I would maintain compatibility with existing Type and Provider >> implementations. >> > > There's a bunch of things that can't be solved in any good way in the old > type and provider system that looks like it would be pretty easy to solve > in this new system. For example this old feature request: > https://projects.puppetlabs.com/issues/2198 > yeah, that is exactly the reason for passing an array of resources into the set() method. It'll require more infrastructure around it, but we have to start somewhere. > *Specific features* >> >> *Attribute and parameter validation* >> >> Validation ought to be performed during catalog building, thus it needs >> to be adequately addressed by type "definitions". I am dissatisfied with >> the proposal's provision for that. The Puppet type system is very >> expressive, but it can also be very arcane. I maintain that it is a >> mistake to rely exclusively on the type system for validating "attributes" >> or "operational parameters". Moreover, I think the proposal is missing an >> opportunity to provide for multiple-attribute, multiple-parameter >> covalidation. This has been requested on and off for a long time, and this >> proposal is a great opportunity to finally put it in place. >> >> >> This was one of my biggest worries early on and it has been solidified >> with the example code. The Type system simply isn't suitable for complex >> validation at this point. I need logic (sometimes stupid amounts of logic) >> and, until I can do arbitrary validation with the Type system, I can't use >> it for my parameters. >> > > If all attributes were defined in a single type it could handle a lot more > situations (although the type signature could get massive). Consider this > simplified example for a file type: > > Variant[ > Struct[{ > ensure => Enum[link], > target => String, > }], > Struct[{ > ensure => Enum[file], > content => String, > }], > Struct[{ > ensure => Enum[file], > source => String, > }], > ] > > That would only allow the target attribute if ensure is "link", and only > allow either content or source if ensure is "file". > Accounting for all possible attributes on the file type would probably > span a few pages though :) > Technically, a solution. :-D Regards, David -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CALF7fHbVswDjfv_Sh_CWHDZaAUUMWrxpDcNq5NWeF-X86XxFkA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
