How to manage a charm bundle

See also:

Contents:

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:

applications:
  mediawiki:
    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: https://github.com/juju/juju/blob/5c2de081e2d217c5142bd04feff88524288b1a81/cmd/juju/application/bundle/bundle_test.go#L241-L257

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
applications:
  grafana:
    charm: grafana
    options:
      port: include-file://config

$ cat config
1234

$ 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: