On Thu, Oct 12, 2023 at 11:05 PM Bruce Ashfield via lists.yoctoproject.org
<bruce.ashfield=gmail....@lists.yoctoproject.org> wrote:
>
>
> On Thu, Oct 12, 2023 at 7:02 PM Joshua Watt <jpewhac...@gmail.com> wrote:
>
>>
>>
>> On Thu, Oct 12, 2023, 4:39 PM Bruce Ashfield <bruce.ashfi...@gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 12, 2023 at 6:09 PM Joshua Watt <jpewhac...@gmail.com>
>>> wrote:
>>>
>>>> On Thu, Oct 12, 2023 at 11:25 AM Bruce Ashfield
>>>> <bruce.ashfi...@gmail.com> wrote:
>>>> >
>>>> >
>>>> >
>>>> > On Thu, Oct 12, 2023 at 1:23 PM Bruce Ashfield via
>>>> lists.yoctoproject.org <bruce.ashfield=gmail....@lists.yoctoproject.org>
>>>> wrote:
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Thu, Oct 12, 2023 at 12:52 PM Joshua Watt <jpewhac...@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.
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 <jpewhac...@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
>
>
>
>
>
--
- 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 (#8360):
https://lists.yoctoproject.org/g/meta-virtualization/message/8360
Mute This Topic: https://lists.yoctoproject.org/mt/101922305/21656
Group Owner: meta-virtualization+ow...@lists.yoctoproject.org
Unsubscribe:
https://lists.yoctoproject.org/g/meta-virtualization/leave/6693005/21656/1014668956/xyzzy
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
