heavywater/pennyworth — Issue #21: META - Project activity
Author: patcon
Created: 2012-01-11 21:47:03+00:00
State: open

Hey guys, I've got some questions. I'm trying to use pennyworth internally at my organization (and for the [FGA project](http://projects.occupy.net/projects/fga), which I'd mentioned to AJ), but as wonderful as it is, I'm finding it to be not as modular as I'd hoped. This is leading to me picking away at it locally in a way that feels very divergent from your effort (although only organizationally, and without changing the actual "product"). Was just wondering whether you'd be open to making it more compartmentalized and grokable, as I'm otherwise probably going to need to fork my efforts and give up any pretense of contributing back. Which would be lame.

A couple points (same admittedly personal taste):

* roles should be json, so they can be version controlled better (changes made through chef web UI can be pulled back into code)
* with most cookbooks, each recipe is usually a minimal piece of functionality, or a specific fork of a functional unit (ie source.rb vs package.rb in php's default cookbook). Would you be averse to my putting pennyworth into such a setup? Small example, dependencies.rb could never really run on it's own
* ssh_key.rb seems to repeat lots of what's already in the jerkins::default, but simply adds a place to drop in known_hosts and config files. Could this not be a much smaller recipe that runs after jerkins::default? ssh-keyscan can be used to generate known_hosts dynamically…
* leiningen recipe is required in default (should be separate or in databag option)
* .gnupg manipulation happens in jenkins default. Could this not go in gpg cookbook, ie. attribute for user to run gpg commands, so files are generated in that users $HOME? Seem more appropriate to do this, then set that attribute to be the jenkins user from within the pennyworth recipe.
* instead of using sudoers.d (which only works on natty, I believe), use the sudo cookbook, and submit a pull request to accomodate cmnd aliases?
* there are some deps built into pennyworth (gems/packages/cookbooks) that assume I want to build something specific. Could be not try to move some of that stuff out? Maybe have a container role called pennyworth_android, or use databags to define deps based on intended build use, or whatever?
* librarian would make it SOOO much simpler for other people to take what you've done and merge it into their infra. You have some hacked cookbooks with odd versionings, and that doesn't bestow confidence to someone looking to "come along for the ride" and use your configs with the expectation of benefiting from improvements.
* your knife plugin could be deployed more like the ohai cookbook is:
https://github.com/opscode/cookbooks/blob/master/ohai/recipes/default.rb
(we could write a "knife" cookbook for installing knife plugins remotely)

It's easier for me to just start my own effort at this point, but I'd honestly rather contribute back. I'm totally willing to help, but I'm clarifying ahead of time because I'd really rather not try to fit my work into the pennyworth paradigm unless you guys are amenable to some rather obtrusive changes. I haven't always heard back from my input in the issues, so I'm not really clear whether you actively dogfood with pennyworth and seek to improve it as a general tool, or whether it's a codebase you simply pulled out of your own infra and don't actually depend on internally. If you've got your own codebase and you're not using the pennyworth codebase yourself, I guess I just think that's important for me to know, as it sets expectations on responsiveness, etc.

Anyhow, thanks guys. Sorry for the journal, just that a bunch of smaller issues seemed overboard when the answer might just be that you're not able to actively support. If you'd be cool with doing a skype call or IRC chat to speed up the "getting on the same page", I'd be down for that! Regardless, if you're up for it, I'll get to work gathering all this shit together and pushing it public :)