On Tue, Nov 8, 2022 at 10:45 AM Guenther Meyer <[email protected]> wrote: > > Hi, > > I am trying to build some OCI-containers, but there are some things that are > not really clear to me: > > Issue one: When I build my container image, these are the resulting files: > > example-container-qemux86-64.testdata.json -> example-container- > qemux86-64-20221108152401.testdata.json > example-container-qemux86-64-20221108152401.testdata.json > example-container-qemux86-64.manifest -> example-container- > qemux86-64-20221108152401.rootfs.manifest > example-container-qemux86-64-20221108152401.rootfs.manifest > example-container-qemux86-64.qemuboot.conf -> example-container- > qemux86-64-20221108152401.qemuboot.conf > example-container-qemux86-64-20221108152401.qemuboot.conf > example-container-qemux86-64-20221108152401.rootfs.tar.bz2 > example-container-qemux86-64.tar.bz2 -> example-container- > qemux86-64-20221108152401.rootfs.tar.bz2 > example-container-qemux86-64-20221108152401.rootfs-oci > example-container-qemux86-64-20221108152401.rootfs-oci.tar > > So the question is, why are there only stable symlinks for some of the files > and not for the rootfs-oci files? How can this be changed?
Some of those symlinks are done by core and the base image classes (the manifests, etc). Artifacts related to the oci image class are the responsibility of the image class itself. Those are the -oci- components of deploy. I recently tweaked the container image backends to make an additional symlink, you can see those on the master-next branch of meta-virt. Additional convenience links are possible, but would have to be requested, so I can understand the use case and come up with a patch and test for them. > > > The second issue is the resulting tar-file. I thought, I could directly load > it > as an image, but that results in an error. > Investigating the content of the archive, I found, that the necessary content > like index.json, oci-layout ad blob/* is not on the root level but inside a > subfolder "example-container-qemux86-64-20221108152401.rootfs-oci/". > > Is that intentional, if yes, why? > Because when I create an archive with the same files on the root level, it can > directly be used with podman or other tools. > This has been discussed on the list before, it is intentional. The tar file was created to make handling the images a bit easier (since when i did the work, the oci image class was just specifying directories). There are workflows and use-cases that expect that format. I promised to think about how to handle and support both use cases, and I haven't come up with an answer yet. I'll get to that shortly (fingers crossed). The primary use case for the oci images is that they are expected to be manipulated with something with skopeo and copied/transformed in that sort of workflow. > > Issue number three: > Maybe this is not directly related, but I'm fairly new into this container > stuff, so forgive me, if I'm wrong: > If I want to use a predeployed image with k3s, what is the name of the image > that I have to use in the deployment yaml? Is it just the filename or is it > something else? If the latter, how do I set the image name during the build? I've never done something predeployed (or at least what I think of in that sense), but you can find a very simple example of a yaml file that I did for a ELC presentation in the meta-virt layer itself (recipes-demo/helloworld-flask/helloworld-flask) Anything more complex is an exercise for whoever is developing the application and working with their deployment. But if there are ways to generate more of the yaml, or streamline things. I'm always interested in discussing it. Bruce > > Cheers, > Guenther > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#7678): https://lists.yoctoproject.org/g/meta-virtualization/message/7678 Mute This Topic: https://lists.yoctoproject.org/mt/94892904/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
