Regression: 3.x places incorrect metadata.yaml in built charm (2.5.3 works)
Metadata
Current evaluation
Fixed by #1524 (commit 9988b7db), preserving metadata generated by reactive builds; #1151 (35adadf4) provided the 2.x/edge fix.
Resolution: closed resolved
Reason: Merged PR #1524 at commit 9988b7db stopped packaging from overwriting an existing metadata.yaml, preserving the reactive-generated file. PR #1151 at commit 35adadf4 supplied the 2.x/edge correction.
Evaluated by: mr-cal-bot
No scores available.
Issue body
### Bug Description
This is a **regression**.
`charmcraft pack` for a reactive charm using 2.x/edge (2.5.3.post59+gb6e26ca) doesn't put the correct `metadata.yaml` into the built charm. It should be the `metadata.yaml` that the reactive plugin builds, but it's actually just the `metadata.yaml` from the top most reactive layer.
This means that the `metadata.yaml` is wrong and thus the charm won't actually work; e.g. in manila's case, the hacluster relation is missing, etc.
### To Reproduce
```bash
sudo snap refresh charmcraft --channel=2.x/edge
git clone "https://review.opendev.org/openstack/charm-manila"
charmcraft pack --bases-index=0
unzip -p manila_ubuntu-22.04-amd64.charm metadata.yaml > wrong.yaml
```
Save the `metadata.yaml`.
```bash
sudo snap refresh charmcraft --channel=2.x/stable
git clone "https://review.opendev.org/openstack/charm-manila"
charmcraft pack --bases-index=0
unzip -p manila_ubuntu-22.04-amd64.charm metadata.yaml > right.yaml
```
Compare two files.
### Environment
* Ubuntu 22.04 LTS
* LXD
### charmcraft.yaml
```shell
type: charm
parts:
charm:
plugin: reactive
reactive-charm-build-arguments:
- --binary-wheels-from-source
- --verbose
- --verbose
build-packages:
- tox
- git
- python3-dev
- libffi-dev
- libssl-dev
- rustc
- cargo
- pkg-config
source: src/
build-snaps:
- charm/latest/edge
build-environment:
- CHARM_INTERFACES_DIR: $CRAFT_PROJECT_DIR/interfaces/
- CHARM_LAYERS_DIR: $CRAFT_PROJECT_DIR/layers/
bases:
- build-on:
- name: ubuntu
channel: "22.04"
architectures: [amd64]
run-on:
- name: ubuntu
channel: "22.04"
architectures: [amd64]
- build-on:
- name: ubuntu
channel: "22.04"
architectures: [s390x]
run-on:
- name: ubuntu
channel: "22.04"
architectures: [s390x]
- build-on:
- name: ubuntu
channel: "22.04"
architectures: [ppc64el]
run-on:
- name: ubuntu
channel: "22.04"
architectures: [ppc64el]
- build-on:
- name: ubuntu
channel: "22.04"
architectures: [arm64]
run-on:
- name: ubuntu
channel: "22.04"
architectures: [arm64]
- build-on:
- name: ubuntu
channel: "23.04"
architectures: [amd64]
run-on:
- name: ubuntu
channel: "23.04"
architectures: [amd64]
- build-on:
- name: ubuntu
channel: "23.04"
architectures: [s390x]
run-on:
- name: ubuntu
channel: "23.04"
architectures: [s390x]
- build-on:
- name: ubuntu
channel: "23.04"
architectures: [ppc64el]
run-on:
- name: ubuntu
channel: "23.04"
architectures: [ppc64el]
- build-on:
- name: ubuntu
channel: "23.04"
architectures: [arm64]
run-on:
- name: ubuntu
channel: "23.04"
architectures: [arm64]
- build-on:
- name: ubuntu
channel: "23.10"
architectures: [amd64]
run-on:
- name: ubuntu
channel: "23.10"
architectures: [amd64]
- build-on:
- name: ubuntu
channel: "23.10"
architectures: [s390x]
run-on:
- name: ubuntu
channel: "23.10"
architectures: [s390x]
- build-on:
- name: ubuntu
channel: "23.10"
architectures: [ppc64el]
run-on:
- name: ubuntu
channel: "23.10"
architectures: [ppc64el]
- build-on:
- name: ubuntu
channel: "23.10"
architectures: [arm64]
run-on:
- name: ubuntu
channel: "23.10"
architectures: [arm64]
```
### Relevant log output
```shell
Right.yaml
"name": "manila"
"summary": "A REST API for folder shares"
"maintainer": "OpenStack Charmers <openstack-charmers@lists.ubuntu.com>"
"description": |
Shared File Systems service provides a set of services for management of
shared file systems in a multi-tenant cloud environment. The service resembles
OpenStack block-based storage management from the OpenStack Block Storage
service project. With the Shared File Systems service, you can create a remote
file system, mount the file system on your instances, and then read and write
data from your instances to and from your file system.
"tags":
- "openstack"
"series":
- "jammy"
- "lunar"
- "mantic"
"requires":
"certificates":
"interface": "tls-certificates"
"shared-db":
"interface": "mysql-shared"
"amqp":
"interface": "rabbitmq"
"identity-service":
"interface": "keystone"
"ha":
"interface": "hacluster"
"scope": "container"
"neutron-plugin":
"interface": "neutron-plugin"
"scope": "container"
"manila-plugin":
"interface": "manila-plugin"
"scope": "container"
"remote-manila-plugin":
"interface": "manila-plugin"
"provides":
"nrpe-external-master":
"interface": "nrpe-external-master"
"scope": "container"
"peers":
"cluster":
"interface": "openstack-ha"
"extra-bindings":
"public": !!null ""
"admin": !!null ""
"internal": !!null ""
"subordinate": !!bool "false"
wrong.yaml
name: manila
summary: A REST API for folder shares
maintainer: OpenStack Charmers <openstack-charmers@lists.ubuntu.com>
description: |
Shared File Systems service provides a set of services for management of
shared file systems in a multi-tenant cloud environment. The service resembles
OpenStack block-based storage management from the OpenStack Block Storage
service project. With the Shared File Systems service, you can create a remote
file system, mount the file system on your instances, and then read and write
data from your instances to and from your file system.
tags:
- openstack
series:
- jammy
- lunar
- mantic
subordinate: false
requires:
shared-db:
interface: mysql-shared
amqp:
interface: rabbitmq
identity-service:
interface: keystone
neutron-plugin:
interface: neutron-plugin
scope: container
manila-plugin:
interface: manila-plugin
scope: container
remote-manila-plugin:
interface: manila-plugin
provides:
nrpe-external-master:
interface: nrpe-external-master
scope: container
```
Evaluation history
| Date | Model | Scores | Action | Summary |
|---|---|---|---|---|
| stealth/space-bunny-alpha | — | closed resolved | Fixed by #1524 (commit 9988b7db), preserving metadata generated by reactive builds; #1151 (35adadf4) provided the 2.x/edge fix. | |
| stealth/space-bunny-alpha | — | closed resolved | Fixed by canonical/charmcraft#1524 (commit 9988b7db), preserving charm-tools' generated metadata.yaml instead of overwriting it with the top-layer copy. | |
| stealth/space-bunny-alpha | — | closed resolved | Reactive metadata was overwritten by the top-level layer file; #1524 (9988b7db) preserved generated metadata, and #1151 (35adadf4) fixed 2.x/edge. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Fixed in 2.x/edge after correcting a misdeployed branch. The regression caused charmcraft 3.x to incorrectly package the top-level metadata.yaml instead of the reactive plugin output. Follow-ups were separate configuration issues. | |
| qwen/qwen3.6-35b-a3b | — | — | Fixed by correcting the branch deployment for the 2.x/edge snap. Subsequent reports were identified as separate configuration issues. The original metadata.yaml regression was resolved in the updated 2.x/edge build. | |
| qwen/qwen3.6-35b-a3b | — | — | Fixed by correcting the branch deployment in 2.x/edge. The regression causing incorrect metadata.yaml in reactive charms was resolved. Later reports were deemed separate configuration issues. | |
| qwen/qwen3.6-35b-a3b | — | — | Fixed in 2.x/edge channel. Refresh to that version to resolve the regression where charmcraft 3.x incorrectly placed metadata.yaml instead of the reactive plugin output. Related reports were redirected to a new issue. | |
| qwen3.6-35b-a3b-mtp-q6 | — | — | Fixed the regression causing incorrect metadata.yaml in reactive charms by correcting the 2.x/edge branch deployment. Follow-ups were identified as separate issues and directed to new tickets. Closed. |
Update history
No update history recorded yet.
Related work
-
Likely Fixed By:
canonical/charmcraft#1524
(confidence 100%)
Merged fix preventing packaging from overwriting metadata generated by a reactive build.
-
Likely Fixed By:
canonical/charmcraft#1151
(confidence 95%)
Stopped metafile generation during reactive builds and addressed the 2.x/edge regression.
Related issues
| Issue | Project | State | Summary | Similarity |
|---|---|---|---|---|
| #1666 fix: only keep metadata.yaml for reactive charms | charmcraft | merged | Merged #1666 (b2b127e6), retaining metadata.yaml only for reactive charms so non-reactive repacks no longer carry stale integration metadata; fixes #1654. | |
| #2502 fix: add missing build metadata in reactive charm artifacts | charmcraft | open | Adds .build.manifest preservation and charmtool_version to manifest.yaml for reactive charms. Under active review with 4 unresolved comments; most CI checks pending. |