As requested by Victor, I'd like to start a conversation about the
idea of packaging barclamps as gems (which are then optionally
automatically wrapped in .rpms / .debs). This was first proposed a
*long* time ago by James Tan, and has occasionally surfaced in
conversations since then, but other than a few concerns being raised
which are likely surmountable, no progress has been made yet.
As I see it, re-using the gem mechanism and eco-system could be a big
win for the reasons I already stated in the other thread. Here's a
recap with additions (read to the end for more details about how it
could work):
- Any barclamp repo could easily be unit-tested standalone in Travis
simply by ensuring its Gemfile expressed the right dependencies
(e.g. on the core framework and barclamp gems), rather than the
awful https://github.com/crowbar/travis-ci-crowbar monolithic tree
flattening hack we were forced to build previously, which was
never able to automatically test pull requests.
- Dependencies could be expressed using version numbers adhering to
semantic versioning, which gives much more flexibility during
testing than a monolithic approach which insists git cloning an
exact set of commits/branches/tags from a set of remotes chosen
in an opinionated fashion using git submodule / subtree or ./dev.
- Doesn't reinvent any wheels.
- Proven technology already adopted by the whole Ruby community.
- Everyone already knows bundler / Gemfile etc. very well => very
shallow learning curve => more welcoming for newbies.
- No need for a git "meta" tool which clones lots of repositories;
this could be handled by a single Gemfile which points at the
relevant (repository, branch) tuples, plus "bundle config" for
any desired local overrides.
- No need for custom code which builds barclamp "packages" as
tar balls.
IIRC, the main objections are that barclamps contain more meta-data
and content than gems typically package:
- meta-data such as crowbar.yml, which includes:
- dependencies on debs / rpms
- dependencies on binary packages
- Chef cookbooks, roles, data bags etc.
- scripts in bin/, updates/ etc.
However I think these can all be handled pretty easily. Firstly there
is no restriction on what files you can put in a gem. Secondly, a
gem can be wrapped inside an rpm or deb which correctly reflects any
of the dependencies defined by the barclamp metadata. Tools such as
gem2rpm (and possibly gem2deb) already do a lot of the heavy lifting
for this - it's how we're able to maintain over 1000 gems as rpms
for our various SUSE distributions:
https://build.opensuse.org/project/show/devel:languages:ruby:extensions
.travis.yml would also require the correct package dependencies, and
if necessary a simple script could be hacked to auto-generate it.
Ensuring that all files get copied / moved / symlinked to the right
places (e.g. /opt/dell/chef) can still be done automatically at
package build-time by barclamp_install.rb - this is how we already do
it for SUSE Cloud. (Build-time is better than install-time because
then you don't get a bunch of files in /opt/dell untracked by rpm /
deb, and checksumming is important for supportability.)
Ensuring the cookbooks / roles / data bags get uploaded to Chef can
also be done automatically at package install-time by
barclamp_install.rb.
And finally, ensuring that barclamp_install.rb can still be run
standalone preserves the ability to develop directly from git without
requiring packages to be built every time you want to test a change.
_______________________________________________
Crowbar mailing list
[email protected]
https://lists.us.dell.com/mailman/listinfo/crowbar
For more information: http://crowbar.github.com/
