On Thu, Oct 12, 2023 at 9:40 PM Bruce Ashfield <[email protected]> wrote: > > > > On Thu, Oct 12, 2023 at 11:05 PM Bruce Ashfield via lists.yoctoproject.org > <[email protected]> wrote: >> >> >> >> On Thu, Oct 12, 2023 at 7:02 PM Joshua Watt <[email protected]> wrote: >>> >>> >>> >>> On Thu, Oct 12, 2023, 4:39 PM Bruce Ashfield <[email protected]> >>> wrote: >>>> >>>> >>>> >>>> On Thu, Oct 12, 2023 at 6:09 PM Joshua Watt <[email protected]> wrote: >>>>> >>>>> On Thu, Oct 12, 2023 at 11:25 AM Bruce Ashfield >>>>> <[email protected]> wrote: >>>>> > >>>>> > >>>>> > >>>>> > On Thu, Oct 12, 2023 at 1:23 PM Bruce Ashfield via >>>>> > lists.yoctoproject.org >>>>> > <[email protected]> wrote: >>>>> >> >>>>> >> >>>>> >> >>>>> >> On Thu, Oct 12, 2023 at 12:52 PM Joshua Watt <[email protected]> >>>>> >> 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 <[email protected]> >>>>> >>> --- >>>>> >>> 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 (#8361): https://lists.yoctoproject.org/g/meta-virtualization/message/8361 Mute This Topic: https://lists.yoctoproject.org/mt/101922305/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/meta-virtualization/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
