[Fuego] Fuego's version up and other changes

[Bird, Timothy]

> -----Original Message-----
> From: Daniel Sangorrin on Tuesday, January 10, 2017 4:28 PM
> I've been working on Fuego's upgrade for a few weeks, and in the process I
> have made quite a few changes.
> You can check it by following these instructions. I'd really appreciate your
> feedback:
...
> 

This is really awesome work, and I'm very excited about the improvements.
I do have some questions and comments, which I'll inline below.

> Here is a list of the most fundamental modifications I've added:
> - I automatized the version upgrade process. So far I have updated Jenkins 3
> times quite smoothly.
>    The current version is the latest LTS version (2.31.1 LTS)
This is very welcome, and something that should help us keep synchronized with
Jenkins going forward.

> - I reduced plugin dependencies to the minimum (only 2, and they can be
> made optional).
This is good, but it dramatically changes the default visual look of fuego
(which was based on some Jenkins plugins).

This will require a substantial re-write of some of the docs, and a revamping
of our tutorials.  Luckily (??), we don't have a whole lot of tutorials and screenshots
to redo.  This will obsolete some of the existing presentations and videos, but
only certain portions, I think.  And it's early enough in Fuego's lifetime that it's
better to do it now than later.

We will need to make sure that previous functionality is available,
(or alternatively, that we can live without that functionality).  I assume
some cosmetic things (like, say, the "greenballs" Jenkins plugin)
should work without problem.  More problematical is dealing with changes
in the workflow caused by missing Jenkins modules that have been assumed
by Fuego users to be present.

> - I removed dependencies on all groovy scripts.

I'm still processing this.  I believe it means that targets are not first-class
objects inside of Jenkins anymore.  I'll have to investigate how to use
Jenkins to configure attributes of the target, or see target-specific test
results, etc, based on the new interface.

I haven't had time yet to play with the newer code and find out what
features or workflows are sacrificed by this, but I hope to do so next
week.

I plan to come up with a list of tasks and operations that I did in the
old interface, that are not obvious how to do in the new interface.

> - Userdata is gone. Instead we now have fuego-ro and fuego-rw, which
> together with fuego-core
>    are mounted as external docker volumes. Only fuego-rw, which contains
> logs and build folders,
>    is mounted in RW mode. I also fixed the uid/gid of jenkins so that it
> matches the one in the host.
>    This means you can develop comfortably on your host, with GUI tools, and
> don't fear a buggy
>    script deleting your folders.
This is super awesome, and resolves a lot of my own development headaches
with Fuego.

> - I added a  tool for generating jobs from testplans.  Creating jobs from
> testplans is powerful.
>    It allows you, for example, to easily specify the timeout for each test on
> your board.
>    The tool also generates the corresponding batch job. For example, you can
> easily trigger all
>    tests for your board and a specific testplan periodically.

Sounds good, and similar to what 0day does, but I'm not sure I understand
completely.  I believe you mean that you can use the test materials and testplans
to create separate Jenkins job for each plan?  Is that right?

It looks like you also create a separate Jenkins job for each combination of
test and target?  Is that right?  The default Jenkins interface is so sparse
that I'm a little lost what to do with it.  (Maybe I should not have comingled
my learning of Jenkins with my learning of Fuego - I think I've made assumptions
about base Jenkins features based on the plugins Cogent added by default
in JTA.)

>    [Note] This will also enable the creation of scripts for comparing test results
> across
>    different boards and test parameters (on my TODO list).

This sounds good.

> Other less fundamental changes include:
> - I added support for using the docker container itself as a target board (e.g.:
> for a quickstart or unit tests)
That's very handy, for a quickstart, and for testing Fuego itself.  Good idea!

> - I fixed the flot plugin (java and javascript fixes)
Thanks!!

> - Now you can click on a node and see which jobs (and testplans) are
> assigned to your board. This was
>   one of my old feature requests and makes Fuego's GUI easier to use.
> - I added quite a few fixes and improvements to the core engine scripts and
> tests (too detailed to describe here).
This one worries me.  I haven't done a diff yet, but I hope we're not
diverging too far to make integration difficult.

> - I added Excel output support for IOzone
> - Faster docker build time (ARMhf compiler installation is now optional, no
> latex..)
These both sound good.  The excel output format possibly ties
into discussions we've had about canonical output formats, 
results saving and comparisons, etc.  But I'd like to get more details
to see what's up with this.

> - I put a fixed name to the fuego container, instead of the
> "last_container_id" file.
I tend to have several containers lying around, for testing multiple
fuego versions.  I'm not sure if this will work if docker is using a fixed
name for the container.

> - I removed the inotify script
One of my first contributions to fuego!  This makes me a little sad,
but happy if it's not needed anymore. :-)

> - I added scripts for easily removing the docker container/image.
> 
> I have to split the current "huge" patch into smaller chunks and test it further
> but it would
> be nice to get your feedback about the approach in general.
> 
> Tim: I haven't updated ftc nor your "Christmas commits" yet.

I can help with updating ftc and with more recent commits.

I have yet to really dig into the code changes to see how it affects
the overall architecture.  But I really like the list of changes.
I do want to make sure that we haven't lost any important features
going forward, and that the changes fit with my longterm goals
for the project.

Let me know what would be best to look at, for planning future
integration of these changes.
 -- Tim