FPM generate Puppet manifests about fpm HOT 12 CLOSED

Righto then; I'll see what I can come up with. What I had in mind for puppet was something that generates a puppet modules for each "package"

If you have other suggestions, let me know, otherwise that'll be my first target.

from fpm.

That was pretty much my vision - each package has a corresponding module.

from fpm.

+1 neat idea. Not sure what it looks like yet, but potentially really useful.

from fpm.

I'll be working on this during the fpm hackathon tomorrow at DevOpsDays

from fpm.

Beta results here: https://gist.github.com/1033869

Still to do:

• anticlasses for uninstalling a package
• figure out how to do versioning so you can do 'include nodejs::0.4.8::package' (which isn't valid puppet but is still the idea)

from fpm.

That's awesome! Will give it a try.

from fpm.

fpm 0.3.1 has puppet support with anti classes, but it's not very good.

You should be able to take any source type (dir, rpm, gem, etc) and produce a puppet module from it. Example:

# Build convert a 'puppet' rubygem to a puppet module
fpm -s gem -t puppet puppet

Missing:

• dependencies

Poorly implemented:

• some directories should be excluded, like "/usr" and such, but there's no automatic way we can do this reliably. This most poorly affects the 'anticlass' of foo::package::remove

from fpm.

With regards to the puppetsort def in /target/puppet.rb, can you provide an example of the sort of hash you envision passing ?

I'm big into standards and style adherence, so this topic hits home for me. ;)

from fpm.

@phrawzty: http://docs.puppetlabs.com/guides/style_guide.html#attribute-ordering

Basically, 'ensure' should be first and perhaps alphabetic after that - mainly i want consistent ordering that aligns with the puppet style guide.

from fpm.

The 'poorly implmeented' part mentioned above (/usr being in the directory list, etc) should be fixed by implementing "basedir" support that will help puppet, rpm, and solaris package targets (all of which can support some variant of "basedir")

from fpm.

I think a good way to handle versioning would be to output a parameterized class in the module. So this way you can pass it when you drop the class or use a sane default.

class { 'someclass':
version => 1.0,
}

Or just include someclass to use the default

from fpm.

fpm -t puppet was implemented long ago, but it's not well maintained. Fun proof of concept though.

from fpm.