meta-virtualization.lists.yoctoproject.org archive mirror
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@gmail.com>
To: bruce.ashfield@gmail.com
Cc: Joshua Watt <jpewhacker@gmail.com>,
	meta-virtualization@lists.yoctoproject.org
Subject: Re: [meta-virtualization][PATCH v2] classes/image-oci-umoci: Handle mutliple entrypoint arguments
Date: Mon, 16 Oct 2023 14:16:28 -0400	[thread overview]
Message-ID: <CADkTA4OCAzhASkMv0umKOgqNc9bbaMZV5cjaVko7S_oQ1OE9Ag@mail.gmail.com> (raw)
In-Reply-To: <178DC83238988A4B.8679@lists.yoctoproject.org>

On Fri, Oct 13, 2023 at 5:32 PM Bruce Ashfield via
lists.yoctoproject.org
<bruce.ashfield=gmail.com@lists.yoctoproject.org> wrote:
>
> On Fri, Oct 13, 2023 at 3:32 PM Joshua Watt <jpewhacker@gmail.com> wrote:
> >
> > On Fri, Oct 13, 2023 at 10:58 AM Bruce Ashfield
> > <bruce.ashfield@gmail.com> wrote:
> > >
> > > On Fri, Oct 13, 2023 at 11:38 AM Joshua Watt <JPEWhacker@gmail.com> wrote:
> > > >
> > > > The entrypoint to a container is actually an array of the executable to
> > > > run and the arguments to pass to it. It is useful to be able to specify
> > > > the entire list as the entrypoint when creating containers so that
> > > > then entrypoint can be encoded with argument, e.g.
> > > >
> > > >     ENTRYPOINT ["/usr/bin/python3", "my-script"]
> > > >
> > > > The current way that image-oci-umoci.bbclass handles this is equivalent
> > > > to:
> > > >
> > > >     ENTRYPOINT ["/usr/bin/python3"]
> > > >     CMD ["my-script"]
> > > >
> > > > But this is undesirable as it means if the user passes arguments when
> > > > running the container, it will override the "my-script" argument and the
> > > > arguments will instead get passed to the python interpreter, which may
> > > > not be desired.
> > > >
> > > > Instead, pass all the entry point arguments to umoci in a single
> > > > invocation using multiple --config.entrypoint arguments, which correctly
> > > > make the list as described above. The entire ENTRYPOINT list will start
> > > > with OCI_IMAGE_ENTRYPOINT, then have OCI_IMAGE_ENRTYPOINT_ARGS split by
> > > > spaces concatenated after it.
> > > >
> > > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> > > > ---
> > > >  classes/image-oci-umoci.inc | 8 ++++----
> > > >  1 file changed, 4 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/classes/image-oci-umoci.inc b/classes/image-oci-umoci.inc
> > > > index 58e4668..245dae5 100644
> > > > --- a/classes/image-oci-umoci.inc
> > > > +++ b/classes/image-oci-umoci.inc
> > > > @@ -99,10 +99,10 @@ IMAGE_CMD:oci() {
> > > >         bbnote "OCI: image subarch is set to: ${OCI_IMAGE_SUBARCH}, but umoci does not"
> > > >         bbnote "     expose variants. use sloci instead if this is important"
> > > >      fi
> > > > -    umoci config --image $image_name:${OCI_IMAGE_TAG} --config.entrypoint ${OCI_IMAGE_ENTRYPOINT}
> > > > -    if [ -n "${OCI_IMAGE_ENTRYPOINT_ARGS}" ]; then
> > > > -       umoci config --image $image_name:${OCI_IMAGE_TAG} --config.cmd "${OCI_IMAGE_ENTRYPOINT_ARGS}"
> > > > -    fi
> > > > +    umoci config --image $image_name:${OCI_IMAGE_TAG} \
> > > > +       --config.entrypoint "${OCI_IMAGE_ENTRYPOINT}" \
> > > > +       ${@" ".join("--config.entrypoint %s" % s for s in d.getVar("OCI_IMAGE_ENTRYPOINT_ARGS").split())}
> > > > +
> > >
> > >
> > > This is super close to what I badly tried to describe. I realize I could have
> > >  just done a patch to be clear, but it was a bit late and I just
> > > wanted to get something out.
> > >
> > > Do you think something like the following would meet your use case :
> > >
> > > diff --git a/classes/image-oci-umoci.inc b/classes/image-oci-umoci.inc
> > > index 58e4668..0d6c712 100644
> > > --- a/classes/image-oci-umoci.inc
> > > +++ b/classes/image-oci-umoci.inc
> > > @@ -99,9 +99,10 @@ IMAGE_CMD:oci() {
> > >         bbnote "OCI: image subarch is set to: ${OCI_IMAGE_SUBARCH},
> > > but umoci does not"
> > >         bbnote "     expose variants. use sloci instead if this is important"
> > >      fi
> > > -    umoci config --image $image_name:${OCI_IMAGE_TAG}
> > > --config.entrypoint ${OCI_IMAGE_ENTRYPOINT}
> > > +    umoci config --image $image_name:${OCI_IMAGE_TAG} \
> > > +         ${@" ".join("--config.entrypoint %s" % s for s in
> > > d.getVar("OCI_IMAGE_ENTRYPOINT").split())}
> > >      if [ -n "${OCI_IMAGE_ENTRYPOINT_ARGS}" ]; then
> > > -       umoci config --image $image_name:${OCI_IMAGE_TAG} --config.cmd
> > > "${OCI_IMAGE_ENTRYPOINT_ARGS}"
> > > +       umoci config --image $image_name:${OCI_IMAGE_TAG} ${@"
> > > ".join("--config.cmd %s" % s for s in
> > > d.getVar("OCI_IMAGE_ENTRYPOINT_ARGS").split())}
> > >      fi
> > >
> > > That way you aren't forced to split your multi argument entrypoint
> > > over two variables, and
> > > we can still have arguments in that ARGS variable available to be
> > > clobbered on container
> > > start, etc.
> > >
> > > I realize this is probably where you would have started if not for
> > > concerns about backward compatibility, etc.
> > > But looking at it more, it is easier to just convert both variables to
> > > the repeated call to umoci. We are
> > > leaving the variables themselves the same with space separated
> > > arguments/entrypoint, so that is enough
> > > backward compatibility for me.
> >
> > Ah, yes. That is even better.
> >
> > I like how you can set both entrypoint and command as lists this way.
>
> I can make the commit here, and add your signed-off-by, since we can
> take your reply as you being ok with this change, derived from your
> patches.
>

My version of this is on master-next. I passed creation and skopeo copy
to dockerhub, pull and run, so it appears to be sane :)

Bruce

> Bruce
>
> >
> > >
> > > Bruce
> > >
> > >
> > > >
> > > >      umoci config --image $image_name:${OCI_IMAGE_TAG} --author ${OCI_IMAGE_AUTHOR_EMAIL}
> > > >
> > > >      # make a tar version of the image direcotry
> > > > --
> > > > 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
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#8365): https://lists.yoctoproject.org/g/meta-virtualization/message/8365
> Mute This Topic: https://lists.yoctoproject.org/mt/101942798/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


      parent reply	other threads:[~2023-10-16 18:16 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-12 16:25 [meta-virtualization][PATCH] classes/image-oci-umoci: Handle mutliple entrypoint arguments Joshua Watt
2023-10-13 15:38 ` [meta-virtualization][PATCH v2] " Joshua Watt
2023-10-13 16:58   ` Bruce Ashfield
2023-10-13 19:32     ` Joshua Watt
2023-10-13 21:32       ` Bruce Ashfield
     [not found]       ` <178DC83238988A4B.8679@lists.yoctoproject.org>
2023-10-16 18:16         ` Bruce Ashfield [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=CADkTA4OCAzhASkMv0umKOgqNc9bbaMZV5cjaVko7S_oQ1OE9Ag@mail.gmail.com \
    --to=bruce.ashfield@gmail.com \
    --cc=jpewhacker@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).