Some software, in order to operate properly, needs to be able to tweak the LXD profile used in deployment. There are an array of reasons from special kernel access for performance to allowing storage mounting that might pose a security risk in general but is expected behavior of a storage based Charm.
Using during development
Sample charm we use for testing:
Functionality available as of 29-Oct-2018:
- You can upload a charm which includes
lxd-profile.yamlto the charm store.
- Juju deploy a charm utilizing the lxd-profile with the lxd provider and to lxd containers.
- lxd-profile charms will be validated during deployment,
--forceis currently available.
- lxd-profile details available in juju show-machine.
- Upgrading a charm with an lxd-profile will update the profile applied to the unit’s machine. This includes removing a profile if the charm no longer has an lxd-profile and adding a profile if the charm now has one.
- Subordinate charms will apply a lxd profile, the same as a non subordinate.
Examples of Profile Adjustments
- OpenStack deployment: https://github.com/openstack-charmers/openstack-on-lxd/blob/master/lxd-profile.yaml
- conjure-up spells https://github.com/conjure-up/spells/blob/master/canonical-kubernetes/steps/00_process-providertype/lxd-profile.yaml
Charms gain the ability to specify a lxd-profile.yaml file in their root of the directory layout. This YAML file will be used to chain over on top of the existing Juju LXD profile as we’re only looking to provide additional functionality and not to make sure that things set by Juju are respected in the cases of security and more. LXD profiles are meant to be layered in such a way and so we should leverage the tooling there to help keep the layers on a container clean.
This means that if a charm is upgraded that the profile needs to be updated and we need to investigate if/how we can update the container with the correct profile. This is also true if another application is applied to the same container. We need to watch out for potential restarts of a container with a production workload that might be affected by a profile update.
The YAML file is expected to only be the keys needed and Juju will provide a unique name for the profile based on the charm so that it’s meaningful and able to be cleaned up upon removal of the application in question.
The name of the profile should also include the version of the charm so that future charm updates may permit the application of updated profiles and applications of mixed versions can function properly. In this way an Application might have in use a few different profiles at once.
If a charm is upgraded, once no unit references the previous profile it should be cleaned up and removed in the same vein.
Discerning a profile in use
The command juju show-machine shows the profile details as in current use when in the YAML/JSON output. In this way we can see what tweaks are being permitted and auditing of the container is easily accessible.
We have to be aware that it is possible to “hulk smash” charms onto the same container and they might have profiles including ones that conflict. For the scope of this current work we note that we should document that Hulk Smashing is not advised and since the profiles are layered on each other conflicts will be resolved by LXD during the merging of those.
Subordinates will also have the ability to provide a profile adjustment however their adjustments are applied to a related host. This might make checking that a profile is in use more interesting as it needs to be performed when the related application is made available in the model and not specifically when the subordinate is deployed since subordinates are unitless on the outset.
Removal of applications/upgrades
If an application is removed than the lxd-profile used should be removed from the host machine so that we do not keep an ever expanding list of profiles that may or may not be important to the current host machine.
Allowed keys for LXD profile
Juju will be opinionated on what keys you can set in your profile.yaml. If there is a key that is not allowed Juju will prevent the charm from deploying, the upgrade from occurring, etc.
- config (note ones below are excluded)
- devices of type
Escaping the allow-list
If you wish to set a profile config value that is not allowed you’ll need deployed with the --force argument on the deploy command. When a deploy is --forced the allow-list will be ignored and it will be logged with a WARNING that we’re skipping allow-list checks.
<implementation note @joe>
This should be simple if we use a consistent prefix for the profile names.
Profile type returned by LXD includes a
UsedBy slice. At an appropriate point (post remove/upgrade of units?) just delete each name-spaced profile without any containers listed.
If a profile was to go missing from disk Juju should be prepared to recreate it so that the model continues to operate correctly.
Out of scope
There is a separate feature for Juju that needs to be done to enable passing through of raw devices to containers. This feature would enable things like passing raw network and GPU devices for performance purposes. While LXD profiles are used to help set this up this feature does not directly enable binding devices into containers through the Juju language at this time. This is considered a more basic building block for just enabling customizing the profile in generic methods and leaves the work around devices to future efforts.