[Fuego] [PATCH 7/7] kernel_build: add multiple deploy options

[Daniel Sangorrin]

> -----Original Message-----
> From: Tim.Bird at sony.com <Tim.Bird at sony.com>
[...]
> >  function test_deploy {
> > -    if [ -z "$FUNCTIONAL_KERNEL_DEPLOY" ]; then
> > -        FUNCTIONAL_KERNEL_DEPLOY="$LOGDIR"
> > +    # FIXTHIS: add support for device trees
> > +    if [ -z "$FUNCTIONAL_KERNEL_DEPLOY_METHOD" ]; then
> > +        FUNCTIONAL_KERNEL_DEPLOY="log"
> My preference would be to call this "logdir".  Let me know if you object.

I don't.

> > +    if [ "$FUNCTIONAL_KERNEL_DEPLOY" == "scp" ]; then
> Since 'put' is the name of the Fuego remote copy operation,
> I'd rather this deploy method was named 'put'.

OK, good idea.

> > +++ b/engine/tests/Functional.kernel_build/spec.json
> > @@ -26,7 +26,7 @@
> >              "config": "defconfig",
> >              "target": "Image",
> >              "params": "-j8",
> > -            "deploy": "/var/lib/tftp/",
> > +            "deploy_method": "tftp",
> Hmmm.  this is OK, but possibly not as generic as I'd like.

Yes, it's kind of a first step.

> I'm just brainstorming, but how about something like:
> deploy_method: "local_dir",
> deploy_path: "/var/lib/tftp"

Looks good.

> The reason for this is that I used to have an elaborate system
> with copies under /target/<board>/boot.  I don't think that
> everyone uses /var/lib/tftp.
> Currently, I use the path "/var/lib/tftpboot"
> 
> Other locations in the file system might be used as a rendezvous
> point for external deploy systems.  I'm doing this for my
> minnowboard, which uses an external program to boot into
> a "safe" kernel, and write from a kernel build directory
> directly to target:/boot
> 
> One idea, besides logdir, would be to put it into /fuego-rw/board/<board-name>/,
> and always have a variable in Fuego for that location:
> FUEGO_RW_BOARD_DIR
> or something like that.  Maybe we could support a "board_dir" deploy_method.

I guess we can infer FUEGO_RW_BOARD_DIR from NODE_NAME. We could do the same for /var/lib/tftpboot/<NODE_NAME>.
Maybe we should add an unique identifier (commit id and date for instance)

> Note.  I reviewed the other patches in this series (the kernel_build 1-6) and
> they all look fine on visual inspection.  I haven't had time to apply the
> patches and try to run them.  This would take a while, and I trust your judgement.
> I'm out of time tonight, but I'll likely apply these tomorrow, and give them a
> smoketest, then push them and let you know when they're applied.
> 
> Let me know if you want to  re-spin 7 (this one) based on my feedback.  I don't
> mind applying it as is and working on it more after it's applied (e.g. if you're OK with
> changes.)

I'm OK with the changes, you can apply them and we can work on top adding fixes and new features.

> BTW - I have been working on external methods of deployment, that I was
> considering
> putting into a separate Fuego test, then stringing the kernel build together with
> something
> like "Functional.kernel_deploy" in a batch job, to perform the replacement of the
> software
> under test on the board.  However, I wanted to fix some things about how we did
> batch
> jobs first.  I'm inclined to leave this deployment stuff here in
> Functional.kernel_build for now.
> We can always move it around later if I ever find the time to work on integrating my
> deployement stuff with it.
> 
> One thing that kind of blows people's minds about Fuego, is that our 'deploy'
> operation
> is a deploy of the test software, NOT the software under test (which we have
> historically
> left as an exercise for the user).  It would be really nice to also support deploying
> (/installing)
> the software under test (the kernel, modules and distro/rootfs) as well.  Doing this
> generically
> is a big task, but this is a nice start.

Let me use the word 'provisioning', instead of 'deploying', when talking about the kernel/rootfs ('installing' is also easy to understand).

Here is a possible way to implement provisioning:
- Functional.kernel_build could build the kernel/modules/dtb and put them on a TFTP or HTTP server.
- Functional.yocto_build could be added to build the distro/rootfs and deploy it to the same server (probably we should run the build on a remote server as well because it is CPU consuming)
- Functional.provision then could 
1) reboot the board (power control, cmd reboot, or finger input)
2) wait for the u-boot console prompt and specify what files to download. This would require parameters in the board file, as in LAVA. In fact, this is the most complicated step in LAVA for beginners. I think that we should also support users that prefer to download the kernel/distro from the same exact server and path every time. In that case, the user can just prepare the bootloader (e.g. u-boot tftpboot environment variables) in advance, and this way Fuego wouldn't need to interact with the u-boot console. This could be the easiest way both for the users and for us. We just need to make sure that we can track what kernel/rootfs was used, and keep them somewhere.
3) wait until the board is completely ready. This is another difficult step. In LAVA you can wait until you match a string from the target's output (e.g. the prompt), but if your prompt is too short there may be conflicts. Waiting for an ssh connection could be enough for most users so we can use that as a default.

The execution of these jobs need to be done in a specific order. We can do that by creating a script that calls ftc in order. Another option is to add options to specify what test comes after and force testplans/batches to follow the order in which they are specified.

Thanks,
Daniel

> 
> Thanks very much.
>   -- Tim