13:05:18 <andreasn> #startmeeting
13:05:18 <zodbot> Meeting started Mon Aug  3 13:05:18 2015 UTC.  The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05:18 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:05:24 <andreasn> #topic agenda
13:05:28 <andreasn> .hello andreasn
13:05:29 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:05:33 <dperpeet> .hello dperpeet
13:05:33 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com>
13:06:14 <stefw> .hello stefw
13:06:15 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
13:06:39 <mvollmer> .hello mvo
13:06:40 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:06:50 <andreasn> ok, what do we have on the agenda today
13:06:52 <andreasn> ?
13:06:54 <stefw> * Cockpit info at F23 login screen
13:07:02 <dperpeet> * storage tests
13:07:24 <stefw> * Running shell scripts from javascript
13:08:18 <andreasn> sounds good
13:08:30 <andreasn> #topic Cockpit info at F23 login screen
13:09:10 <stefw> I did some work on agetty to update its VT display when IP addresses change
13:09:19 <stefw> and that means we can include a cockpit address in /etc/issue
13:09:26 <andreasn> wohoo!
13:09:29 <stefw> sgallagh is going to do the work to include it in the fedora-release-server /etc/issue
13:09:36 <dperpeet> nice
13:09:45 <stefw> https://bugzilla.redhat.com/show_bug.cgi?id=1239089
13:09:52 <andreasn> #info https://bugzilla.redhat.com/show_bug.cgi?id=1239089
13:10:57 <andreasn> cool, ok, next
13:11:02 <andreasn> #topic Storage tests
13:11:10 <dperpeet> ok, we have a recurring error
13:11:16 <dperpeet> I understand mvollmer was looking into it?
13:11:23 <mvollmer> yes
13:11:24 <dperpeet> do we need to have a temporary fix?
13:11:33 <mvollmer> I have been running the tests now for some time
13:11:46 <mvollmer> nothing conclusive, unfortunately
13:12:22 <mvollmer> i have seen other failures, for example the wipefs in storaged failing after parted because the new partition block device wasn't found
13:12:28 <mvollmer> which should be 'impossible'
13:12:40 <dperpeet> storaged bug?
13:12:44 <mvollmer> because storaged has explicitly waited for it to appear
13:12:49 <mvollmer> can't say.
13:13:10 <dperpeet> should we add something to ignore that test failure?
13:13:17 <mvollmer> but these are all "once in a million times" bugs...
13:13:20 <dperpeet> I think currently we don't have a way to run a test but ignore failure
13:13:27 <mvollmer> i haven't seen testHidden fail
13:13:34 <dperpeet> the *luks failure crops up quite often
13:13:48 <mvollmer> right
13:13:59 <stefw> these are not once in a million bugs though
13:13:59 <mvollmer> we could make it retry
13:14:06 <stefw> they fail on the test machine
13:14:11 <stefw> 2/3rds of the time
13:14:17 <dperpeet> have you tried with sit on the test machine?
13:14:21 <mvollmer> yes
13:14:38 <dperpeet> ./verify with sit?
13:14:40 <mvollmer> i believe that they fail
13:14:55 <mvollmer> parallel fights with -s, stdin is closed
13:14:56 <dperpeet> can it be reproduced when running just one test?
13:15:22 <mvollmer> no
13:15:33 <mvollmer> or rather, I wasn't able to.
13:15:55 <dperpeet> do you want to keep at it or should someone else look, too?
13:16:01 <mvollmer> from reading the code, fstab _should_ have been updated when Delete returns.
13:16:14 <mvollmer> I'll make some concrete proposals soon, I hope.
13:16:15 <dperpeet> we could watch that file
13:16:20 <dperpeet> in the test
13:16:25 <mvollmer> so let me try a bit longer
13:16:27 <dperpeet> ok
13:16:31 <dperpeet> let me know if I can help
13:17:00 <mvollmer> I'll add some debugging output to the journal, if possible.
13:17:04 <dperpeet> I say we only add stopgap measures if we can't fix it in a day or two
13:17:12 <dperpeet> until then we can just ignore the error
13:17:24 <dperpeet> "manually"
13:17:25 <mvollmer> ok
13:17:53 <mvollmer> there is also the kubernetes failure, which looks frequent to me, too
13:18:06 <stefw> which one?
13:18:12 <mvollmer> > watching kubernetes events failed: 404
13:18:15 <dperpeet> it feels like it's not that frequent anymore
13:18:17 <mvollmer> http://files.cockpit-project.org/hubbot/e880705d43e157d9ca54c6a8191c58103880a08f_f22_x86-64.2/hubbot.html
13:18:48 <dperpeet> ignore what I said, I'm not aware of seeing *that* bug
13:18:57 <stefw> interesting very strange
13:19:28 <mvollmer> also on 22 testing: http://files.cockpit-project.org/hubbot/e880705d43e157d9ca54c6a8191c58103880a08f_f22-t_x86-64.2/hubbot.html
13:19:49 <mvollmer> and atomic: http://files.cockpit-project.org/hubbot/e880705d43e157d9ca54c6a8191c58103880a08f_f22-atomic_x86-64.2/hubbot.html
13:20:05 <mvollmer> all on master, i.e., with recent packages
13:20:05 <dperpeet> just saw it on atomic
13:20:17 <dperpeet> I guess some new update broke our kubernetes api
13:20:23 <mvollmer> likely
13:20:24 <stefw> is that since yseterday?
13:20:29 <stefw> maybe with the v1 api change
13:20:38 <dperpeet> I didn't see it on Friday
13:20:42 <mvollmer> but testHidden etc are broken in the 'stable' images also, right?
13:20:43 <stefw> i'll bump the kubernetes requirement
13:20:52 <dperpeet> mvollmer, yes
13:20:56 <mvollmer> right
13:21:05 <stefw> dperpeet, i wonder if we should rebuild the atomic image
13:21:07 <stefw> does that happen?
13:21:12 <stefw> automatically?
13:21:13 <mvollmer> the storage stack really feels brittle
13:21:24 <dperpeet> stefw, the base image?
13:21:28 <stefw> yeah
13:21:43 <stefw> because i think kubernetes has been updated to a later version in f22 atomic
13:21:51 <stefw> er, maybe it's the f23 atomic
13:22:05 <dperpeet> let me check the script
13:22:26 <dperpeet> we use http://mirror2.hs-esslingen.de/fedora/linux/releases/22/Cloud/x86_64/Images/ as base
13:22:42 <dperpeet> sorry, that was for me
13:22:44 <dperpeet> script says http://download.fedoraproject.org/pub/fedora/linux/releases/22/Cloud/x86_64/Images/
13:22:50 <dperpeet> that's the newest base image
13:22:58 <dperpeet> from May
13:23:15 <stefw> yup, we may need to use f23 to have the kubernetes v1 API
13:23:31 * stefw gets it
13:24:04 <stefw> http://dl.fedoraproject.org/pub/alt/fedora-atomic/images/testing/
13:24:24 <dperpeet> also, manual rebuilding via pull request tag is currently blocking on https://github.com/cockpit-project/hubbot/pull/24
13:24:54 <dperpeet> mvollmer, if you work on storage tests, you can cherry pick https://github.com/cockpit-project/cockpit/pull/2518
13:25:11 <dperpeet> or be aware of it
13:25:34 <dperpeet> I think that can be merged anyway
13:25:36 <mvollmer> yep, thanks
13:25:45 <dperpeet> it can't break the tests more than they already are on atomic
13:25:46 <dperpeet> :)
13:25:50 <mvollmer> yes, forgot about it in the PR...
13:26:32 <andreasn> ok, next topic?
13:26:45 <mvollmer> one thing
13:26:53 <andreasn> sure
13:27:00 <mvollmer> should we consider not running the storage tests in parallel?
13:27:21 <mvollmer> getting rid of the races would be ideal, but then again, they seem to be all over the stack
13:27:34 <dperpeet> it's nice to be aware of possible races
13:27:37 <stefw> whit kind of races?
13:27:46 <stefw> especially with a DBus API we should work to get rid of the races, no?
13:28:07 <mvollmer> fstab changes bubbling up through the stack, for example
13:28:24 <mvollmer> wipefs not seeing the partition that was just created
13:28:52 <stefw> with fstab, shouldn't we force it to be updated before returning from a method that modifies it?
13:28:55 <mvollmer> but I agree, i think we have them under control, almost.
13:29:20 <mvollmer> yes,we can change storaged to do that
13:29:40 <mvollmer> but there are also external changes, and a 'no-block' Format
13:29:41 <dperpeet> or wait for it in the test
13:29:45 <mvollmer> we do
13:29:56 <github> [cockpit] stefwalter opened pull request #2529: Fix the shebang lines in VERIFY and friend (master...fix-shebang-lines) http://git.io/vO4vS
13:30:24 <mvollmer> ok, let's keep them running under load.
13:30:24 <stefw> we don't wait for fstab changes in the test
13:30:32 <stefw> i think we just read /etc/fstab and expect it to have changed
13:30:35 <stefw> (which it should have)
13:30:40 <mvollmer> yes, in that case
13:30:55 <mvollmer> "it's complicated"
13:31:01 <github> [cockpit] stefwalter opened pull request #2530: base: Actually make the waitSeconds change take effect (master...wait-seconds-for-real) http://git.io/vO4vh
13:31:46 <mvollmer> The AddConfiguration method adds to fstab or crypttab, but it doesn't guarantee that the D-Bus properties are up-to-date when it returns.
13:31:58 <mvollmer> that can be fixed
13:32:42 <mvollmer> but there are cases in the tests where fstab really changes asynchronously, and we need to wait for the change.
13:33:05 <mvollmer> and since we need to do that anyway, I didn't want to block on fixing storaged.
13:33:31 <mvollmer> so, yeah, let's find that testHidden bug as well, it's just so frstrating to reproduce.
13:34:39 <mvollmer> eot. :-)
13:34:50 <andreasn> #topic Running shell scripts from javascript
13:35:50 <dperpeet> stefw ^
13:36:06 <stefw> ah yes
13:36:22 <stefw> i've often been thinking about how we would run multiple commands together in the absence of an API without a lot of round trips and races
13:36:28 <stefw> and i have a suggestion
13:36:44 * stefw has added a cockpit.script() function
13:36:51 <stefw> which accepts a shell script to run
13:37:05 <dperpeet> sounds like a good way to avoid boilerplate
13:37:20 <stefw> here: https://github.com/stefwalter/cockpit/commit/bdb991d1ebff052c863f6e23a82cf9000f96c646
13:37:27 <stefw> and here's a use of it: https://github.com/stefwalter/cockpit/commit/3c2672be6cc4db2910580f791504a2b6fe821f37
13:37:37 <stefw> it also allows certain things to be tested better
13:37:42 <stefw> anyway, i wanted to highlight it
13:37:58 <stefw> may be worth thinking about and seeing if it's a recurring pattern we want to use
13:38:06 <stefw> especially in situations where there's no solid API to interact with
13:38:41 <stefw> that's it on that topic
13:38:50 <andreasn> #topic Open Floor
13:39:04 <dperpeet> on the old topic: thanks for that, I think it's a lot cleaner
13:39:24 <stefw> I have a question about Internet Explorer
13:39:32 <stefw> how are we doing with support for IE11 fixes and stuff?
13:39:41 <mvollmer> yeah, makes me think of the "batching" problem we have with stroage
13:39:57 <dperpeet> in progress
13:40:06 <andreasn> sgallagh reported that everything works well in Edge, the new default browser in Windows 10, so that's a positive sign
13:40:14 <mvollmer> stefw, are there guarantees about what happens to a running 'spawn' when the browser disconnects=
13:40:17 <mvollmer> *?
13:40:30 <stefw> mvollmer, we could add an option to the bridge
13:40:37 <mvollmer> is it killed immediately with the bridge, or is it allowed to finish?
13:40:40 <stefw> so that it spawns the process in such a way that it's reparented and not killed when we exit
13:40:44 <mvollmer> does that make sense even?
13:40:47 <stefw> we would need to finish that part of it's interesting
13:41:19 <mvollmer> right
13:41:41 <dperpeet> not automatically killing a job can be pretty dangerous
13:41:49 <dperpeet> considering resources
13:41:58 <mvollmer> yes
13:42:18 <mvollmer> i guess "background batching" needs to be quite explicit.
13:42:27 <stefw> i think so
13:42:31 <dperpeet> is there any urgent need?
13:42:35 <mvollmer> no
13:42:39 <dperpeet> you can always start a job backgrounded yourself in the terminal
13:43:10 <dperpeet> I agree that it would need to be very explicit
13:43:36 <dperpeet> in most cases that job is probably better left to services
13:43:42 <dperpeet> e.g. storaged
13:43:46 <dperpeet> and we just interface with those
13:44:03 <mvollmer> yes
13:44:06 <stefw> certainly
13:44:34 <dperpeet> stefw, are those script commits ready to cherry-pick?
13:44:35 <mvollmer> it means that storaged needs to implement what we need for our UI, but I guess that's ok.
13:45:06 <dperpeet> mvollmer, yeah - I think that suits Cockpit better
13:45:19 <stefw> dperpeet, yes, you could bring them into your keys branch if you want
13:45:29 <dperpeet> then it's all in one place
13:45:37 <dperpeet> and only mvollmer left to review
13:45:52 <stefw> well we can review each other's commits
13:45:58 <dperpeet> yeah :)
13:51:25 <andreasn> anything else?
13:52:21 <mvollmer> no
13:52:28 <andreasn> all right, thanks everyone!
13:52:31 <andreasn> #endmeeting