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

Tim.Bird at sony.com Tim.Bird at sony.com
Wed Sep 5 20:00:23 UTC 2018



> -----Original Message-----
> From: 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.

OK - I've applied the patches, and then did a small refactoring patch on top.
I decided to go with the following deploy_methods: log_dir, local_dir, board_dir
and to support an optional deploy_path (for local_dir and board_dir, with defaults
for each).

Please try it out and let me know if it works for you.  I successfully built in my docker
image.  Kernel's built on my other boards, but then there were issues finding the 
kernel image (I likely hadn't set some needed variable).

One other thing I noted: This test should always perform its test_build phase,
as that's the point of the test.  I ended up doing another commit on top
that sets the "Rebuild" variable, so that Fuego doesn't skip the build.
I'm not sure how this interacts with unpacking code into the existing directory.
Possibly this should be more aggressive and remove everything from the
build directory before proceeding with the build.

If this test is used as part of a broader set of testing actions, then configuring
it to skip the build if the kernel hasn't changed would make sense.  So this may
need to be re-thought when that happens.  Let me know if doing a forced rebuild
goes against your use cases for this test.

> 
> > 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).
Agree that provision or install are better words, to avoid confusion.

> 
> 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.

I basically agree with all of this.  Creating a script that calls ftc in order sounds like
the easiest solution.  Trying to manage ordering with a declarative syntax is,
IMHO, harder for users to understand.

It would be nice if we could just do something simple like the following:
function test_run {
	ftc run-test -b $BOARD_NAME -t Functional.kernel_build
	ftc run-test -b $BOARD_NAME -t Functional.kernel_provision
                ftc run-test -b $BOARD_NAME -p testplan_myproject
}

Maybe we already can?

In this case, the absence of a board locking at the 'ftc' level is actually helpful.
This would all run as a single Jenkins job (if launched from a job), so Jenkins
node locking would not get in the way.
 -- Tim




More information about the Fuego mailing list