From: Stefan Agner <stefan@agner.ch>
To: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: Brandon Shibley <brandon.shibley@toradex.com>,
meta-virtualization@yoctoproject.org
Subject: Re: OpenEmbedded Image Format
Date: Mon, 10 Sep 2018 18:01:38 -0700 [thread overview]
Message-ID: <203ab06d2498d62ef1bedbb43c49d144@agner.ch> (raw)
In-Reply-To: <8d25ae3a-6f8a-7b45-33e0-1564dce82eb2@windriver.com>
On 10.09.2018 17:34, Bruce Ashfield wrote:
> On 2018-09-10 7:21 PM, Stefan Agner wrote:
>> Hi,
>>
>> Is there a OpenEmbedded image type which allows to build images which
>> are OCI Image Format compliant? meta-virtualization includes the
>> oci-image-tools, hence the recipe for tooling is there. There is
>> currently no -native support for oci-image-tool and its dependencies,
>> but I guess that shouldn't be too far away. Any thoughts?
>
> This is something that we typically do with umoci, not with the
> raw tools.
>
> re-inventing what better tools already do in a bbclass using
> the raw oci-image-tools is an not an exercise worth doing.
>
> Not to mention, nearly every use case I currently have for
> working with container images, involves registries, and adding
> something as clunky as a build system to generate the images
> just doesn't make sense.
>
> How were you planning on running/using the OCI bundles ?
I am not very familiar with OCI and its tools yet, so quite possible I
am on the wrong track here.
What we are looking for is a way to build an image using OE, generate a
container from it and push it to a registry. The last operation is
probably a separate/manual step, but ideally OE should build the tools
for it.
A second use case is where we build the container runtime image, but
also the container image using OE. In this case the container image
should get installed at OE build time onto the container runtime rootfs.
Since OpenEmbedded is the tooling to build the container runtime image
as well as the container itself, all those steps preferably should be
handled in OE as well.
It seems to me that umoci is the tool we are looking for. Is this
available as -native?
--
Stefan
>
> I've been doing similar things for quite some time in meta-cube
> i.e. http://layers.openembedded.org/layerindex/recipe/87474/
>
> But that all happens outside of the build system.
>
> I could move more of the tools over to meta-virt, if there's
> interest.
>
> Cheers,
>
> Bruce
>
>>
>> --
>> Stefan
>>
next prev parent reply other threads:[~2018-09-11 1:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-10 23:21 OpenEmbedded Image Format Stefan Agner
2018-09-11 0:34 ` Bruce Ashfield
2018-09-11 1:01 ` Stefan Agner [this message]
2018-09-11 1:10 ` Bruce Ashfield
2018-09-11 4:37 ` Stefan Agner
2018-09-11 11:14 ` Bruce Ashfield
2018-09-11 17:01 ` Stefan Agner
2018-09-11 17:19 ` Bruce Ashfield
2018-10-04 13:29 ` Bruce Ashfield
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=203ab06d2498d62ef1bedbb43c49d144@agner.ch \
--to=stefan@agner.ch \
--cc=brandon.shibley@toradex.com \
--cc=bruce.ashfield@windriver.com \
--cc=meta-virtualization@yoctoproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.