There are the annotations in Juju that aren't used for much but X/Y coordinates for the GUI to lay out services. There might be something really interesting in pulling charm metadata into annotations automatically at deployment time.
On Fri, Jun 17, 2016 at 9:17 AM Ryan Beisner <ryan.beis...@canonical.com> wrote: > On Fri, Jun 17, 2016 at 2:10 AM, Jay Wren <jay.w...@canonical.com> wrote: > >> If it helps, the charm set command supports arbitrary key values to be >> stored in extra-info in the charm store. >> >> e.g. >> >> $ charm set cs:~evarlast/trusty/parse-server-0 layer-x=rev1 layer-y=rev2 >> >> Then this will be displayed in extrainfo: >> >> $ charm show cs:~containers/trusty/swarm extra-info >> extra-info: >> layer-x: rev1 >> layer-y: rev2 >> >> After pushing, you could use set to save the revisions of what was used >> to build the charm. >> > > Thanks, Jay. There is some potential in that. I think it'd be worth > discussing some k:v norms around this that we can all gather around. Then, > perhaps more importantly, how that info will persist in the places where it > needs to be observed, such as: charm store ui, a pulled charm, and the > resulting deployments. > > > >> >> -- >> Jay >> >> On Thu, Jun 16, 2016 at 8:51 PM, Charles Butler < >> charles.but...@canonical.com> wrote: >> >>> Greetings, >>> >>> I deposit many of my layers in GitHub, and one of the things I've been >>> striving to do is keep tag releases at the revisions i cut a charm release >>> for a given channel. As we know, the default channel is seen by no-one, and >>> runs in increments of n+1. >>> >>> My prior projects i've been following semver for releases, but that has >>> *nothing* in terms of a breadcrumb trail back to the store. >>> >>> Would it be seen as good practice to tag releases - on the top most >>> layer of a charm - with what charm release its coordinated with? >>> >>> Given the scenario that i'm ready to release swarm, and lets assume that >>> to date i haven't tagged any releases in the layer repository: >>> >>> charm show cs:~containers/trusty/swarm revision-info >>> revision-info: >>> Revisions: >>> - cs:~containers/trusty/swarm-2 >>> - cs:~containers/trusty/swarm-1 >>> - cs:~containers/trusty/swarm-0 >>> >>> I see that i'm ready to push swarm-3 to the store: >>> >>> git tag 3 >>> git push origin --tags >>> >>> I can now correlate the source revision to what i've put in my account >>> on the store, but this does not account for promulgation (which has an >>> orthogonal revision history), and mis-match of those id's. >>> >>> I think this can simply be documented that tags track >>> <<username>>/<<charm>> pushes, and to correlate source with release, to use >>> the method shown above to fetch release info. >>> >>> Does this sound useful/helpful or am I being pedantic? (I say this >>> because Kubernetes touches ~ 7 layers, and it gets confusing keeping >>> everything up to date locally while testing, and then again re-testing with >>> --no-local-layers to ensure our repositories are caught up with current >>> development work. (Cant count the number of open pull requests hanging >>> waiting for review because we've moved to the next hot-ticket item) >>> >>> All the best, >>> >>> Charles >>> -- >>> Juju Charmer >>> Canonical Group Ltd. >>> Ubuntu - Linux for human beings | www.ubuntu.com >>> Juju - The fastest way to model your service | www.jujucharms.com >>> >>> -- >>> Juju mailing list >>> Juju@lists.ubuntu.com >>> Modify settings or unsubscribe at: >>> https://lists.ubuntu.com/mailman/listinfo/juju >>> >>> >> >> -- >> Juju mailing list >> Juju@lists.ubuntu.com >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/juju >> >> -- > Juju mailing list > Juju@lists.ubuntu.com > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/juju >
-- Juju mailing list Juju@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju
