From: Joshua Watt <jpewhacker@gmail.com>
To: Bruce Ashfield <bruce.ashfield@gmail.com>
Cc: meta-virtualization@lists.yoctoproject.org
Subject: Re: [meta-virtualization][PATCH] classes/image-oci: Add OCI_IMAGE_ENTRYPOINT_ARG_LIST
Date: Fri, 13 Oct 2023 08:03:01 -0600 [thread overview]
Message-ID: <CAJdd5GZRFLmzE0WrXcjGNRk361va0WooF4MWczVYMaZEY8F01w@mail.gmail.com> (raw)
In-Reply-To: <CADkTA4OR61ZYbTyGpzk2_8v3gJcbR=6O1VYEa4M61Byo4dToUw@mail.gmail.com>
On Thu, Oct 12, 2023 at 9:40 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
>
>
> On Thu, Oct 12, 2023 at 11:05 PM Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:
>>
>>
>>
>> On Thu, Oct 12, 2023 at 7:02 PM Joshua Watt <jpewhacker@gmail.com> wrote:
>>>
>>>
>>>
>>> On Thu, Oct 12, 2023, 4:39 PM Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>> On Thu, Oct 12, 2023 at 6:09 PM Joshua Watt <jpewhacker@gmail.com> wrote:
>>>>>
>>>>> On Thu, Oct 12, 2023 at 11:25 AM Bruce Ashfield
>>>>> <bruce.ashfield@gmail.com> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Thu, Oct 12, 2023 at 1:23 PM Bruce Ashfield via lists.yoctoproject.org <bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> On Thu, Oct 12, 2023 at 12:52 PM Joshua Watt <JPEWhacker@gmail.com> wrote:
>>>>> >>>
>>>>> >>> The "entrypoint arguments" (command) is allowed to be a list of
>>>>> >>> arguments to pass to the entrypoint. However, the current
>>>>> >>> OCI_IMAGE_ENTRYPOINT_ARGS variables doesn't support however. In order to
>>>>> >>> maintain backward compatibility, a new variable has to be introduced to
>>>>> >>> that can be split into the multiple arguments required
>>>>> >>>
>>>>> >>
>>>>> >> I haven't looked in detail, but the original intent of that variable IS to have more than
>>>>> >> one argument. I was just the only current user of them, and only had one argument
>>>>> >> that needed to be passed.
>>>>> >>
>>>>> >> I'd rather not have a new variable, but just change the processing to do 1 or more
>>>>> >> arguments in the existing variable.
>>>>> >>
>>>>> >
>>>>> > Which if I'm not mistaken, is your first patch :)
>>>>>
>>>>> Almost. The first patch does it for OCI_IMAGE_ENTRYPOINT. That one is
>>>>> straight forward because there is no backward compatible problem. The
>>>>> second one (this one) does it for
>>>>> OCI_IMAGE_ENTRYPOINT_ARGS, which is trickier because if we make it
>>>>> behave the same as OCI_IMAGE_ENTRYPOINT it will break anyone who is
>>>>> currently relying on a space in OCI_IMAGE_ENTRYPOINT_ARGS to be passed
>>>>> verbatim to their entrypoint (hence my tentative suggestion to add a
>>>>> new variable). I'd be fine with just make OCI_IMAGE_ENTRYPOINT_ARGS
>>>>> split on space if that was the original intention (I can even roll it
>>>>> into the previous patch if you want and make it do both variables at
>>>>> the same time).
>>>>
>>>>
>>>> That's sort of my point.
>>>>
>>>> The entry point can just be the executable, and this variable is supposed to be the arguments.
>>>>
>>>> So no arguments should be passed via that first variable, but should be in this one. We can have the split and processing here, and check and forbid it in the first variable. It shouldn't be in both.
>>>
>>>
>>> I've made plenty of container images where ENTRYPOINT had multiple arguments; the trivial example is ["/usr/bin/python3", "my script"]. Sure, you can do it other ways (e.g. a proxy shell script.... Which then means your container needs a shell), but restricting that as an option doesn't seem necessary?
>>>
>>
>> Sure, but I'm saying put that "my script" in the args variable, that's exactly what I added it for.
>>
>
> I should clarify that I mean that we don't have to process it via the config.cmd for umoci
> .. if there's a technical need to change how it is encoded, we can deal with that. i.e in
> theory that variable could just be turned into multiple config.entrypoint calls instead of
> config.cmd
>
> But both ways of encoding it work (entrypoint + cmd), and there's no need to
> complicate things by adding another variable, we should be able to express what
> we need with the existing ones.
>
> The umoci and image-spec tests that I've run use entrypoint + cmd to encode arguments
> to the main executable / interpreter. We can sit around and talk about how we are reading
> the oci-image-spec, but both entrypoint and cmd are optional in it (the spec), and have a
> similar function. I've seen both ways of encoding in various container stacks over
> the years.
>
> But in the end, I don't think it matters at all. With umoci, it is valid to encode them either
> way, so simply converting space separated entrypoints and arguments to repeated
> --config.entrypoint and --config.cmd calls are fine, and we don't have to worry about
> backward compatibility now that I've looked at things more closely.
>
> If someone wants a single entrypoint and options via cmd, they can do that with them
> both converted, and vice versa.
Got it. I think I understand now. I'll send a patch.
>
> Bruce
>
>
>>
>> Bruce
>>
>>
>>>
>>>
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>>
>>>>> >
>>>>> > Bruce
>>>>> >
>>>>> >
>>>>> >>
>>>>> >> I'll also have to figure out how to make the sloci backend work, but that's a different
>>>>> >> question.
>>>>> >>
>>>>> >> Bruce
>>>>> >>
>>>>> >>
>>>>> >>>
>>>>> >>> Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
>>>>> >>> ---
>>>>> >>> classes/image-oci-umoci.inc | 3 +++
>>>>> >>> classes/image-oci.bbclass | 1 +
>>>>> >>> 2 files changed, 4 insertions(+)
>>>>> >>>
>>>>> >>> diff --git a/classes/image-oci-umoci.inc b/classes/image-oci-umoci.inc
>>>>> >>> index 6c7f244..da93570 100644
>>>>> >>> --- a/classes/image-oci-umoci.inc
>>>>> >>> +++ b/classes/image-oci-umoci.inc
>>>>> >>> @@ -103,6 +103,9 @@ IMAGE_CMD:oci() {
>>>>> >>> if [ -n "${OCI_IMAGE_ENTRYPOINT_ARGS}" ]; then
>>>>> >>> umoci config --image $image_name:${OCI_IMAGE_TAG} --config.cmd "${OCI_IMAGE_ENTRYPOINT_ARGS}"
>>>>> >>> fi
>>>>> >>> + if [ -n "${OCI_IMAGE_ENTRYPOINT_ARG_LIST}" ]; then
>>>>> >>> + umoci config --image $image_name:${OCI_IMAGE_TAG} ${@" ".join("--config.cmd %s" % s for s in d.getVar("OCI_IMAGE_ENTRYPOINT_ARG_LIST").split())}
>>>>> >>> + fi
>>>>> >>> umoci config --image $image_name:${OCI_IMAGE_TAG} --author ${OCI_IMAGE_AUTHOR_EMAIL}
>>>>> >>>
>>>>> >>> # make a tar version of the image direcotry
>>>>> >>> diff --git a/classes/image-oci.bbclass b/classes/image-oci.bbclass
>>>>> >>> index 9ddb88b..68045ad 100644
>>>>> >>> --- a/classes/image-oci.bbclass
>>>>> >>> +++ b/classes/image-oci.bbclass
>>>>> >>> @@ -57,6 +57,7 @@ OCI_IMAGE_SUBARCH ?= "${@oci_map_subarch(d.getVar('TARGET_ARCH'), d.getVar('TUNE
>>>>> >>>
>>>>> >>> OCI_IMAGE_ENTRYPOINT ?= "sh"
>>>>> >>> OCI_IMAGE_ENTRYPOINT_ARGS ?= ""
>>>>> >>> +OCI_IMAGE_ENTRYPOINT_ARG_LIST ?=""
>>>>> >>> OCI_IMAGE_WORKINGDIR ?= ""
>>>>> >>> OCI_IMAGE_STOPSIGNAL ?= ""
>>>>> >>>
>>>>> >>> --
>>>>> >>> 2.34.1
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>>
>>>>> >>
>>>>> >>
>>>>> >> --
>>>>> >> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
>>>>> >> - "Use the force Harry" - Gandalf, Star Trek II
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >
>>>>> >
>>>>> > --
>>>>> > - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
>>>>> > - "Use the force Harry" - Gandalf, Star Trek II
>>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end
>>>> - "Use the force Harry" - Gandalf, Star Trek II
>>>>
>>
>>
>> --
>> - 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 (#8359): https://lists.yoctoproject.org/g/meta-virtualization/message/8359
>> Mute This Topic: https://lists.yoctoproject.org/mt/101922305/1050810
>> Group Owner: meta-virtualization+owner@lists.yoctoproject.org
>> Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/leave/6693017/1050810/978058475/xyzzy [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
>
prev parent reply other threads:[~2023-10-13 14:03 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-12 16:51 [meta-virtualization][PATCH] classes/image-oci: Add OCI_IMAGE_ENTRYPOINT_ARG_LIST Joshua Watt
2023-10-12 17:22 ` Bruce Ashfield
[not found] ` <178D6BFFDDF3349D.29357@lists.yoctoproject.org>
2023-10-12 17:25 ` Bruce Ashfield
2023-10-12 22:08 ` Joshua Watt
2023-10-12 22:39 ` Bruce Ashfield
2023-10-12 23:01 ` Joshua Watt
2023-10-13 3:05 ` Bruce Ashfield
[not found] ` <178D8BCB6046F019.14388@lists.yoctoproject.org>
2023-10-13 3:39 ` Bruce Ashfield
2023-10-13 14:03 ` Joshua Watt [this message]
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=CAJdd5GZRFLmzE0WrXcjGNRk361va0WooF4MWczVYMaZEY8F01w@mail.gmail.com \
--to=jpewhacker@gmail.com \
--cc=bruce.ashfield@gmail.com \
--cc=meta-virtualization@lists.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).