[bosh-users] Desired Feature: bosh package release

On Wednesday, January 9, 2013, wrote:
Hi,

After having to mess around with using different VMs/laptops for different parts of the create/deploy process, I had the idea that I could package a release into a tarball and distribute that, just like you can distribute a stemcell. That is, when I do $bosh upload release and I see
Copying packages
...
Building tarball
----------------
Generated /tmp/d20130110-9288-3jg7h0/d20130110-9288-193ciw3/release.tgz
Release size: 1.5G
...
Uploading release
release.tgz: 2% | | 32.3MB 825.8KB/s ETA: 00:31:53
...

Then I'd rather do
$bosh package release
Copying packages
...
Building tarball with every "FOUND LOCAL" package and job
----------------
Generated /output_directory/release.tgz
Release size: 1.5G

$bosh upload release /output_directory/release.tgz
Verifying release...
File exists and readable OK
Extract tarball OK
Manifest exists OK
Release name/version OK
...
Uploading release
release.tgz: 20% |oooo | 316.6MB 822.5KB/s ETA: 00:26:07


That may open up future things like $bosh download public releases

Just a thought

On Jan 9, 2013, at 9:52 PM, Matthew Kocher wrote:

Agreed, sharing compiled packages somewhere central makes a lot of sense. I think they can only be use if the stemcells are exactly the same however, as we can't know if all the shared libraries are the same on an upgraded stemcell.

I'd love if the package cache could just be a blobstore with no server in front of it with well defined file names (eg, stemcell-bosh-stemcell-aws-0.6.4-sha1ofstecell-postgres-9-1-sha1ofpostgres). I think at the moment bosh doesn't assume it can chose a filename in the blobstore, but I'm not sure where that restriction comes from.

On Wed, Jan 9, 2013 at 8:55 PM, Martin Englund wrote:

the second part is something I've thought about a lot when testing micro
bosh stemcells. The way it works now, every package gets recompiled
whenever you build a new stemcell, even if the base OS hasn't changed. You
also have excessive compiling when you have multiple bosh directors
deploying the same release (using the same stemcell).

On Wed, Jan 9, 2013 at 11:09 PM, James Bayer wrote:

Off-topic. Speaking of blob stores, just for fun you can take a look at
this next-gen blob store called camilstore under development by Brad
Fitzpatrick that Adrian Crockcoft retweeted tonight that I thought was
interesting.
http://camlistore.org/talks/2011-05-07-Camlistore-Sao-Paolo/#1

Thank you,

James Bayer


On Jan 9, 2013, at 9:52 PM, Matthew Kocher <mkocher@pivotallabs.com>
wrote:

Agreed, sharing compiled packages somewhere central makes a lot of sense.
I think they can only be use if the stemcells are exactly the same
however, as we can't know if all the shared libraries are the same on an
upgraded stemcell.

I'd love if the package cache could just be a blobstore with no server in
front of it with well defined file names (eg,
stemcell-bosh-stemcell-aws-0.6.4-sha1ofstecell-postgres-9-1-sha1ofpostgres).
I think at the moment bosh doesn't assume it can chose a filename in the
blobstore, but I'm not sure where that restriction comes from.

On Wed, Jan 9, 2013 at 8:55 PM, Martin Englund wrote:
the second part is something I've thought about a lot when testing micro bosh stemcells. The way it works now, every package gets recompiled whenever you build a new stemcell, even if the base OS hasn't changed. You also have excessive compiling when you have multiple bosh directors deploying the same release (using the same stemcell).