'atomic images list' is missing some system containers
miabbott opened this issue · 3 comments
On Fedora 27 AH, using atomic-1.20.1-9.fc27.x86_64, the output from atomic images list is missing some system containers that were pulled to ostree storage. However, if I pass in the --all option, the missing images show up.
# atomic images list
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE TYPE
registry.fedoraproject.org/fedora latest 9881e4229c95 2018-01-18 07:48 252.33 MB docker
> docker.io/registry 2 d1fd7d86a825 2018-01-10 01:22 33.28 MB docker
registry.fedoraproject.org/f27/kubernetes-proxy latest 4660f3d3b9a3 2018-02-06 16:43 262.53 MB ostree
registry.fedoraproject.org/f27/kubernetes-kubelet latest 3c419c4956d8 2018-02-06 16:42 267.37 MB ostree
registry.fedoraproject.org/f27/kubernetes-controller-manager latest cc1f95c6fe77 2018-02-06 16:40 231.12 MB ostree
registry.fedoraproject.org/f27/etcd latest 4501c21370c0 2018-02-06 16:43 111.26 MB ostree
# atomic images list --all
REPOSITORY TAG IMAGE ID CREATED VIRTUAL SIZE TYPE
registry.fedoraproject.org/fedora latest 9881e4229c95 2018-01-18 07:48 252.33 MB docker
> docker.io/registry 2 d1fd7d86a825 2018-01-10 01:22 33.28 MB docker
<none> <none> 8d884f5d20c0 2018-02-06 16:43 ostree
<none> <none> ff8eae79cd9d 2018-02-06 16:43 ostree
<none> <none> a0d3b3cff988 2018-02-06 16:37 ostree
registry.fedoraproject.org/f27/kubernetes-proxy latest 4660f3d3b9a3 2018-02-06 16:43 262.53 MB ostree
<none> <none> 9d695cfffacf 2018-02-06 16:40 ostree
<none> <none> e8d4ef1c74c2 2018-02-06 16:42 ostree
<none> <none> 1eb9b88722dd 2018-02-06 16:37 ostree
<none> <none> 80f95099db80 2018-02-06 16:43 ostree
registry.fedoraproject.org/f27/kubernetes-kubelet latest 3c419c4956d8 2018-02-06 16:42 267.37 MB ostree
<none> <none> 08f2d2edcd3b 2018-02-06 16:40 ostree
<none> <none> 8c91fa19a01a 2018-02-06 16:37 ostree
<none> <none> 8850316d6c29 2018-02-06 16:42 ostree
<none> <none> c33d58df0ea9 2018-02-06 16:42 ostree
registry.fedoraproject.org/f27/kubernetes-apiserver latest e590748969a7 2018-02-06 16:37 285.73 MB ostree
<none> <none> 2de259afc9c4 2018-02-06 16:43 ostree
<none> <none> 04331e646521 2018-02-06 16:37 ostree
registry.fedoraproject.org/f27/kubernetes-controller-manager latest cc1f95c6fe77 2018-02-06 16:40 231.12 MB ostree
<none> <none> 9f5b1420a44b 2018-02-06 16:43 ostree
registry.fedoraproject.org/f27/kubernetes-scheduler latest cb17034be1ed 2018-02-06 16:43 231.12 MB ostree
<none> <none> 67a58c9856a5 2018-02-06 16:43 ostree
registry.fedoraproject.org/f27/etcd latest 4501c21370c0 2018-02-06 16:43 111.26 MB ostree
In the example above, the kubernetes-apiserver and kubernetes-scheduler images are missing from the 'short' list of images.
I believe this is because of this line in syscontainers.py: in get_system_images function
revs = [x for x in repo.list_refs()[1] if x.startswith(OSTREE_OCIIMAGE_PREFIX) \
and (get_all or len(x) != len(OSTREE_OCIIMAGE_PREFIX) + 64)]
After the installation of kubernetes-apiserver, we list them with ostree refs
[root@localhost ~]# ostree refs --repo=/var/lib/containers/atomic/.storage/ostree
ociimage/ca4f61b1923c10e9eb81228bd46bee1dfba02b9c7dac1844527a734752688ede
ociimage/hello-world_3Alatest
ociimage/a0d3b3cff98825af4debc7883d4c96d2deb4400592d3b6d1a60058b5e2221ae9
ociimage/1eb9b88722dda2113c3e55a6436d733e4feea21e772b854dbe7f92010b46eafb
ociimage/f2a91732366c0332ccd7afd2a5c4ff2b9af81f549370f7a19acd460f87686bc7
ociimage/8c91fa19a01abc779994110abd8146c8f38fe26eb879c83f2aed5f4699ffa2a7
ociimage/registry.fedoraproject.org_2Ff27_2Fkubernetes-apiserver_3Alatest
ociimage/04331e646521ddb577d113f3c103aef620cc4451641452c347864298669f8572
It can be seen that the actual kubernetes image
ociimage/registry.fedoraproject.org_2Ff27_2Fkubernetes-apiserver_3Alatest
has the same length as other "image layers"( images usually with tag <none> and repository <none>) . IOW, it will not satisfy the if condition len(x) != len(OSTREE_OCIIMAGE_PREFIX) + 64). ( because the name is exactly 64 characters more by coincidence and thus get treated similarly as other <none> images shown in "atomic images list -a").
Tho, i can't think of an easy fix atm, may be @giuseppe will have an easy solution for this =P.
@miabbott, goot catch!
@peterbaouoft, yes correct that is the reason. Would you like to prepare a fix for it?
Looking at the metadata would be expensive for each branch. Let's add another check that the part after 'ociimage/' is not an hexadecimal. For this function, you could probably use int('...', 16) and see it raises an exception.
Sure, I can prepare a fix for it.
you could probably use int('...', 16) and see it raises an exception
That would require us to have a try-except block right? which seems ... a bit ugly. I was thinking if we could try using regex matching see if only letters + numbers were existent in the part. If the image( the ref after ociimage/) is not purely letters + numbers we can say it is an image we want to display via atomic images list.
That is my initial thought, i will see how it goes when I am prepping the fix. Thanks for the hint! =)