[Fuego] [PATCH] LTP_one_test: create a Fuego test for a single LTP test

[Daniel Sangorrin]

> > Maybe it's because the recent update broke everything, but "ftc run-test"
> > and "ftc build-jobs" didn't work on my machine.
> That's a problem.  I see you have one bugfix in a later message.  If you are still
> seeing issues, please let me know and I'll try to help fix them.

That was one of the problems.
The second one was that LTP wouldn't build. I just sent a patch that fixes that.
Probably you were testing LTP_one_test after having built LTP from Jenkins.
Now, it seems to work fine.

> 
> > Other than that, I like the ability to use "ftc run-test" within the tests. In this
> > case for the building phase, but I want to use
> > it for creating background loads as well.
> >
> > Do you think there could be some conflict with the nesting of tests such as
> > variable
> > overwriting (Fuego using all these global shell variables is a bit scary) or
> > deadlocks?
> 
> I worried about both of those issues as well.  I checked ftc, and it doesn't
> read much from the environment (only JENKINS_URL, FUEGO_CONTAINER,
> and PS1).  It sets a whole bunch of environment variables when it runs a test,
> and it looks like it sets everything that is used by the core scripts and the parsers.
> (specifically overriding any values that were in the environment when ftc started).
> But it's possible I missed something - so this *is* a concern.
> 
> The core scripts have a few cases where we only set a variable if it's not
> already defined in the environment
> (like BUILD_URL, FUEGO_HOST, BUILD_TIMESTAMP or FUEGO_START_TIME, in
> common.sh),
> or we define a variable using shell default values
> (like MAX_REBOOT_RETRIES or FUEGO_TARGET_TMP) in functions.sh).
> 
> But from what I can tell, both of these sets of variables are handled OK for nested
> builds.
> 
> The parser modules (especially common.py) read a bunch of variables from the
> environment, but
> these should all have been set correctly (and unconditionally) by ftc.
> 
> With regard to locks, I already took care of one issue with nested use of the build lock.
> There may be other resources that pop up in the future, that a parent and child build
> might contend on. But it seems to work correctly now.
> 

Thanks for the explanation, I will keep an eye on it.

Regards,
Daniel 

> 
> > > I'm thinking this approach might be useful to split out
> > > the OpenPosix and realtime subsets of LTP.
> > Sounds good.
> >
> > > Also, it might
> > > work for handling setup and cleanup for subtest groups or
> > > individual tests, like the network-related tests or smack.
> > > For example, instead of doing smack-specific machine setup
> > > in the LTP test, I think we should make something like
> > > Functional.LTP-smack, use the techniques demonstrated here
> > > for building it.  But then have  pre_test, deply, run, and processing
> > > phases be customized for that test's needs. in Functional.LTP-smack's
> > > fuego_test.sh.
> >
> > Yeah, let's split corner cases. Otherwise things will get too complicated to
> > handle.
> 
> Agreed - thanks for the feedback.
>  -- Tim