On Fri, Oct 13, 2023 at 3:32 PM Joshua Watt <[email protected]> wrote:
>
> On Fri, Oct 13, 2023 at 10:58 AM Bruce Ashfield
> <[email protected]> wrote:
> >
> > On Fri, Oct 13, 2023 at 11:38 AM Joshua Watt <[email protected]> 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 <[email protected]>
> > > ---
> > >  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.

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/21656
Group Owner: [email protected]
Unsubscribe: 
https://lists.yoctoproject.org/g/meta-virtualization/leave/6693005/21656/1014668956/xyzzy
 [[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to