Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Edits on resource api readme #17

Merged
merged 2 commits into from
Jan 30, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
52 changes: 26 additions & 26 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ This is an implementation of the [Resource API](https://github.com/DavidS/puppet
## Getting started

* Install the [PDK](https://puppet.com/download-puppet-development-kit).
* As of Jan 2018, the required PDK features are still in development.
* As of January 2018, the required PDK features are still in development.
See [PDK-506](https://tickets.puppetlabs.com/browse/PDK-506) for progress.

* Create a [new module](https://puppet.com/docs/pdk/latest/pdk_generating_modules.html) with the PDK, or work with an existing PDK-enabled module.
Expand Down Expand Up @@ -58,7 +58,7 @@ pdk (INFO): Creating '/home/david/git/example/spec/unit/puppet/provider/foo/foo_
~/git/example$
```

The three generated files are the type, the actual implementation, and unit tests. The default template contains a trivial example, to demonstrate the basic workings of the Resource API. This allows the unit tests to run immediately after creating the provider:
The three generated files are the type, the implementation, and the unit tests. The default template contains an example that demonstrates the basic workings of the Resource API. This allows the unit tests to run immediately after creating the provider:

```
~/git/example$ pdk test unit
Expand All @@ -72,7 +72,7 @@ The three generated files are the type, the actual implementation, and unit test

### Writing the Type

The type contains the shape of your resources. The template renders the minimally necessary `name`, and `ensure` attributes. You can modify their description and the name's type to match your resource. Add more attributes as you see fit.
The type contains the shape of your resources. The template provides the necessary `name` and `ensure` attributes. You can modify their description and the name's type to match your resource. Add more attributes as you need.

```ruby
# lib/puppet/type/foo.rb
Expand All @@ -99,18 +99,18 @@ Puppet::ResourceApi.register_type(
```

The following keys are available for defining attributes:
* `type`: the puppet 4 data type allowed in this attribute. You can use all [data types](https://puppet.com/docs/puppet/latest/lang_data_abstract.html#parent-types) matching `Scalar` and `Data`.
* `type`: the Puppet 4 data type allowed in this attribute. You can use all [data types](https://puppet.com/docs/puppet/latest/lang_data_abstract.html#parent-types) matching `Scalar` and `Data`.
* `desc`: a string describing this attribute. This is used in creating the automated API docs with [puppet-strings](https://github.com/puppetlabs/puppet-strings).
* `default`: a default value that will be used by the runtime environment, whenever the caller doesn't specify a value for this attribute.
* `behaviour`/`behavior`: how the attribute behaves. Currently available values:
* `namevar`: marks an attribute as part of the "primary key", or "identity" of the resource. A given set of namevar values needs to distinctively identify a instance.
* `init_only`: this attribute can only be set during creation of the resource. Its value will be reported going forward, but trying to change it later will lead to an error. For example, the base image for a VM, or the UID of a user.
* `read_only`: values for this attribute will be returned by `get()`, but `set()` is not able to change them. Values for this should never be specified in a manifest. For example the checksum of a file, or the MAC address of a network interface.
* `parameter`: these attributes influence how the provider behaves, and cannot be read from the target system. For example, the target file on inifile, or credentials to access an API.
* `default`: a default value used by the runtime environment; when the caller does not specify a value for this attribute.
* `behaviour`/`behavior`: how the attribute behaves. The current available values include:
* `namevar`: marks an attribute as part of the "primary key" or "identity" of the resource. A given set of `namevar` values needs to distinctively identify an instance.
* `init_only`: this attribute can only be set during the creation of the resource. Its value will be reported going forward, but trying to change it later leads to an error. For example, the base image for a VM or the UID of a user.
* `read_only`: values for this attribute will be returned by `get()`, but `set()` is not able to change them. Values for this should never be specified in a manifest. For example, the checksum of a file, or the MAC address of a network interface.
* `parameter`: these attributes influence how the provider behaves, and cannot be read from the target system. For example, the target file on inifile, or the credentials to access an API.

### Writing the Provider

The provider is the meat and bone of your new resource. It contains all the intelligence to read and enforce state. Here's the example generated by `pdk new provider`:
The provider is the most important part of your new resource, as it reads and enforces state. Here is the example generated by `pdk new provider`:

```ruby
require 'puppet/resource_api'
Expand Down Expand Up @@ -152,7 +152,7 @@ end

The optional `initialize` method can be used to set up state that is available throughout the execution of the catalog. This is most often used for locally acting providers to set up command helpers, or to establish a connection, when talking to a service (e.g. when managing a database).

The `get(context)` method returns a list of hashes describing the resources that are currently on the target system. The basic example would always return an empty list. Here is an example of some resources that could be returned from this:
The `get(context)` method returns a list of hashes describing the resources that are currently on the target system. The basic example would always return an empty list. Here is an example of resources that could be returned from this:

```ruby
[
Expand All @@ -167,41 +167,41 @@ The `get(context)` method returns a list of hashes describing the resources that
]
```

The `create`/`update`/`delete` methods get called by the `SimpleProvider` base-class to change the system as requested by the catalog. The `name` argument is the name of the resource being processed. `should` contains the attribute hash - in the same format as `get` returns - with the values in the catalog.
The `create`/`update`/`delete` methods get called by the `SimpleProvider` base-class to change the system as requested by the catalog. The `name` argument is the name of the resource that is being processed. `should` contains the attribute hash - in the same format as `get` returns - with the values in the catalog.

### Unit testing

The generated unit tests in `spec/unit/puppet/provider/foo_spec.rb` get automatically evaluated with `pdk test unit`.

### Further Reading

The [Resource API](https://github.com/DavidS/puppet-specifications/blob/resourceapi/language/resource-api/README.md) describes the gory details of all capabilities of this gem.
The [Resource API](https://github.com/DavidS/puppet-specifications/blob/resourceapi/language/resource-api/README.md) describes details of all the capabilities of this gem.

This [Introduction to Testing Puppet Modules](https://www.netways.de/index.php?id=3445#c44135) talk describes rspec usage in more detail.

The [RSpec docs](https://relishapp.com/rspec) give a great overview over all the capabilities of rspec.
The [RSpec docs](https://relishapp.com/rspec) provide an overview of the capabilities of rspec.

Read [betterspecs](http://www.betterspecs.org/) for general guidelines on what's considered good specs.
Read [betterspecs](http://www.betterspecs.org/) for general guidelines on what is considered good specs.

## Known Issues

This gem is still under heavy development. This section is a living document of what's already done, and what items are still outstanding.
This gem is still under heavy development. This section is a living document of what is already done, and what items are still outstanding.

Already working:
* basic type and provider definition, using `name`, `desc`, and `attributes`
* the `canonicalize` and `remote_resource` features
* all the logging facilities
* executing the new provider under any of the following commands:
Currently working:
* Basic type and provider definition, using `name`, `desc`, and `attributes`.
* The `canonicalize` and `remote_resource` features.
* All the logging facilities.
* Executing the new provider under the following commands:
* `puppet apply`
* `puppet resource`
* `puppet agent`
* `puppet device` (if applicable)


There are still a few notable gaps between the implementation, and the specification:
* Only a single runtime environment (the puppet commands) is currently implemented.
* `auto*` definitions
* the Commands API is mostly implemented, but deployment is blocked on upstream work (PDK-580). You can use regular Ruby `system()` calls as a workaround, with all their underlying encoding, and safety issues.
There are still a few notable gaps between the implementation and the specification:
* Only a single runtime environment (the Puppet commands) is currently implemented.
* `auto*` definitions.
* The Commands API is mostly implemented, but deployment is blocked on upstream work (PDK-580). Use regular Ruby `system()` calls as a workaround, with their underlying encoding and safety issues.

## Development

Expand Down