http://permalink.gmane.org/gmane.linux.kernel.autotest hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.linux.kernel.autotest/7585 <pre>Hi, I have a requirement where I want my test to run iPerf on all existing combination of hosts that we have. For example if I have 2 hosts of type A, B and C each, then I want the test to run between A &amp; B, B &amp; C and A &amp; C. Here A, B and C are labels assigned to the hosts. I am not worried about which host gets picked up from group A, B and C. I don't want to be hard-coding the hosts in my control file as shown in examples of iPerf. How can I achieve something like this in my control file? Do we have access to labels of a machine in the control file? If you have an example that does something similar please point me to that. Thanks, Dev _______________________________________________ Autotest-kernel mailing list Autotest-kernel&lt; at &gt;redhat.com https://www.redhat.com/mailman/listinfo/autotest-kernel</pre> Dev Priya 2013-05-20T20:07:14 http://permalink.gmane.org/gmane.linux.kernel.autotest/7584 <pre>Hi Qingtang I see you make this patch and the commit is : a1c46d139b79ad7f27ab2dee6f6ff58ac9de65d1 But in Fedora 18/17, there still no: 'qtree' in vm.monitor.send_args_cmd("help") but 'info qtree' still works. So I'm very confuse about this patch :) Thanks Mike </pre> Mike Qiu 2013-05-17T03:33:17 http://permalink.gmane.org/gmane.linux.kernel.autotest/7583 <pre>Thanks for the tip, this works :D def step_init(): for x in range(0, 3): run_sleeptest(str(x)) def run_sleeptest(tag): AUTHOR = "Autotest" NAME = "Sleeptest" TIME = "SHORT" TEST_CATEGORY = "Functional" TEST_CLASS = "General" TEST_TYPE = "client" DOC = """ This test simply sleeps for 1 second by default. It's a good way to test profilers and double check that autotest is working. The seconds argument can also be modified to make the machine sleep for as long as needed. """ job.run_test('sleeptest', seconds = 1, tag = tag) On Thu, May 16, 2013 at 4:31 PM, Rajeev S &lt;rajeevs1992&lt; at &gt;gmail.com&gt; wrote: _______________________________________________ Autotest-kernel mailing list Autotest-kernel&lt; at &gt;redhat.com https://www.redhat.com/mailman/listinfo/autotest-kernel</pre> Dev Priya 2013-05-16T23:57:54 http://permalink.gmane.org/gmane.linux.kernel.autotest/7582 <pre>That can be done by creating a different *tag* for each test. For example, tests = ['create', 'list', 'extract', 'copy'] for i in tests: job.run_test('pax', test = i,* tag = i*, archive = ARCHIVE) On Fri, May 17, 2013 at 4:56 AM, Dev Priya &lt;devpriya00&lt; at &gt;gmail.com&gt; wrote: </pre> Rajeev S 2013-05-16T23:31:48 http://permalink.gmane.org/gmane.linux.kernel.autotest/7581 <pre>Hi, I want to be able to run a test n-times from a control file. How do I go about doing this? I tried the following control file but it didn't work - def step_init(): for x in range(0, 3): job.next_step('run_sleeptest) def run_sleeptest(): AUTHOR = "Autotest" NAME = "Sleeptest" TIME = "SHORT" TEST_CATEGORY = "Functional" TEST_CLASS = "General" TEST_TYPE = "client" DOC = """ This test simply sleeps for 1 second by default. It's a good way to test profilers and double check that autotest is working. The seconds argument can also be modified to make the machine sleep for as long as needed. """ job.run_test('sleeptest', seconds = 1) I get an error message saying - Unhandled TestError: sleeptest already exists; multiple tests cannot run with the same subdirectory How can we get this to work? Thanks, Dev _______________________________________________ Autotest-kernel mailing list Autotest-kernel&lt; at &gt;redhat.com https://www.redhat.com/mailman/listinfo/autotest-kerne</pre> Dev Priya 2013-05-16T23:26:46 http://permalink.gmane.org/gmane.linux.kernel.autotest/7579 <pre>Lucas Meneghel Rodrigues invited you to Autotest Weekly Hangout (PST friendly time) Thu, May 23, 8:00 PM PDT Jiří Župka, Fergus Yu, Rajeev S and 22 more are invited View Invitation: https://plus.google.com/_/notifications/ngemlink?&amp;emid=CIiDnZDYmrcCFTCvcgoduGwAAA&amp;path=%2Fevents%2Fc4qglf1ddcmh9hkdflhgi4800po%3Fauthkey%3DCOT0nsjEjrC3ywE%26gpinv%3DAMIXal8miPtJlJoJRwkQD8rAkKB02PCR9t18pDnyH57OARp-JSS-QIzEeDLJwn247uvG6eIeA0muPIlUOi2cDuHrbe-IIyueYu0fwilC9jp-ZC5cT_FMBYk%26gpsrc%3Dgpev0&amp;dt=1368709474754&amp;uob=14 Weekly meeting of people interested in the development of the Autotest framework or any of its subprojects, such as virt-tests. We're going to hold meetings in 2 timings, one more friendly to our friends in China, another one more friendly to our friends on the US east coast, in alternate weeks. This instance is the PST friendly one. 1. Community development  2. Feature roadmap and development status  3. Discuss new tests in development  Meeting agenda and notes: https:/</pre> Lucas Meneghel Rodrigues (Google+ 2013-05-16T13:04:34 http://permalink.gmane.org/gmane.linux.kernel.autotest/7576 <pre> Great, the extra detail helps a lot. I'm not all that familiar with the server-side, lmr is the person for suggestions there. Though, I imagine it will be a lot easier (or exponentially harder) since the results, droppings, and names don't need to be secret. Presuming none of the users (except maybe the secret-approved) have remote (or physical) access to the clients/hosts, lmr's prior-suggestion may meet your needs. I think the client/host systems and source for the test(s) are the biggest threat to secrecy. Mainly because that's where the code lives and will be exposed to some degree in transit. In the same category, I'd be concerned about limited-users somehow injecting or executing other code/tests before, during, or after the secret test(s) run. Secondarily, you will likely need to address the issue of storing any secret test-source access credentials or licenses on the autotest server. For example, if a user can view a server-side control-file or data which allows out-of-band downloading/acces</pre> Chris Evich 2013-05-15T19:32:56 http://permalink.gmane.org/gmane.linux.kernel.autotest/7575 <pre>Chris, Let me try to describe the general model/requirements first 1) There is autotest server with shared hosts/users/tests/recurring jobs etc, there is a requirement of user being registered to use the service 2) special user is a registered user of that setup and wants to find a way to run secret test using that autotest server (with its hosts, install server etc) - as long as only he can initiate secret test, CLI is OK - nobody will see the secret code, okay to see autotest wrapper (control file) - test results don't need to be hidden Based on that: * What does "see" mean, does it include file/directory names as well as contents? I believe the code that does the actual testing should not be visible to anyone outside of predefined set of users; Visibility of file/directory or control file would be ok. * How is the test being run, it this a stand-alone client running the secret test or is it being controlled by an autotest or other server? Autotest CLI, but there is some freedom here as long as </pre> Gawlas, Julius 2013-05-15T17:28:40 http://permalink.gmane.org/gmane.linux.kernel.autotest/7574 <pre> I think we we need more details to help narrow the option list down: * What does "see" mean, does it include file/directory names as well as contents? * How is the test being run, it this a stand-alone client running the secret test or is it being controlled by an autotest or other server? Can unprivileged users run tests on the client? * What level of access to users of each type have to a shell or other interface on the server and/or clients? (i.e. root, sudo, read/execute autotest client tests manually, etc.) * If clients are controlled from a server, do all users (secret-privileged and not) have access to schedule/run tests from the server? * How are test-results to be secured, should all users be able to view them? Do 'secret' test results need to be filtered/obfuscated? * What other specific conditions/aspects should be restricted? </pre> Chris Evich 2013-05-15T16:57:09 http://permalink.gmane.org/gmane.linux.kernel.autotest/7573 <pre> Should be pretty simple. 'Secret' tests were very common back when I worked for IBM, and google also had its own internal tests. What we did back then was to have a separate repo that contains the test modules and put them under client/site_tests. The tests could be elsewhere, global_config.ini can point out to other filesystem locations where this repo could be. There are other options, such as putting them in tarballs and passing the urls to job.run_test(), as it is described here: https://github.com/autotest/autotest/wiki/ExternalTests So I'd say there is no shortage of options you can use here. Now maybe you want to imply that other people can't look at the code or the results of such tests at all. In this case, well... I don't know, there are no provisions for obfuscating test results on an autotest server. Perhaps using kerberos/ldap auth and restricting the list of allowed logins? </pre> Lucas Meneghel Rodrigues 2013-05-15T16:49:44 http://permalink.gmane.org/gmane.linux.kernel.autotest/7572 <pre>One of our users is interested in running a secret test, which is a test that has legal restrictions on who can run it. Let's say we are given some test covered by NDA and it was agreed that only limited set of people can see it and run the code. How would we go about hooking such test to autotest instance? Any ideas or pointers? Thanks Julius _______________________________________________ Autotest-kernel mailing list Autotest-kernel&lt; at &gt;redhat.com https://www.redhat.com/mailman/listinfo/autotest-kernel</pre> Gawlas, Julius 2013-05-15T15:52:03 http://permalink.gmane.org/gmane.linux.kernel.autotest/7571 <pre>Thanks for your feedback. It would be great to have the design open as a github issue. Can people leave comments there? It would be nice to have some conversations over implementation details before we actually do it. I can take the lead on its development and start checking in some working code. Thanks, Dev On Fri, May 10, 2013 at 6:20 AM, Lucas Meneghel Rodrigues &lt;lmr&lt; at &gt;redhat.com&gt;wrote: _______________________________________________ Autotest-kernel mailing list Autotest-kernel&lt; at &gt;redhat.com https://www.redhat.com/mailman/listinfo/autotest-kernel</pre> Dev Priya 2013-05-10T22:03:50 http://permalink.gmane.org/gmane.linux.kernel.autotest/7570 <pre> Hmmmm, anyone know how to use pulseaudio or another mixer to send a phone's output to google hangout input, and visa versa? I'm thinking having a nearby phone on speaker will introduce so much noise, it will not work. I'm half-tempted to hack apart a cell-phone headset cable so I can plug output into computer line-in, and input from computer line-out. But maybe there is a way to do this in software w/ a softphone? </pre> Chris Evich 2013-05-10T18:12:48 http://permalink.gmane.org/gmane.linux.kernel.autotest/7569 <pre> lmr, What do you think about during hangout, can you (or someone) also put one of our conference bridge-lines on speaker phone? Then people on hangout can interact with phone (Though quality will be bad). Also phone bridge can handle many more people than hangout and we have many international toll-free numbers for bridge-system. </pre> Chris Evich 2013-05-10T16:35:59 http://permalink.gmane.org/gmane.linux.kernel.autotest/7568 <pre> That's a great idea. I have some comments to make below. Not that I'm aware. There's the drone architecture in autotest that allows to spread the load of autoserv processes across several machines, that we call drones, but no special treatment is given to log files. Yes, I definitely want to see it in Autotest, as we sometimes have trouble with our internal test grid logs. One thing that I was thinking is that GlusterFS might be an interesting option here. It even has a drop in compatibility library to make GlusterFS to replace HDFS, so that's something interesting to explore. If you feel like it, we could put the design open as a github issue or something, so it can be tracked, and people could help with tasks. Cheers, Lucas </pre> Lucas Meneghel Rodrigues 2013-05-10T13:20:17 http://permalink.gmane.org/gmane.linux.kernel.autotest/7567 <pre> We have some code for kernel version and package version check based on the cfg files in qemu part tests. The code is shows in qemu/control.kernel-version in virt repo(our kernel cfg is under qemu/cfg/host-kernel.cfg). This solution just require user declare the packages that need checked and if the package is not installed, the case will be dropped if the package check is failed. The service check maybe can be done in a similar way. We may have some code to generate test job coverage dashboard. Seems like this items. But still need some work on it. cc Feng Yang </pre> Yiqiao Pu 2013-05-10T10:02:30 http://permalink.gmane.org/gmane.linux.kernel.autotest/7566 <pre>It's here: http://v.youku.com/v_show/id_XNTU0OTA0MDA0.html _______________________________________________ Autotest-kernel mailing list Autotest-kernel&lt; at &gt;redhat.com https://www.redhat.com/mailman/listinfo/autotest-kernel</pre> Qingtang Zhou 2013-05-10T09:51:00 http://permalink.gmane.org/gmane.linux.kernel.autotest/7565 <pre>于 2013/5/10 16:02, Qingtang Zhou 写道: OK, Thanks a lot :) I hope to see Thanks Mike _______________________________________________ Autotest-kernel mailing list Autotest-kernel&lt; at &gt;redhat.com https://www.redhat.com/mailman/listinfo/autotest-kernel</pre> Mike Qiu 2013-05-10T08:19:58 http://permalink.gmane.org/gmane.linux.kernel.autotest/7564 <pre>Oh, hey, Mike, I understand what you're suffering. I've downloaded the video from youtube, then upload it to youku, which is 'Chinese version of youtube'. I'll paste the video link here once the upload progress is done. If you need, I can upload every comming Hangout video to youku. This is what I'm worrying about too... </pre> Qingtang Zhou 2013-05-10T08:02:33 http://permalink.gmane.org/gmane.linux.kernel.autotest/7563 <pre>? 2013/5/9 20:39, Lucas Meneghel Rodrigues ??: Oh, we can't access this website in China, so sad.... also google+ can't access sometimes :) _______________________________________________ Autotest-kernel mailing list Autotest-kernel&lt; at &gt;redhat.com https://www.redhat.com/mailman/listinfo/autotest-kernel</pre> Mike Qiu 2013-05-10T02:45:14 http://permalink.gmane.org/gmane.linux.kernel.autotest/7562 <pre>Hi, I have been working on a persistent log storage solution for Autotest and want to discuss my thoughts with you, seek your advice and investigate if prior work/solution exist on this front. As of now Autotest in its default config stores the logs locally on the results server. We don't get redundancy as well as very large storage capacity in this configuration. To tackle this issue I am thinking of implementing a variant of ResultsArchiver that archives the log files and stores them on HDFS. The proposed changes are like this - 1. Config file will dictate whether to use local storage or HDFS. 2. All HDFS related configs will be in the global config file. 3. ResultsArchiver's HDFS implementation can either use python libraries or wrap command line tools to push a file on HDFS. I am even planning to explore HttpFS for Hadoop. 4. For reading the files, currently Apache file handler handles the file rendering. We can use HttpFS for accessing the files directly from HDFS and this will need some alteration t</pre> Dev Priya 2013-05-09T20:20:45 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.linux.kernel.autotest