cf-charmers team mailing list archive

[Alexander Lomov <lomov.as@xxxxxxxxx>]

Hello, Whit.

Sorry for the late answer, I'm sure this question should be
well-thought-out.

At the moment I can't see following:
1. how BOSH is able to extract the the compiled from the deployment.
2. why we can't delegate compiling sources from blobs to
launchpad. cf-release already have everything to do it automatically. In
this case you can get ubuntu package with version that will point to
cf-release version and install it from charm.
3. what are you going to do with config files, are you going
to maintain them manually or do you suggest any automation for it. we
already have tool that feels in all fields of cf-release templates with
necessary/default values (check it here
https://github.com/Altoros/cf-job2package-tool). I guess such thing can be
used to render config for particular charm after necessary relation is
added.


Best wishes,
Alex L.







On 4 June 2014 01:20, Whit Morriss <whit.morriss@xxxxxxxxxxxxx> wrote:

> 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
>
> --
> Mailing list: https://launchpad.net/~cf-charmers
> Post to     : cf-charmers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~cf-charmers
> More help   : https://help.launchpad.net/ListHelp
>
>