[Fuego] Fuego 1.0.0 release

Bird, Timothy Tim.Bird at am.sony.com
Fri Nov 11 17:01:33 UTC 2016



> -----Original Message-----
> From: Daniel Sangorrin pm Friday, November 11, 2016 1:42 AM
> > -----Original Message-----
> > From: Bird, Timothy on Thursday, November 10, 2016 10:58 AM
> > > -----Original Message-----
> > > From: Daniel Sangorrin on Wednesday, November 09, 2016 4:55 PM
> > > > -----Original Message-----
> > > > From: Bird, Timothy on Wednesday, November 09, 2016 12:44 PM
> > > > Let me know if you see any problems.  I've foregone going through an RC
> > > release
> > > > series for this release, but I may add that if it looks like I need help from
> > > outside
> > > > parties stabilizing releases in the future.
> > >
> > > Thanks for the release. I reinstall everything from scratch and let you
> know if
> > > I find some problem.
> >
> > Thanks.  I would especially like to know if the support for building a
> container
> > behind a proxy works right.   I wasn't able to test that.
> 
> I just installed everything from scratch and didn't have any problems.

Thanks.  This is really helpful.

> > > > Finally - I know there are pending patches on the mailing list (thanks
> > > Daniel).
> > > > I wanted to get this release out before going through those, as this
> release
> > > was
> > > > already complicated enough.  Just by way of information, my upcoming
> to-
> > > do list is:
> > > >  * figure out why there are two tests.info files, and hopefully get rid of
> one
> > > >  * evaluate Daniel's latest set of patches (from the last 2 weeks), and
> > > provide
> > > >     feedback and/or integrate them into 'next'.
> > > >  * start work on standards for test pre check functionality (compare
> with
> > > 0day
> > > >    and any other systems that do test pre check
> > > >  * write a target scan and health_check test
> > > >  * write the contract for the serial console transport feature
> > >
> > > Thanks, I was thinking about preparing a patch to replace tarballs by git
> > > repositories (using the https protocol so they can be fetched behind
> > > proxies).
> > > What do you think about that? If you think there are more urgent
> changes
> > > to make let me know.
> >
> > I think this would be a nice addition.  Please don't replace tarballs, but just
> > add the ability to process a git URL, in addition to the current support for
> > de-tarring (and applying patches).  This feature would make Fuego similar
> > to other build systems that can retrieve source via repositories, so we
> might
> > want to use the same terminology or conventions that other systems do
> > (maybe copy (at least partially) what Yocto Project does, as some segment
> > of our user base may have experience with that).
> >
> > One thing those systems support is specifying a git commit id to checkout,
> > along with the repository URL.
> 
> Actually, I was thinking about using the functionality built into jenkins.
> Jenkins
> allows monitoring git repositories and trigger a test when there is an update
> for example.

Hmmm.  OK.  I'll be interested to see what this solution looks like.
To be honest, I'm trying to use as few Jenkins-isms as possible in the
core script system, to allow people to use the script system with other
front-ends (including their own proprietary front ends).  However, if
Jenkins already has this capability, it seems like a good idea to leverage it.

One thing I worry about, with dynamic update of the test program
source, is making sure we associate results with a particular version 
of the test source (and build environment).  It's important for regression
testing to limit the number of variables (things that change) from
one run to the next.  This is one reason that snapshotting the source is
useful.  Having different source for test programs at different test
node diminishes the ability to compare test results from different nodes. 
Or at least it makes it more complicated to determine the source of a
regression, if there is one.

But I recognize that our current system of bundling the snapshotted
source is cumbersome.

> # By the way, because of the size of the tarballs the repository can't be
> hosted on Github (on a free account).

Yes - this is one of the results of snapshotting the source for the test programs.
I've considered different mechanisms to deal with this.  One feature that's
been requested, and that I'm working towards, is to use test programs already
on target, from the distribution that's installed.  Another is to create a separate
location (like a web or ftp server) where test programs (either source or binaries)
can be downloaded from. But this last option adds more complexity to the image
build step as well as further complicates the release management for Fuego.
It adds yet another thing that must be maintained going forward, and something
that we'd want to automate the management of.

As an aside, this solution look surprisingly like the one that Yocto Project
had to create with their mirror system, when they faced similar issues with
availability of the source for their packages.

One question I have about this, is how often test programs themselves
change, vs. the software and hardware that is being tested.  I haven't been
doing this long enough to determine if things change rapidly or not.
My suspicion is that some tests are quite stagnant, while other are seeing
active development.  It is hard to determine how much effort will be
required to keep test source and/or test source references up-to-date
in Fuego.  Unfortunately, this is an issue that has been largely unaddressed
until now.  So maybe a nice side effect of working on the dynamic source
referencing will be to resolve some issues here.

Thanks for the discussion.  I look forward to seeing your work in this area.
 -- Tim


More information about the Fuego mailing list