Re: About SQL Backend Project (GSoC)
> In previous years you could receive comments there and revise your > application - but I haven't looked in details there this year yet. It is possible to do that. So I would really appreciate a feedback on my proposal (on GSoC platform) if possible so I can improve it before the final submission. Thank you. 2018-03-21 3:04 GMT+00:00 Nizar Benshaqi : >> In previous years you could receive comments there and revise your >> application - but I haven't looked in details there this year yet. > It is possible to do that. > So I would really appreciate a feedback on my proposal (on GSoC > platform) if possible so I can improve it before the final submission. > Thank you. > > 2018-03-18 10:35 GMT+00:00 Martin Husemann : >> On Sat, Mar 17, 2018 at 05:27:52PM +, Nizar Benshaqi wrote: >>> Exactly >>> Is there a previous discussion that I can check about this project? >> >> I don't think so. >> >> I understand David's issues and if the project gets selected, we'll >> deal with it when it is time. >> >> Martin >>
Re: About SQL Backend Project (GSoC)
On Thu, Mar 15, 2018 at 05:52:22AM +, David Holland wrote: > (also, don't forget to think about how the data gets from each testbed > into the integration database) I think this is the only relevant issue (from a GSoC students point of view, at this point in time). A specification certainly needs to be part of the deliverables, but from my point of view is not a must-have in the initial application. This process will have implications for the lifetime/inheritance of our unique test bed identifiers, and that will have consequences for the meta data store (and its flexibility). So yes: it clearly needs to be handled properly in the early design phase, and the overall workflow be documented and discussed before we move on to the implementation phase. But I wouldn't expect a fixed database design in the application either. Martin
Re: About SQL Backend Project (GSoC)
On Tue, Mar 13, 2018 at 08:37:28PM +0100, Martin Husemann wrote: > Assume that the test data will come from different enviroments, so we will > need a bit of meta data, but that is trivial While that's true, details like this are things that sink projects if not ironed out adequately up front. For this project I'd say part of the proposal should be to figure out how to identify the different testbeds producing data and what metadata to store about each one. One of the goals of aggregating this data is to look for patterns, and the metadata in question (things like which architecture, emulator vs. hardware, etc.) is going to be important in doing that. (also, don't forget to think about how the data gets from each testbed into the integration database) -- David A. Holland dholl...@netbsd.org
Re: About SQL Backend Project (GSoC)
On Tue, Mar 13, 2018 at 11:54:33AM +, Nizar Benshaqi wrote: > Hello, > > My name is Nizar Benshaqi , 19 Years old from Morocco, > > I'm really interested in a NetBSD GSoC project: Creating an SQL backend and > statistics/query page for ATF test results ( > https://wiki.netbsd.org/projects/project/atf-sql-backend/) Hello Nizar! > I am an experienced web developer , with knowledge in PostgreSQL , I can > build such project using either PHP , Node.JS or Python ( Depending on your > requirements) for the backend. PostgreSQL and Python sound good. > As for the tool to read the ATF xml data and insert it into the database, I > can build it either using Python , or remotely using PHP (Depending on the > file size). Preferably Python again here... > If you can provide me with ATF xml data I will provide you with more > in-depth details on how to implement and build these tools. A good start is probably to look here: - the list of all currently running tests: http://releng.netbsd.org/test-results.html If you look at the upper (babylo5) tests, you can see what we get currently, e.g. for i386 this month: http://releng.netbsd.org/b5reports/i386/commits-2018.03.html#end If you scroll a bit up, you'll note that at 2018.03.13.02.24.26 a lot of ipsec tests stopped failing. This is exactly the kind of information we would want to search within the database. If you look at individual test lines, you can see the html output, like: http://releng.netbsd.org/b5reports/i386/2018/2018.03.13.02.24.26/test.html or you can download the raw or xml data: http://releng.netbsd.org/b5reports/i386/2018/2018.03.13.02.24.26/test.tps http://releng.netbsd.org/b5reports/i386/2018/2018.03.13.02.24.26/test.xml Your tool should be able to process one of those formats, so I guess xml will be the simple way. Assume that the test data will come from different enviroments, so we will need a bit of meta data, but that is trivial (and mostly static per test environment, with rare changes every year or so, e.g. when the qemu version gets updated). Martin
