Open DanielDewberry opened 2 months ago
The issue is in the images_aliases
table. When a POST request is made to /1.0/images/aliases, the image_id
column is overwritten.
kadinsayani@devbox:~/canonical/lxd$ lxc image copy ubuntu:jammy local: --copy-aliases --vm
Image copied successfully!
kadinsayani@devbox:~/canonical/lxd$ lxd sql global 'select * from images_aliases'
+----+-------------+----------+-------------+------------+
| id | name | image_id | description | project_id |
+----+-------------+----------+-------------+------------+
| 31 | 22.04 | 15 | | 1 |
| 32 | 22.04/amd64 | 15 | | 1 |
| 33 | j | 15 | | 1 |
| 34 | j/amd64 | 15 | | 1 |
| 35 | jammy | 15 | | 1 |
| 36 | jammy/amd64 | 15 | | 1 |
+----+-------------+----------+-------------+------------+
kadinsayani@devbox:~/canonical/lxd$ lxc image copy ubuntu:jammy local: --copy-aliases
Image copied successfully!
kadinsayani@devbox:~/canonical/lxd$ lxd sql global 'select * from images_aliases'
+----+-------------+----------+-------------+------------+
| id | name | image_id | description | project_id |
+----+-------------+----------+-------------+------------+
| 37 | 22.04 | 10 | | 1 |
| 38 | 22.04/amd64 | 10 | | 1 |
| 39 | j | 10 | | 1 |
| 40 | j/amd64 | 10 | | 1 |
| 41 | jammy | 10 | | 1 |
| 42 | jammy/amd64 | 10 | | 1 |
+----+-------------+----------+-------------+------------+
I see two options forward:
1) Separate images_aliases
into two distinct tables, container_images_aliases
and vm_images_aliases
; or
2) Separate the image_id
column into two distinct columns, container_image_id
and vm_image_id
(less overhead with this option).
In either case, an alias with the same name could belong to both a container and VM.
Which option would be preferable? cc. @tomponline @hamistao
The issue is in the
images_aliases
table. When a POST request is made to /1.0/images/aliases, theimage_id
column is overwritten.kadinsayani@devbox:~/canonical/lxd$ lxc image copy ubuntu:jammy local: --copy-aliases --vm Image copied successfully! kadinsayani@devbox:~/canonical/lxd$ lxd sql global 'select * from images_aliases' +----+-------------+----------+-------------+------------+ | id | name | image_id | description | project_id | +----+-------------+----------+-------------+------------+ | 31 | 22.04 | 15 | | 1 | | 32 | 22.04/amd64 | 15 | | 1 | | 33 | j | 15 | | 1 | | 34 | j/amd64 | 15 | | 1 | | 35 | jammy | 15 | | 1 | | 36 | jammy/amd64 | 15 | | 1 | +----+-------------+----------+-------------+------------+ kadinsayani@devbox:~/canonical/lxd$ lxc image copy ubuntu:jammy local: --copy-aliases Image copied successfully! kadinsayani@devbox:~/canonical/lxd$ lxd sql global 'select * from images_aliases' +----+-------------+----------+-------------+------------+ | id | name | image_id | description | project_id | +----+-------------+----------+-------------+------------+ | 37 | 22.04 | 10 | | 1 | | 38 | 22.04/amd64 | 10 | | 1 | | 39 | j | 10 | | 1 | | 40 | j/amd64 | 10 | | 1 | | 41 | jammy | 10 | | 1 | | 42 | jammy/amd64 | 10 | | 1 | +----+-------------+----------+-------------+------------+
I see two options forward:
1. Separate `images_aliases` into two distinct tables, `container_images_aliases` and `vm_images_aliases`; or 2. Separate the `image_id` column into two distinct columns, `container_image_id` and `vm_image_id` (less overhead with this option).
In either case, an alias with the same name could belong to both a container and VM.
Which option would be preferable? cc. @tomponline @hamistao
is name
a unique index?
@kadinsayani does LXD auto select the correct instance type if launch an instance using an image alias
of type VM without specifying --vm
?
@kadinsayani does LXD auto select the correct instance type if launch an instance using an image
alias
of type VM without specifying--vm
?
Yes, applyAliases()
in /shared/simplestreams/simplestreams.go
fetches all images and applies aliases by filling a slice of alias structs with properties from api.Image
structs, which include an image type.
is
name
a unique index?
Yes. We could also change name
to not be a unique index, and rely on a unique id
.
Edit: I don't think it's possible to remove a unique constraint from a table. This approach would require creating a new table with different constraints and copying everything over.
Yes. We could also change name to not be a unique index, and rely on a unique id.
This would be best in my view, since it would be a simpler change and wouldn't break any (I think) lxd sql
queries currently being used.
Edit: @kadinsayani independentely of which approach we choose, I think you should be able to fix this by patching LXD: https://github.com/canonical/lxd/blob/5c3440f95557581119ffaba36622a6e1efe91e96/lxd/patches.go#L1437-L1439
So does this issue boil down to:
Simplestreams aliases are unique per instance type, but LXD's image aliases are unique (excluding instance type)?
My worry here is that changing the behavior could be considered a breaking API change.
Perhaps rather than just re-assigning the aliases we should error out and let the user decide which aliases they want to keep/update.
Thank you all looking into this issue.
My worry here is that changing the behavior could be considered a breaking API change.
@tomponline As the user, I consider the CLI API behaviour to be misleading/ incorrect because the expectation is that lxc launch local:jammy
(without --vm
) should only ever launch a container, but it will actually launch a VM if the alias is assigned to a VM.
Unique alias per image type is the solution I think best aligns with the documentation, but I appreciate your point and suggest that if you follow your approach the above mentioned CLI behaviour be accounted for, e.g.:
$ lxc launch local:jammy
E: You tried to create a container using the "local" alias "jammy",
which doesn't exist. The "local" alias "jammy" does
exist for a VM image."
$ lxc launch local:jammy --vm
E: You tried to create a VM using the "local" alias "jammy",
which doesn't exist. The "local" alias "jammy" does
exist for a container image."
That or the documentation be updated to reflect the possibility that the alias may cause the "wrong" kind of instance to be launched.
Best regards
Daniel
Upon further review of the issue, the changes required to resolve this issue are as follows:
/images/aliases
which include a /type/
segment for types virtual-machine
and container
;image_type
column to images_aliases
and amend unique constraint;CreateImageAlias
; andGetImageAlias
, GetExistingAliases
, and other DB interaction functions.For reference: https://github.com/canonical/lxd/pull/14162.
Hi @DanielDewberry,
Just wanted to let you know that this is still on my radar. I'm hoping I'll be able to resume working on it soon.
Best regards, Kadin
Required information
Distribution:
Kubuntu
Distribution version:24.04.1
The output of
snap list --all lxd core20 core22 core24 snapd
:The output of
lxc info
:Issue description
Copied from https://discourse.ubuntu.com/t/unexpected-behaviour-with-lxc-image-copy-copy-alises/47529?u=dwd-daniel, as requested.
I think that the aliases should be copied to the local storage, and should not be unique across instance types. That is to say, both a VM and Container image should be able to have the
jammy
ornoble
alias.Acquring the images: order 1
Issuing
I see the following images are stored:
Notice that the alias is set for the VMs, which are the second of the container/ VM aquisitions.
Acquring the images: order 2
If I switch the order of the Jammy container & VM acquisition, having already executed the previous command:
I see this:
The Jammy container image, which was acquired after the Jammy VM image, owns the alias.
Observation vs expectation
The aliases are not copied and preserved for each image, they seem to be required to one image, irrespective of image type. I expected each image to retain its aliases, and the
--vm
switch to be used as a way to discerne between the container and VMs images.We can see the aliases exist on the remote:
Attempting to set local aliases
If I attempt to add an alias to the local copy of the Jammy container, I am informed the Jammy alias already exists, which leads me to believe the alias must be, as previously noted, unique to a single image irrespective of the image type.
I can set up my own aliases which correctly categorize the images:
Summary
I think that the aliases should be copied to the local storage, and should not be unique across instance types. That is to say, both a VM and Container image should be able to have the
jammy
ornoble
alias.Best regards
Daniel