[libvirt] [sandbox PATCH v4 10/21] Image: Add get_command function to Source

[Cedric Bosdonnat]

On Tue, 2015-09-08 at 17:21 +0100, Daniel P. Berrange wrote:
> On Fri, Aug 28, 2015 at 01:47:38PM +0000, Eren Yagdiran wrote:
> > Provide a way to know how a template can be started depending on the used source
> > DockerSource will need to parse the topmost config file in order to find the igniter command
> > ---
> >  virt-sandbox-image/sources/DockerSource.py | 14 ++++++++++++++
> >  virt-sandbox-image/sources/Source.py       |  4 ++++
> >  2 files changed, 18 insertions(+)
> > 
> > diff --git a/virt-sandbox-image/sources/DockerSource.py b/virt-sandbox-image/sources/DockerSource.py
> > index 760ba6c..3e0362b 100644
> > --- a/virt-sandbox-image/sources/DockerSource.py
> > +++ b/virt-sandbox-image/sources/DockerSource.py
> > @@ -29,6 +29,15 @@ import os
> >  import subprocess
> >  import shutil
> >  
> > +class DockerConfParser():
> > +
> > +    def __init__(self,jsonfile):
> > +        with open(jsonfile) as json_file:
> > +            self.json_data = json.load(json_file)
> > +    def getRunCommand(self):
> > +        cmd = self.json_data['container_config']['Cmd'][2]
> > +        return cmd[cmd.index('"') + 1:cmd.rindex('"')]
> 
> In testing, I found out we should be using 'config' here
> not 'container_config', since the latter refers to the
> configuration used when the image was built, which is
> subtly different from the config that is intended to be
> used when in it deployed.
> 
> In particular the 'Cmd' field does not need this string
> munging when we use 'config' instead of 'container_config'.
> 
> In researching this, I found out that docker also has an
> optional 'Entrypoints' array and if both Entrypoints and
> Cmd are specified, we should concatenate them. If the
> user provides command line args, then should replace
> the 'Cmd' list, but not the 'Entrypoints' list. Finally
> some images don'pt define any 'Cmd' or 'Entrypoints' at
> all, in which case it seems we should just try using
> /bin/sh, in the absence of any user supplied command.

Do we really want to have a default to /bin/sh when docker is giving an
error to the user?

Error response from daemon: No command specified

--
Cedric
> Regards,
> Daniel