Modules metadata standards
Al @ Lab42
discussion.
At the Puppet Camp and on this list there has been discussion about
this.
I might have missed some bits, but afaik there's not yet a formal
decision about that.
So if anyone knows more, please update me.
It has been discussed the modules packaging format, the metadata
format and of course the metadata info to provide.
In order to sum up things, and avoid repeating things already written,
I've found these references on the topic:
1- GIT COMMIT "Adding additional module metadata" by Luke
http://github.com/lak/puppet/commit/3896288ff56b44ae6f5e1f0c2a8adc995a458f76
This is for sure the starting point: json format, some basic
parameters: :source, :author, :version, :license, :puppetversion, :summary, :description, :project_page
2- THREAD: Module Standards discussion
http://groups.google.com/group/puppet-users/browse_thread/thread/66b90ee0e3a229c2?hl=en
Blake Barnett proposed a yaml example such as the following, the
discussion then somehow has evolved on metadata format and modules
packaging but the info outlined can be interesting:
module_postfix.yml
---
name: postfix
version: 0.1
description: Yay.... postfix.
provides:
classes: postfix, postfix::ldap, postfix::gerbils
definitions:
- name: postfix_spamq
description: Specifies blah de blah
required_parameters:
- name: ensure
- parameter_options: present, absent
default: present
optional_parameters:
native_types: postfixregex
dependencies:
native_types:
parser_functions:
modules:
facter_plugins:
3- THREAD: Proposals for modules naming conventions
http://groups.google.com/group/puppet-users/browse_thread/thread/eb0ee0dc312d1a4
Julian Simpson suggests:
"Was there discussion on metadata for modules? I know Luke was
experimenting with that. I'd love to see what OS(es) a module has
been tested on, and what versions of Puppet."
in another post he says:
" I'd like to make a proposal around module
metadata, so that you could declare things like:
- this module depends on others
- this module works for this list of $operatingsystems
- this module uses this sysadmin strategy "
+1 for info about testing results for different puppet versions and
OS.
---
Now, as a user, I think that it is important to know how to start to
write metadata files: format and minimal required parameters.
A final (?) decision is not to be rushed, but an indication of the
format and on some basic parameters that won't be changed for sure is
definitively welcomed.
If from this thread comes out an "officially Puppet complant" example
of a metadata file I'm an happy guy.
My 2c
Al
Julian Simpson
[snip]
> Now, as a user, I think that it is important to know how to start to
> write metadata files: format and minimal required parameters.
> A final (?) decision is not to be rushed, but an indication of the
> format and on some basic parameters that won't be changed for sure is
> definitively welcomed.
> If from this thread comes out an "officially Puppet complant" example
> of a metadata file I'm an happy guy.
>
+1.
Happy to agree the above. I'd rather specify less and get some broad
agreement on what makes the minimal and official/community compliant
metadata, than try and pin down every detail. I'd assumed that the
metadata would be in Ruby code, but equally happy with JSON or YAML.
Julian.
James Turnbull
For those of you who haven't seen the module metadata this is the
commit (in master and so scheduled for Rowlf not 0.25.2):
http://github.com/reductivelabs/puppet/commit/adc211ad191568e84eb3e1f618f1cbf78df95ba9
Regards
James Turnbull
--
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
Bruce Williams
wrote:
This is a topic that is sure to come up in more detail soon, as I'm
ramping up work on the [yet to be named] "module forge" and related
client tools.
I'd love to see some examples of what the community thinks should be
present in the metadata -- especially information beyond the
authorship and dependency information. Perhaps a wiki page is a good
place to start (focusing on the information to be supported -- not the
format, which is an implementation detail).
Cheers,
Bruce
--
Bruce Williams
http://reductivelabs.com
Al @ Lab42
On 21 Dic, 01:50, James Turnbull <ja...@lovedthanlost.net> wrote:
> 2009/12/21 Julian Simpson <simpsonjul...@gmail.com>:
> > 2009/12/18 Al @ Lab42 <lab42...@gmail.com>:
> > [snip]
> >> Now, as a user, I think that it is important to know how to start to
> >> write metadata files: format and minimal required parameters.
> >> A final (?) decision is not to be rushed, but an indication of the
> >> format and on some basic parameters that won't be changed for sure is
> >> definitively welcomed.
> >> If from this thread comes out an "officially Puppet complant" example
> >> of a metadata file I'm an happy guy.
>
> > +1.
>
> > Happy to agree the above. I'd rather specify less and get some broad
> > agreement on what makes the minimal and official/community compliant
> > metadata, than try and pin down every detail. I'd assumed that the
> > metadata would be in Ruby code, but equally happy with JSON or YAML.
>
> For those of you who haven't seen the module metadata this is the
> commit (in master and so scheduled for Rowlf not 0.25.2):
>
> http://github.com/reductivelabs/puppet/commit/adc211ad191568e84eb3e1f...
>
> Regards
>
> James Turnbull
>
> --
> Author of:
> * Pro Linux System Administration (http://tinyurl.com/linuxadmin)
> * Pulling Strings with Puppet (http://tinyurl.com/pupbook)
> * Pro Nagios 2.0 (http://tinyurl.com/pronagios)
> * Hardening Linux (http://tinyurl.com/hardeninglinux)
In order to have a real *correct* example of how a json metadata file
should be, according to what is written in
http://github.com/reductivelabs/puppet/blob/adc211ad191568e84eb3e1f618f1cbf78df95ba9/lib/puppet/module.rb
, I ask to the lurking Ruby and Puppet Gurus if something like what
follows could be a correct example of a metadata file.
The name of the file is MODULEPATH/metadata.json
The content (please review/fix):
{"apache": {
"source": "git://www.example42.com/example42puppetinfrastructure",
"author": "Alessandro Franceschi",
"version": "0.1.3",
"license": "GPL3",
"puppetversion": "0.24",
"summary": "Standard Apache module",
"description": "This module can be used for basic Apache
management",
"project_page": "http://www.example42.com",
}}
If we wanted to implement some of the suggestions people have made on
metadata info is something like this suitable (check syntax and
logic)? :
{"apache": {
"source": "git://www.example42.com/example42puppetinfrastructure",
"author": "Alessandro Franceschi",
"version": "0.1.3",
"license": "GPL3",
"puppetversion": "0.24",
"summary": "Standard Apache module",
"description": "This module can be used for basic Apache
management",
"project_page": "http://www.example42.com",
"dependencies": {
"native_types": [ "replaceline", "configfile" ] ,
"parsec_functions": "" ,
"modules": "" ,
"facter_plugins": "" ,
}
"tested": {
"centos": [ "4", "5" ] ,
"solaris": "5.10" ,
}
}}
And, if we wanted to give more info on classes and defines provided
with the module there should be detail for each class on the required/
optional parameters and eventually the same class dependencies (it's
not rare the case of a module with simple classes with no dependencies
and more complex classes with custom deps).
I suppose there's still much to talk and code around, but it would be
nice to have confirmations on this metadata format and maybe on some
of the proposed details.
Some references for Json:
http://www.json.org/
http://www.json.org/example.html
http://www.ietf.org/rfc/rfc4627.txt