charms should be able to expose version information about themselves (e.g. in juju status)

[James Troup]

Charms should be able to expose version information about themselves to users. This would trivially allow one to know what version of the OpenStack charms one is using for example.

(I know there's a 'charm' and 'charm-rev' field already in juju status but these aren't helpful in identifying the version of the charms.)

[John A Meinel (jameinel)]

They currently do have a way to expose payload versions (I'm running
"postgres 9.1.2" for xenial/postgreqsl-25)

Is that sufficient, or is that confusing the "version of the charm" with
the "version of the payload". Given your comment about "Openstack Charm"
what are you looking to expose "I would support Mitaka if you wanted it,
even though you're only running Liberty".

On Sun, Apr 8, 2018 at 1:02 AM, James Troup <email address hidden>
wrote:

> Public bug reported:
>
> Charms should be able to expose version information about themselves to
> users. This would trivially allow one to know what version of the
> OpenStack charms one is using for example.
>
> (I know there's a 'charm' and 'charm-rev' field already in juju status
> but these aren't helpful in identifying the version of the charms.)
>
> ** Affects: juju
> Importance: Undecided
> Status: New
>
> --
> You received this bug notification because you are subscribed to juju.
> Matching subscriptions: juju bugs
> https://bugs.launchpad.net/bugs/1762069
>
> Title:
> charms should be able to expose version information about themselves
> (e.g. in juju status)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/juju/+bug/1762069/+subscriptions
>

[John A Meinel (jameinel)]

For example, we could produce the hash of the charm contents, as a way to
define "identity". However, that wouldn't give you nice
human-understandable identifiers. And any other identifier that would be
human-readable would probably require some sort of process to make sure it
gets updated when it needs to (I changed the charm content, did you bump
the version number?) so that you can trust it accurately represents what
you want.

The short-term thing that supports most of it would be charm-config that
defines whatever you want, which you can then update with "juju config app
charm-identiifer=X" and read with "juju config app charm-identifier".
But very much there is a lot of potential failure modes where it doesn't
get set when it needs to, and thus is stale and not reliable.
Having the charm be able to report something could also be done simply as a
standard action "juju run --application=app charm-identify"

There would still need to be some sort of charm build process that would
produce an identifier for the built charm (that is about to be deployed)
that would be stable and repeatable and trustable.

We can certainly start exposing something in status, but until we've worked
out what would be put there, it seems better to iterate on some of these
other mechanisms that don't require Juju changes.

On Mon, Apr 9, 2018 at 8:37 AM, John Meinel <email address hidden> wrote:

> They currently do have a way to expose payload versions (I'm running
> "postgres 9.1.2" for xenial/postgreqsl-25)
>
> Is that sufficient, or is that confusing the "version of the charm" with
> the "version of the payload". Given your comment about "Openstack Charm"
> what are you looking to expose "I would support Mitaka if you wanted it,
> even though you're only running Liberty".
>
>
>
> On Sun, Apr 8, 2018 at 1:02 AM, James Troup <email address hidden>
> wrote:
>
>> Public bug reported:
>>
>> Charms should be able to expose version information about themselves to
>> users. This would trivially allow one to know what version of the
>> OpenStack charms one is using for example.
>>
>> (I know there's a 'charm' and 'charm-rev' field already in juju status
>> but these aren't helpful in identifying the version of the charms.)
>>
>> ** Affects: juju
>> Importance: Undecided
>> Status: New
>>
>> --
>> You received this bug notification because you are subscribed to juju.
>> Matching subscriptions: juju bugs
>> https://bugs.launchpad.net/bugs/1762069
>>
>> Title:
>> charms should be able to expose version information about themselves
>> (e.g. in juju status)
>>
>> To manage notifications about this bug go to:
>> https://bugs.launchpad.net/juju/+bug/1762069/+subscriptions
>>
>
>

[James Troup (elmo)]

John A Meinel <email address hidden> writes:

> They currently do have a way to expose payload versions (I'm running
> "postgres 9.1.2" for xenial/postgreqsl-25)
>
> Is that sufficient, or is that confusing the "version of the charm" with
> the "version of the payload". Given your comment about "Openstack Charm"
> what are you looking to expose "I would support Mitaka if you wanted it,
> even though you're only running Liberty".

Some charms (or usually sets of charms) are their own software
projects. As such, they have releases¹, release schedules² and
version numbers³. The canonical (lower case c) example of this is the
OpenStack charms⁴.

It's not about the payload/workload version as charms with their own
version often support running any one of multiple payload/workload
versions.

I would like such charms to be able to expose their own version number
to the end user. This would be an optional field which may not be
used at all by the majority of charms, but I think that's OK.

--
James

¹ https://docs.openstack.org/charm-guide/latest/release-policy.html
² https://docs.openstack.org/charm-guide/latest/release-schedule.html
³ https://docs.openstack.org/charm-guide/latest/1802.html
⁴ https://docs.openstack.org/charm-guide/latest/openstack-charms.html

[Tim Penhey (thumper)]

It seems like this is something to add to the metadata.yaml aspect for
charms.

It would be relatively easy to add to that, but the question becomes
where we show this.

Adding to juju status --format=yaml would be easy, but we have less
space in the tabular format for status. Would you expect to see it there
too?

Tim

[James Troup (elmo)]

Tim Penhey <email address hidden> writes:

> It seems like this is something to add to the metadata.yaml aspect
> for charms.
>
> It would be relatively easy to add to that, but the question becomes
> where we show this.
>
> Adding to juju status --format=yaml would be easy, but we have less
> space in the tabular format for status. Would you expect to see it
> there too?

My primary concern is that it's available in the JSON/YAML but having
it in tabular would be a nice bonus, but I agree that we're running
out of space. Looking at a random cloud¹, I see a couple of options:

 1) extend the Rev column to be either $CHARM_VERSION-$REV or
    $CHARM_VERSION/$REV, falling back to just $REV (as it is now) if
    no $CHARM_VERSION is specified.

    (This is obviously not backwardly compatible, but then I don't
     think people should expect backward compatible from tabular
     format.)

 2) What is 'Notes'? In any event, either put it before or instead of
    'Notes'.

But as I said, if neither of these appeal, I'm fine with it just being
in the JSON/YAML status.

Thanks.

--
James

¹ https://pastebin.canonical.com/p/XBWDvGXnpN/

[Canonical Juju QA Bot (juju-qa-bot)]

This bug has not been updated in 2 years, so we're marking it Low importance. If you believe this is incorrect, please update the importance.