Problems building an OCI container image

Problems building an OCI container image

[Guenther Meyer]

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

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?


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.


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?

Cheers,
Guenther

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [meta-virtualization] Problems building an OCI container image

[Bruce Ashfield]

On Tue, Nov 8, 2022 at 10:45 AM Guenther Meyer <g.meyer@signum-media.de> 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
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#7677): https://lists.yoctoproject.org/g/meta-virtualization/message/7677
> Mute This Topic: https://lists.yoctoproject.org/mt/94892904/1050810
> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [bruce.ashfield@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

Re: [meta-virtualization] Problems building an OCI container image

[Guenther Meyer]

[-- Attachment #1: Type: text/plain, Size: 2779 bytes --]

On Dienstag, 8. November 2022 17:37:18 CET Bruce Ashfield wrote:
> On Tue, Nov 8, 2022 at 10:45 AM Guenther Meyer <g.meyer@signum-media.de> 
wrote:
> I recently tweaked the container image backends to make an additional
> symlink, you can see those on the master-next branch of meta-virt.

That's exactly what I need.  Would it be possible to backport that to 
kirkstone?


> > 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.

That's interesting, what are those workflows and use cases? I guess, skopeo 
should be able to handle the image also without the subfolder, because that's 
what the oci specs says - at least as I understand it.

I see two main use cases here: The one is to load the image directly into a 
container runtime, the other would be to push it to a registry.

Don't get me wrong, I could easily create my own tar from the image folder.
But I would expect, that a generated tar image could be used directly without 
any additional handling.
Loading the tar directly with tools like podman or ctr works, when the 
expected file structure is at the root of the tar file, but not when there is an 
additional directory.


> > 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)

Thanks, I will have a look.


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]