Change LXC container '.config."image.description"' after do-release-upgrade

LXD
1

I’m having a feeling of dejavu but I can find the question I’m having dejavu about. So here goes aagain, I think…

I’ve just finished upgrading a container that was previously deployed as Ubuntu 16.04 LTS. After upgrading, I ran the following command:

$ lxc query -X GET /1.0/containers/myContainer | jq '.config."image.description"'
"ubuntu 16.04 LTS amd64 (release) (20180522)"

I note that there are 2 config sections: config and expanded_config

Is it possible to edit these field so that they reflect the state of affairs inside the container - i.e. Ubuntu 20.04 LTS?

2

Yep, lxc config edit will let you change them.
If you’re ever planing on exporting that container into a new image, you probably should also do lxc config metadata edit to change the future image metadata.

3

Thanks @stgraber

Is there a tool one can download to make the appropriate changes once a container OS has been upgraded or is it left as an exercise for server admins to create their own tooling?

I have this feeling that promoting sysadmin laziness isn’t at the top of your agenda and I totally get that. However, reinventing the wheel, especially a crappy version, is something I’d prefer to avoid.

4

I’m not aware of any automated tooling for this currently.

The simplest would be for the guest to be able to directly update its config through /dev/lxd but that’s not something we’ve been very keen on allowing as that could easily be used to attack/DoS LXD.

I’m sure you could script something with lxc exec running lsb_release or reading /etc/os-release and then calling lxc config set to update the relevant config keys, but it’s not something I’ve ever done myself or that we’ve heard someone write so far.

If you do go down that path, please post the script here or on Github so others can find it :slight_smile:

5

Thanks for that suggestion - that’s exactly what I’ve done. Interesting to note though is that lxc config metadata doesn’t have a set method so messing with that now.

I’ll definitely share what I come up with most likely on Github.

Thanks again.

6

Ah yeah, that’s because lxc config metadata is pretty rough, it’s basically directly letting you replace a text file in the instance data, there’s no actual parsing or validation on the data, just file transfer.

Note that you should be able to pipe the replacement content to lxc config metadata edit though but you’ll need to get the data with lxc config metadata show, mangle it and then push with lxc config metadata edit.