On Wed, Mar 1, 2017 at 9:12 AM, Erik Dalén <erik.gustav.da...@gmail.com> wrote:
> > > On Wed, 1 Mar 2017 at 14:46 Trevor Vaughan <tvaug...@onyxpoint.com> 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 > For that ticket in particular, changing from a strict object model to a more lookup-oriented scenario should fix a lot of things. If a provider is in that does something *different* in theory that should be a different resource. Also, many resources, by nature are simply tied together and special logic will need to be in play to handle those relationships. So, for that ticket in particular, using the model that is used in Concat, and SIMP IPTables among others, the 'package' resources should be *data* and the culmination of all types of packages for type 'yum, rpm, deb, foo...' should be that the correct command is run in batch mode. However, this means that if any one of those objects fails, then everything downstream from all of them fails and this is a bad thing. There would just need to be a LOT more back end logic and the ability to fail parts of the resource tree. I still think that the object model is the problem, not this particular interface to it. > >> >> *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 :) > I get it, but take a look down this monstrosity stack and tell me that it wouldn't be WAY easier if I could just call a few Ruby functions https://github.com/simp/pupmod-simp-simplib/tree/master/types/ip -- 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 puppet-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-dev/CANs%2BFoWT3VHxurAsoUXjA982ym2ZKKm-7s92zBNLDZDmr-5HHg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
