cf-charmers team mailing list archive

[Whit Morriss <whit.morriss@xxxxxxxxxxxxx>]

I'm submitting this for discussion and hopefully to correct any mistaken
assumptions.  pretty basic stuff, but important to get clear to keep as
simple as possible.

After talking to Caleb and Matt today, it sounds like the high level
lifecycle will look like below.  Note I am assuming a 1x1 charm to job
mapping,
 - pivotal makes a new release of cf (represented by cf-release)
 - we bosh deploy the release to a working substrate (say AWS)
 - we use bosh to extract the the compiled packages created by said
deployment

At this point we have a couple choices:

 - fold the appropriate job data (monit, spec and templates) and compiled
package into the charm (ala a fat charm)
 - provide the job data and compiled packages as a resource pulled in by
each charm (call this smart?)

There is the question of exactly to digest cf-release.  Digging into
cf-release, I see dependency information enumerated in multiple spots (the
release file itself ala releases/cf-172.yml, the package file spec and the
jobs spec).

I'm assuming that by the time the packages are compiled, the only
dependency topology that matters for deployment is the one in the jobs
spec.   If this holds, could I assume that all we need for a single charm
is the appropriate job description and the compiled package (given we know
the source of both)?  If my assumptions are wrong, what mapping is correct
here?

Returning to the lifecycle,

  - we would create a  new release candidate of cf-bundle
  - update the fat or smart charms as necessary
  - push to our CI, rinse, repeat, release


-w

-- 
---------------
D. Whit Morriss
Developer, Juju Ecosystem
Canonical USA