Distro package manager vs moving dependency source around with the release.

[Bill Chapman]

I'm trying to button up my first BOSH release.  I was just going through the process (mostly academically) and packaging up a release for Solr just to learn the ropes.  I understand why we would want to package up the source with the release instead of relying on one of the inconsistent package managers but I'm wondering if an argument could be made for using the distribution's packaging for fairly stable and ubiquitous packages like java, apache etc... 

From the examples I was following I'd have to track and update the source files in my release. I understand that this will create stability for the release, speed of deployment and  play well with the packaging and droplet creation but wouldn't targeting the latest stable release for your target platform's package management system ensure you have the best release for that platform with any optimizations that may have been used? 

If you are managing your own releases this makes sense,  you would often want to peg the libraries and versions of your production dependencies but if you are trying to create a BOSH release for more generalized use by others does this still hold? For example, if I wanted to create a general and reuseable release for Solr I would have to include both 64 and 32 bit source for the JRE in order to ensure wide platform compatibility when I could rely on package management to decide which version to install. 

I guess my question is, from a bosh development perspective,  would it ever make sense to have a way to compile the release via the target distribution's package management on one of your compilation nodes and include a description of how to package up the resultant items for staging from wherever the target platform has stashed them?

- Bill

[Dr Nic Williams]

Interestingly to experiment with apt packages in bosh releases I added --apt option to "bosh-gen package" recently. Seems work pretty ok. All the required .deb are stored in the blobs/ folder and installed during packaging script execution.

The main differences are:

* files are installed into /var/vcap/packages/NAME/apt rather than / (root)

* the .deb packages probably still generate some default configuration files; and you really still want to do this yourself via a bosh release job; using monit to start/stop.

Let me know how it goes.

To unsubscribe from this group and stop receiving emails from it, send an email to bosh-dev+u...@cloudfoundry.org.

[James Bayer]

you stark and wayne people always ask the same questions [1]! that's how i know you're smart, pragmatic and deep thinkers! read this response to a similar question from wayne in december as he was coming up to speed about bosh.

i even decided to write a blog about it this time: Remote Dependencies, Convenience, Risk and Other Considerations for Operating Distributed Systems [2]. i don't think there is necessarily any perfect answer, just tradeoffs to consider.

[1] https://groups.google.com/a/cloudfoundry.org/d/msg/bosh-users/hpVl7AYJIfE/dtDnmXNC2FUJ

[2] http://blog.cloudfoundry.com/2014/02/03/remote-dependencies-convenience-risk-and-other-considerations-for-operating-distributed-systems/

--

Thank you,

James Bayer

[Wayne E. Seguin]

Very good / educational read James, thanks for sharing the perspective!