add label with ceph version string

[liewegas]

Right now the labels (as reported by podman inspect) look like:

            "Labels": {
                "CEPH_POINT_RELEASE": "",
                "GIT_BRANCH": "HEAD",
                "GIT_CLEAN": "True",
                "GIT_COMMIT": "3e4c74ab4205876cce4afd9c4051ac710a82973b",
                "GIT_REPO": "git@github.com:ceph/ceph-container.git",
                "RELEASE": "wip-cd-df40a49",
                "maintainer": "Dimitri Savineau \u003cdsavinea@redhat.com\u003e",
                "org.label-schema.build-date": "20190801",
                "org.label-schema.license": "GPLv2",
                "org.label-schema.name": "CentOS Base Image",
                "org.label-schema.schema-version": "1.0",
                "org.label-schema.vendor": "CentOS"
            },

For a ceph -v of ceph version 15.0.0-6884-gf0458b188a (d76dc026e8194928712f229afa002cf4005bb5df) octopus (dev), I'd like to add labels like the following:

• CEPH_VERSION - 15.0.0-6884-gf0458b188a
• CEPH_RELEASE - octopus
• CEPH_RELEASE_TYPE` -- dev (orrcorstable``)

Currently ceph-daemon is executing ceph -v inside the container to get this information, but simply extracting it from the container image metadata would be much faster!

[liewegas]

Also, not really sure what the purpose of CEPH_POINT_RELEASE is...

[sebastian-philipp]

cc @krig

[dsavineau]

Currently ceph-daemon is executing ceph -v inside the container to get this information, but simply extracting it from the container image metadata would be much faster!

The thing is that we probably can't do that during the container build (ie: install the package, run ceph -v and set the labels) otherwise it should have already been done. I'll try to take a look.
@leseb any thoughts on this ?

Also, not really sure what the purpose of CEPH_POINT_RELEASE is...

This variable is used when we want to build a specific ceph release (like: 14.2.3).

[liewegas]

The important one is CEPH_VERSION which is also the git describe string (minus the leading 'v')

[leseb]

The problem is that LABELS are generated as part of the Dockerfile, then we execute it to build. So we don't quite know which version we are getting IIRC, so this happens at build time.

[liewegas]

...but the get sha1 is there right? Or is that the commit for ceph-container (not ceph)?

[leseb]

...but the get sha1 is there right? Or is that the commit for ceph-container (not ceph)?

Yes, it's the sha1 of ceph-container (fetched at build time, since we build from that repo), not ceph.

[krig]

@leseb @liewegas @sebastian-philipp I have a tentative proposal for reading the ceph version from a io.ceph.version label if present on the container image here:

krig/ceph@782f0e0

What do you think? The idea is to use the label if set, but fall back to ceph -v if not.

It remains to set the label on the container image of course, with the openSUSE/SLE build chain we can do it quite easily but I'd have to look into how to do it on ceph-container (sounds non-trivial).

Right now the ceph version is the only label actually read by cephadm, so I thought it made sense to limit the initial work to just cover that one.

[liewegas]

The cephadm change looks good. We need to sort out how to add this label to the image though... @dsavineau @leseb ideas?

[dsavineau]

As mentioned earlier, getting those information (basically running ceph -v) before the build would require complexity and this isn't predictible.
The container file could be generated with information that don't reflect the ceph release installed in the container later.
As cephadm seems to support getting those information by running the ceph -v command (as ceph-ansible and rook) then I don't see the point to add this and add more complexity into the container build system.

[sebastian-philipp]

https://tracker.ceph.com/issues/43678

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[sebastian-philipp]

reopen please

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.