[Fuego] About ftc requests
daniel.sangorrin at toshiba.co.jp
Wed Jun 13 08:04:40 UTC 2018
> -----Original Message-----
> From: Tim.Bird at sony.com [mailto:Tim.Bird at sony.com]
> > -----Original Message-----
> > From: Daniel Sangorrin
> > Hi Tim,
> > There are several functions in ftc associated to what I think is the prototype
> > of a fuego web app that you showed us during an ELC BoF session.
> > - put-request
> > - put-test
> > - list-requests
> > - run-request
> > - package-run
> > - put-run
> > Are there any news or roadmap for this effort?
> Unfortunately, it's been on my backburner. The main reason it got stalled
> was that I wanted to add security for all these transfers, but that turns it
> into a much bigger project to get this working.
> What we have now is actually very close to sufficient, for an insecure
> (unencrypted, unauthenticated) transfer of materials.
> There's a bug right now on the server with handling json with Unicode
> (non-ASCII) characters, but it shouldn't be too hard to fix that.
Is this code public already?
I think the standard method for authentication is to provide a token in the headers. Of course, this should be passed over https when run remotely.
KernelCI and Squad already have support for it.
> The end goal is to automate some of this, but with very little effort
> (IMHO), we do things like the following workflow manually:
> 1) create a test
> 2) put the test on the server (ftc put-test)
> 3) add a request to run the test on another person's board (ftc put-request)
> we would need a list of host:boards that were available,
> but to start with we could just know each other's host and board names.
> 4) notify the person to run the test (e.g. by e-mail or slack). They would do:
> 5) ftc run-request
> 6) ftc put-run (maybe make it an option to do this automatically for runs based on
> remote requests)
> 7) the original user can download the run (we don't have ftc get-run yet)
> 8) the original user can analyze the results, looking at the logs, collateral material,
I think we should separate visualization from request management and run them as two separated "micro" services. This way we can substitute the implementation of each micro service and we can install only the visualization service locally.
When working with a Visualization service (kernelci, squad, how about "vision" for fuego's?) a user would use functions such as.
ftc put-run <-- with ability to notify by e-mail in case it was a requested run
When working with the Request management a user would use functions such as:
ftc put-board <-- announce that people can test on my board
ftc rm-board <-- remove the board from the fuego network
ftc list-boards <-- add a --remote flag to list also remote boards?
ftc put-request <-- puts the request. I think ftc put-test is not strictly needed because we can pass the test's git repo url or standard fuego test name on the request. ftc put-test/get-test would be convenient for uploading tarballs though to reduce storage needs.
ftc get-request <-- get next request (can be used for polling also)
ftc run-request <-- downloads (and clears) request and executes ftc run-test
[Note] how about using push/pull instead of put/get?
[Note] A lab would run ftc get-request, ftc run-request, ftc put-run automatically using a simple polling script.
> This would allow anyone in the Fuego "network" to run a test on another person's
About "network": Squad supports the concept of teams/groups and group user permissions. Having something similar would be nice.
We also need to be flexible in regards of how we schedule the requests.
For example, we should be able to put requests like:
"run this on a bbb board, I don't care which one"
"run this on a board with a cortex-a9, I don't care which one"
"run this on a board with architecture powerpc, I don't care which one"
> For example, Wang could update his busybox test, and make requests for the tests
> run on boards in my lab, so he can test how the test works on more than just his
> I could test new tests on boards in multiple labs (yours, Liu's, Wang's, Khiem's,
> which would help a lot with test development and quality.
> One thing I'd like to discuss at the Fuego Jamboree is whether someone is willing to
> be the test subject for this, and actually try it out soon after the meeting (the
> > I am currently working on the integration of Fuego with Squad (and KernelCI)
> > so I might touch some code there.
> > Squad supports very similar functionality and can use LAVA to run the
> > requests. However, for now I think that
> > supporting put-run (publishing the results) will be enough for most Fuego
> > users. What do you think?.
> I have no problem with an alternate implementation of put-run. Mine is
> very simple - basically just creating a tar file and sending it to a server.
> Since mine's not being actively used, you can do what you want. Just sideline my
> so if I get serious about this and restart the work, the code is still there
> to integrate. That is, don't delete the code, but just put it in a dead routine or
> something. We could have the code autodetect what type of server it's
> talking to, but to start with we could just have a flag indicating it's a kernelci,
> squad, or fuego server. Or, we could add a configuration item indicating
> the server type in the fuego.conf file.
> We can talk more about this next week.
More information about the Fuego