How does LXD profiles really work?

I’m exploring the lxd-profile.yaml which is placed inside a charm which needs to deploy using an updated lxd-profile and have some initial questions:

  1. Can I have more than one profile for a charm, if so how?
  2. Can the docs Juju | Using LXD Profiles with Juju be updated with more examples since its a very powerful feature and I’m really missing examples as I’m exploring this.
  3. Is there more profiles added to a lxd model? It seems to be a “default” + “juju-modelname” + “juju--deploy-lxd-profile-” … this tells me that I can attach a “model” lxd profile somehow? Is this possible and if so how?
  4. Can I use --constraints to control lxd-profile behaviour?
  5. Which lxd profile has precedence if I modify a juju-model profile, vs, the charm lxd-profile.yaml?

I will probably have more questions here as I’m exploring here and adding to my example charms repo for ops.

I have found alot of very good information in the openstack charms on this topic which could be used here!

Here is the example charm I’m working on to cover the topic:

I could need some help to test the profiles I’ve documented in the repo.

@tmihoc @jnsgruk @manadart

1 Like

I’ll respond to these as both me and @hmlanigan implemented it many moons ago.

No, only one profile per charm. There is currently an ongoing debate about having multiple variations of profiles for one charm, but you’d only be able to apply one profile per charm.

Sure, that seems a reasonable ask.

So there is a hierarchy of profiles. LXD has its own default profile, then the model default profile (juju-<model-name>), and then a charm profile.

Interestingly, you can insert a model profile juju-<model-name> before you add the model, and juju won’t try and override it.

No, but I wish we had.

From the LXD documentation:

Profiles are applied in the order they are specified so the last profile to specify a specific key wins.

If you have any more questions, then fire away :smiley:


@simonrichardson @tmihoc These were wonderful answers and I will add them to my charm README.

However, it really deserves to be in the official documentation as these are questions that arises immediately when someone tries to implement any of this in charms even at such a rudimentary level.

All these hidden features really deserves to be brought forward. I will try my best to create these charms in my repo, but I also feel somewhat falling short since I don’t really know about them except from what I discover by trying to use them…

Juju applies lxd profiles in the following order: default, juju-, juju---. The application/charm lxd-profiles are applied in alphabetical order if more than one.

juju- profiles are only applied to lxd machines when the lxd provider is used. If you have an lxd container on a machine, it is not used. E.g. 0/lxd/1 would not have the model profile.

If a profile exists, juju does not attempt to overwrite it. Note that taking advantage of this and pre-creating a profile could make juju not work as expected.

If you add a profile to a juju machine outside of juju, it will be removed at some point in the future. Most likely when juju is upgraded or the machine is power cycled etc.