How to manage charm bundles

See also: Bundle


Create a bundle

To create a bundle, create a <bundle>.yaml file with your desired configuration.

If you don’t want to start from scratch, export the contents of your model to a <bundle>.yaml file via juju export-bundle --filename <bundle>.yaml or download the <bundle>.yaml of an existing bundle from Charmhub.

See more: Juju | How to compare and export the contents of a model to a bundle

See more: File <bundle>.yaml

Pack a bundle

To pack a bundle, in the directory where you have your bundle.yaml file (and possibly other files, e.g., a file), create a charmcraft.yaml file suitable for a bundle (at the minimum: type: bundle), then run charmcraft pack to pack the bundle. The result is a .zip file.

See more: charmcraft pack

Publish a bundle on Charmhub

The process is identical to that for a simple charm except that, at the step where you register the name, for bundles the command is register-bundle.

See more: How to publish a charm on Charmhub

1 Like

This page makes use of both the services and applications key. I think the services key is deprecated from what I understand. Should the instances where the services key is used be changed to applications just to be consistent?

Yes it should. Applications is the correct key to use.

Made the change from services to applications.

Is this right? Or should it be mariadb-pv,20M (so pool,size)?

Yes the pool should be first

Discussed with @jameinel and @simonrichardson: since Juju 2.9 it is necessary to set arch=amd64 on the applications too, not only on the machines, otherwise deploying on lxd containers will fail with

0/lxd/3  down                  pending              focal       need agent binaries for arch arm64, only found [amd64]

This is because by not having the architecture specified on the application, juju will by default think we are deploying amd64 applications. I believe this has to do with architecture-dependent charms on the new charmhub and I heard this is mentioned in Juju 2.9’s release notes. This should be reflected in these examples. Thanks!

You might be able to set a model constraint and thus have things deployed into that model default to the architecture you want. juju set-model-constraints arch=s390x is the sort of thing you should be able to specify.

Is it possible to specify a file with configuration options for a charm when using bundles?

For example:

    charm: "cs:mediawiki-5"
    num_units: 1
    options: ./mediawiki.config

Should be equivalent to juju deploy cs:mediawiki-5 --config ./mediawiki.config.

Is this possible in a bundle?

Not with that exact syntax. I believe you can use ‘include-file://’ and/or ‘include-base64://’ We have a test case for that here:

Now I believe it essentially just includes the file as though you had written the YAML content directly. So I believe it supports objects, but it might be that it only supports explicit keys. (eg the value for a key can be the contents of an included file)

This is very handy! I will test that!

edit: Unfortunately it is quite limited to reading strings only. This totally crashed:

$ cat bundle.yaml
    charm: grafana
      port: include-file://config

$ cat config

$ juju deploy --verbose ./bundle.yaml
Executing changes:
- upload charm grafana from charm-hub with architecture=amd64
- set application options for grafana
  setting options:
    port: "1234\n"
Deploy of bundle completed.

grafana was expecting an int but got a string with a \n in the end.

Should I create a bug report for this?

Also, I tried using the include-file in the options: include-file://config but that gave me an error:

ERROR cannot deploy bundle: cannot unmarshal bundle contents: unmarshal document 0: yaml: unmarshal errors:
  line 3: cannot unmarshal !!str `include...` into map[string]interface {}

Opened Bug #1964616 “add support for external files in the bundle” : Bugs : juju to track this :slight_smile: