13:06:22 #startmeeting meeting 13:06:22 Meeting started Mon Aug 8 13:06:22 2016 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:06:22 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:06:22 The meeting name has been set to 'meeting' 13:06:27 #tpic Agenda 13:06:32 #topic Agenda 13:06:38 * mvollmer is multitasking too much 13:06:44 .hello harishanand 13:06:44 harish: harishanand 'Harish Anand' 13:06:48 .hello andreasn 13:06:49 andreasn1: andreasn 'Andreas Nilsson' 13:06:50 stefw, thanks 13:06:55 .hello mvo 13:06:55 * timers 13:06:55 mvollmer: mvo 'Marius Vollmer' 13:07:15 .hello dperpeet 13:07:15 dperpeet: dperpeet 'None' 13:08:09 * storage volumes 13:10:11 * showing all networking interfaces 13:10:18 let's start 13:10:23 #topic timers 13:10:44 https://github.com/cockpit-project/cockpit/pull/4645 13:11:29 I haven't read through it all (yet). What's the general status? 13:11:30 we have completed all the works pending, with tests to be corrected for its failures 13:11:40 there are a few races in the tests 13:11:54 tests were a failures due to race conditions 13:11:56 but I think it will be ready to get merged soon 13:12:16 I will make sure that we get this merged this week itself 13:12:27 https://medium.com/@harishanand95/gsoc-week-9-integration-test-cases-ca53eb3c3739#.8q3xg23pl 13:12:51 in this blog post I have talked about all the test cases given for each timers 13:14:33 dperpeet here are the listing of all blogs i have did as part of GsoC https://medium.com/@harishanand95/ 13:14:50 harish, would you like to comment on why you test via cli and not wait for new timer info in the cockpit ui? 13:14:54 after triggering a timer in the tests 13:15:17 yes i will comment it in #4645 13:15:23 I mean here :) 13:15:26 or do you want me to explain it here? 13:15:29 oh yes 13:15:29 briefly 13:15:54 usually one would expect to see the tests cover that, so it's unusual to do it this way 13:17:29 we use CLI because the timer interface next run and last run gives different results even after we set the test machine to 2020-01-01 UTC 13:18:11 this happens because the PhantomJS has the time of the server it is running not that of the test machine 13:18:45 it's possible to get this time difference in the tests, but I think it would be good to push this to a follow-up 13:18:50 and it's not essential 13:19:41 yes there is also the differences in timezones to look forward to 13:19:53 https://medium.com/@harishanand95/gsoc-week-8-different-dates-issue-testing-41a582ce2aa6#.dn8dfq3x6 13:20:21 I have detailed out the issue here. We could calculate the difference and do the testing 13:20:40 which we could do it as a follow up. 13:20:41 great 13:21:12 I think rest of the things are good. 13:21:46 andreasn1 dperpeet there is also a follow up we discussed on setting timers for existing services as well 13:21:59 yeah, sounds good 13:22:15 here we create new services, we have to do that case as well. 13:22:34 good work 13:22:48 let me know when I should review again 13:22:55 thank you ! :) 13:23:29 next? 13:23:36 eot 13:23:40 #topic storage volumes 13:23:58 I thought I had some questions, but I actually didn't I realized 13:24:05 so we can continue this on the PR 13:24:17 alright! :-) 13:24:31 #topic showing all networking interfaces 13:24:50 so, I have done this: https://github.com/cockpit-project/cockpit/pull/4825 13:25:04 we used to only white-list a few interface types 13:25:11 like ethernet, bond, bridge, ... 13:25:29 this meant that wifi, inifiniband, tun/tap, etc would not be shown at all 13:25:38 not even in the traffic graphs 13:25:54 the now shows everything 13:26:00 was there an issue that triggered this change? 13:26:12 not against this change per se, mostly curious 13:26:15 people were requesting infiniband support 13:26:33 what's that? infiniband 13:26:38 and it always confused me on my laptop that the main wifi interface didn't show up 13:26:46 mostly its traffic 13:27:00 i think infiniband is ethernet from IBM 13:27:08 more better 13:27:10 right, and on most servers, the wifi would be non-existant anyway, so it won't hurt 13:27:14 some other cables etc 13:27:25 yeah, makes sense 13:27:52 i had some fear that showing wifi will just mess it up 13:27:57 but it works well 13:28:04 i can even bring it down and up again etc 13:28:14 nice 13:28:31 just not do anything wifi specific like select a hotspot and put in a password etc 13:28:46 but as long as it is configured already, Cockpit will do the right thing and not destroy anything 13:28:52 that's good 13:29:16 stef pointed out that tests are missing... 13:29:23 which is true 13:29:31 but itmight be hard to test this in a VM 13:29:43 i don't hink we can add infiniband to a vm, no? 13:30:02 hmm, but tun/tap should work 13:30:51 maybe not test it with infiniband 13:30:55 but with something else 13:32:38 yeah, something that doesn't need VM support, like tun 13:32:51 http://opennebula.org/community-extension-enables-infiniband-in-kvm-virtual-machines/ ? 13:33:53 andreasn1, is this passthrough, or emulated? 13:34:04 I couldn't figure out 13:34:18 I just googled for "kbm infiniband" 13:34:25 kvm infiniband even 13:34:38 here is someone asking about emulation http://serverfault.com/questions/252407/virtual-infiniband-on-kvm-qemu-or-another-open-source-platform 13:35:43 thanks 13:35:54 i go with tun anyway I think. 13:36:08 mvollmer, if we need to play around with NIC models, let me know 13:36:11 http://libvirt.org/formatdomain.html#elementsNICSModel 13:36:59 dperpeet, we would need to make a interface show up in NetworkManager that is not "ethernet" 13:37:08 like wifi or infiniband 13:37:27 or tun, which I think is easiest and doesn't involve qemu at all 13:37:34 i think 13:37:37 right 13:37:52 well, we can discuss this outside of the meeting 13:37:59 let me know if I should dig into libvirt 13:38:25 okay, let me first try tun 13:38:32 thanks! 13:40:37 done? 13:40:56 #topic any other business 13:41:10 I'm (finally) writing some code to prune logs 13:41:18 that goes into the sink 13:41:58 so for example pull request logs will get removed after 30 days 13:42:04 is that too soon for known issues? 13:42:39 sounds okay 13:43:01 and I'm setting it up in a way that the script runs daily 13:43:41 or rather, each time the sink is called it will check if prune was run in the last 24 hours 13:43:46 and if not, it will prune 13:44:35 or should it be only a timer event? 13:44:43 i.e. if you don't want pruning, you don't set that up? 13:45:03 whatever is easier... 13:45:19 easiest would be to make it timer based 13:45:28 that way it doesn't interfere with the regular sink use 13:45:31 a cron entry in $HOME? 13:45:35 yeah 13:45:42 or systemd timer :) 13:45:59 ahh, can we have them as non-root? 13:46:13 probably 13:46:20 anyway, sounds all good to me 13:46:52 great, thanks 13:46:57 I will exempt release logs 13:47:24 should we keep the verify log output? 13:47:27 for statistics 13:47:50 or rather, the "log" file 13:48:57 hmm, if we keep the verify logs, what is there to prune? 13:49:08 system logs, screenshots 13:49:10 am i misunderstanding? 13:49:11 lots of stuff 13:49:15 ahh, I see 13:49:20 I propose keeping the summary 13:49:22 so to speak 13:49:28 alright, yeah 13:49:33 I can also zip those 13:49:38 and put them in an archive folder 13:50:07 ok, I'll tinker with that 13:51:45 cool 13:52:38 eot 13:53:01 #endmeeting