Supplemental LXD Profiles Feedback

juju
,
1

Hello,

I was able to share a directory on my host with charmed applications running in lxd containers (localhost provider) using Juju’s built in mechanism for supplying a supplemental lxd profile as a file in the charm.

In my initial attempt to do this, I provided a lxd profile to the charm containing a disk device, where the source, /media is a directory on my host, and the path, /nfs is the target location in the container.

$ cat ../slurm-charms/charm-slurmd/lxd-profile.yaml 

config: {}
description: ""
devices:
  shared:
    path: /nfs
    source: /media
    type: disk
name: shared

I built the charm and deployed it, and was able to see the source file from the host in the desired target location in the container.

$ ls /media
myfile.txt

$ juju run --application slurmd "ls -la /nfs"
- Stdout: |
    total 6
    drwxrwxrwx  2 nobody nogroup 4096 Sep  3 22:00 .
    drwxr-xr-x 19 root   root      25 Sep  3 21:52 ..
    -rw-r--r--  1 root   root       0 Sep  3 22:00 myfile.txt
  UnitId: slurmd/0
- Stdout: |
    total 6
    drwxrwxrwx  2 nobody nogroup 4096 Sep  3 22:00 .
    drwxr-xr-x 19 root   root      25 Sep  3 21:55 ..
    -rw-r--r--  1 root   root       0 Sep  3 22:00 myfile.txt
  UnitId: slurmd/1
- Stdout: |
    total 6
    drwxrwxrwx  2 nobody nogroup 4096 Sep  3 22:00 .
    drwxr-xr-x 19 root   root      25 Sep  3 21:55 ..
    -rw-r--r--  1 root   root       0 Sep  3 22:00 myfile.txt
  UnitId: slurmd/2
- Stdout: |
    total 6
    drwxrwxrwx  2 nobody nogroup 4096 Sep  3 22:00 .
    drwxr-xr-x 19 root   root      25 Sep  3 21:55 ..
    -rw-r--r--  1 root   root       0 Sep  3 22:00 myfile.txt
  UnitId: slurmd/3

Using the lxd-profile.yaml file in the charm, I was able to accomplish sharing the host directory with the containers.

One drawback I found to providing lxd profiles to charmed applications in this way, is that you must rebuild a charm if you want to supply a different lxd profile. I feel like this experience of applying a supplemental lxd profile is powerful and that it could be more powerful if it was extended to be used in a more dynamic way other than having to bake the lxd-profile.yaml file into the charm.

Looking at the application-config, I’m thinking it may be a reasonable location to account for the lxd-profile such that a user might supply the supplemental lxd-profile at deploy time.

Example: juju deploy slurmd --lxd-profile="$(base64 my-lxd-profile.yaml)"

Where the lxd-profile is part of the application-config:

$ juju config slurmd

application: slurmd
application-config:
  trust:
    default: false
    description: Does this application have access to trusted credentials
    source: default
    type: bool
    value: false
  lxd-profile:
    default: ""
    source: default
    type: string
    description: Supplemental lxd profile directives.
    value: <base64-encoded-string>

Ultimately, I am wondering what others thoughts are concerning lxd-profile existing as an application-config?

Thanks

2 Likes
2

This is unlikely to be an avenue that we pursue.

There is already some tension around the fact that we have the trust article as part of application (as opposed to charm) config.

Trust itself is a big hammer - giving access to whatever the credential permits. In the case of K8s charms, it means access to the cluster that charms arguably shouldn’t have.

What is being talked about is a mechanism for declaring and providing specific permissions, something the LXD profile mechanism is an imperative tool for.

We actually had a request for a similar feature from our field team who wanted to be able to supply an alternative LXD profile to charm deployments so that the charm could access network file shares. At present, they are working around it using subordinates to change the profile.

1 Like
3

I would say that the “profile” concept in LXD opens up for something very similar to the AWS “instance-type”.

Why not use that as a capability of juju to be able to specify that as part of instantiation of a lxd-container and possibly also projects?

juju deploy ubuntu --constraints="lxd-profile=myprofile project=myproject"

This would be adding alot of dynamics to Juju in conjunction to LXD.

4

Makes sense. Thank you!