Revision file on charms

[Kapil Thangavelu]

On Mon, Sep 8, 2014 at 4:00 PM, Simon Davy <bloodearnest at gmail.com> wrote:

> On 8 September 2014 15:40, Matt Bruzek <matthew.bruzek at canonical.com>
> wrote:
> > José
> >
> > I just had a conversation about that with the Ecosystems team.  You are
> > correct, the revision file in the charm directory is no longer used and
> we
> > can delete those files on future updates.
>
> So this is interesting, as we are looking to start using the revision
> file more explicitly, as part of our automation.
>
> We deploy from local repositories, with charms in bzr, and one thing
> we would like to explicitly know which *code* revision is currently
> deployed in an environment.
>
> So we were thinking to have a pre-deploy step that did "$(bzr revno) >
> revision"  in each charm, just before deploy/upgrade. That way, the
> revision reported by juju status gives us the exact code revision of
> the the current charm. This would pave the way for us to diff a
> current environment with a desired one and see what charms need
> changing as part of a deploy.
>
> Does this make sense? Is there some other method of knowing the code
> branch/revision a charm is currently running?
>
>
you need to keep in mind the revision file will never match a local charm
version in the state server (it will at min be at least one higher than
that). This goes back to removing the need for users to manage the revision
file contents while in development or pass in the upgrade flag during dev,
the need was obviated by having the state server control the revision of
the charm.

i filed https://bugs.launchpad.net/juju-core/+bug/1313016 to cover this
case for deployer, so it could annotate vcs charms with their repo and rev
since local charm revisions are useless for repeatability as their
independent of content and determined soley by the state server (with the
revision file serving as a hint for min sequence value) and the available
charms in the state server are not introspectable.

cheers,

Kapil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju/attachments/20140908/678624fb/attachment.html>