Closed jarosser06 closed 9 years ago
Stencil Set Manifest
{
"id": "stencil set name",
"ff_api": 1,
"default_stencil": "default_stencil_name", # this will be required
"dependendencies": [],
"berks_dependencies": {
"dep name": {
"options": {
"option": "value" # options like git
}
}
},
"options": {
"option name": {
"default": "default value is optional",
"help": "some help text for this value is also optional"
}
},
"stencils": {
"dependencies": [],
"berks_dependencies": {},
"options": {},
"files": {
"rendered file": "template file"
},
"partials": [],
"directories": [] # Optional but helpful
}
}
Done and merged :)
The names provider and provider type have bothered me for a while but I was unable to come up with anything better. I think the naming should be redone to the following:
Instead of provider use stencil set, it provides a much better idea (IMO) of what it actually does and provider has a very different meaning in Chef.
Instead of a provider type it can be a stencil.
Definitions: A stencil provides a group of templates that add instructions to Chef to handle a particular thing like a creating a recipe to provision a redis master or a Django application that uses Nginx and Uwsgi.
A stencil set is a set of common stencils, so the redis master stencil will likely exist under a stencil set named Redis along with a redis slave.
This naming will cause some things to change on the user facing side such as the manifests in the template pack as well as the fastfood templates that can be used to create and update a cookbook.