Resource API v1.0

[DavidS]

Public PR to facilitate conversations.

This contains draft spec language, code examples, and the history how we got here.

There is still much to do before this can be merged.

[lutter]

Could this be merged with a big 'Draft - under discussion' disclaimer ? (If need be on a separate branch) That way, others can make PR's against the draft to amend it.

[DavidS]

@lutter people can always PR against my branch/fork; collaborators should even be able to push to my branch directly

@igalic thanks for your comments! I'll work them in on my next revision - maybe later this week.

[DavidS]

To keep the loop closed, I'm currently working on a prototype implementation of this in https://github.com/DavidS/puppetlabs-apt/tree/resource-api-experiments

It currently only supports listing apt_key resources through puppet resource. More to come.

[reidmv]

Regarding e974464: how we handle noop is critically important to sustaining an important benefit of Puppet, which is that the framework handles making sure when you run in noop no changes are made to the system. This is a key differentiator between our noop feature and e.g. Chef's dry-run, because more onus is put on Chef's resource developers to make sure dry-run doesn't change the system.

I haven't looked at this recent change it detail so maybe this is already true, but I believe it's important the default, simplest behavior should be noop-compatible. That if you want to do anything that would not be noop-safe, that should require more typing or parameter passing as an opt-in "I know what I'm doing" to bypass noop safeguards. That is, command invocation should be noop-safe by default, and you should have to ask to step outside those safeguards.

Is that the case with the changes in e974464?

[DavidS]

@reidmv : by default, the set function will only be called if the Runtime Environment wants the Implementation to affect changes in the target system. This has not changed from the original API. What has changed, is that Implementations can opt into taking over that decision responsibility themselves, by declaring the noop_handler feature. In this case the Commands API provides a simple ..., noop: noop) parameter (that can easily be checked [even mechanically]) to defang commands that should not run under noop, while still leaving the possibility to run commands when necessary. To note: many providers in the future are expected to talk to APIs (not local commands) which will have no need for noop_handler at all, or require different safety measures.

@lutter : this seems like only a reshuffling of symbols.

[DavidS]

While it's not yet fully implemented, I'd like to call for a final round of comments on the text as it stands.

A 0.9 of the core concepts is available as https://rubygems.org/gems/puppet-resource_api and is already being trialled by us internally.

[DavidS]

PS: see also pdk new provider in the upcoming v1.4 and the pre-releases available on http://nightlies.puppet.com/

[DavidS]

The Resource API v1.0 gem has been released, so this is now a Thing[tm].