Jira (PUP-4370) Formalize Types and Providers API

[Henrik Lindberg (JIRA)]

Title: Message Title

Henrik Lindberg commented on PUP-4370   Re: Formalize Types and Providers API I am not aware of any tickets describing that we need to write a specification of the types & providers API(s). Here is an assortment of thoughts about these APIs: A (resource-) type should be a data carrier, its only behavior should be protecting its own integrity and validity of its parameters. It should be possible to have parameters that in turn are user defined data types. We have the new keywords type and attr reserved. The intent is to use those to enable describing a resource type in the puppet langauge; e.g type mytype inherits resource { attr Enum[red, blue, green, yellow] color ...} We may need to support describing logic (in puppet langauge, or perhaps via predicates/queries) for things like: We have discussed supporting "invariants", i.e. validation across parameters. We may want to support light transformation of attributes, as well as derived attributes. We have talked about producing one (ecore) model per puppet module that contains the description of all of the types in the module. This description is then used to produce necessary runtime support for an implementation language and API for providers. We have also discussed a simplified approach to properties; rather than having properties with two values (desired state, and achieved) we should simply give a provider one instance of the resource-type and expect a new instance back after a "sync". Instances of resource-type should be immutable. All attributes should be typed using the puppet type system. Do we need to keep the distinction of parameters and properties? (I.e. some attributes are input only, some input/output). Do we need to keep the feature that any module can add meta parameters to all other resource types? The above should enable a convenient way to implement a provider in a statically typed language such as C or Java, or a dynamically typed language such as Ruby, Python or Go without having to implement serialization/deserialization logic or the "resource object" with its getters/setters and intrinsic integrity and validation checks specific to each resource-type. The next level up from the basics of resource instances and providers is the application logic itself; what can providers do, what must they do, how can they delay operations, operate in parallel, collect input and perform operations in batch, generate resources, discover resources, etc. Such abilities may require a tighter interoperability using some kind of IPC (more advanced than exec/pipes), and may involve state management of the provider implementation (lifecycle). We also need to figure out how we can implement this in a fashion that gives a reasonable migration path for existing types and providers, allow new resource-types and APIs to coexist with existing (while developing and migrating). Add Comment   This message was sent by Atlassian JIRA (v6.3.15#6346-sha1:dbc023d) -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-bugs+unsubscr...@googlegroups.com. To post to this group, send email to puppet-bugs@googlegroups.com. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/d/optout.