13:01:46 #startmeeting 13:01:46 Meeting started Mon Sep 21 13:01:46 2015 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:46 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:01:51 .hello mvo 13:01:52 .hello dperpeet 13:01:52 mvollmer: mvo 'Marius Vollmer' 13:01:58 dperpeet: dperpeet 'Dominik Perpeet' 13:03:50 * migration from old shell pages to packages 13:04:03 * multipath errors 13:04:19 .hello andreasn 13:04:20 dperpeet: andreasn 'Andreas Nilsson' 13:04:22 hups 13:04:25 yes 13:04:30 * ostree updates 13:05:03 * iscsi 13:05:10 * libvirt for testing 13:08:36 okay! 13:08:41 should we start? 13:08:47 yes please 13:08:57 #topic migration from old shell pages to packages 13:09:18 I started out investigating a regression in the datetime dialog #2777 13:09:27 I opened a pull request here https://github.com/cockpit-project/cockpit/pull/2787 13:09:46 I believe the error to stem from a jquery selector https://github.com/cockpit-project/cockpit/pull/2787/files#diff-06cf3683b896cf3916c0439d444a5b27R1163 13:10:00 in a "hack" piece of the code to support the legacy pages 13:10:30 be aware that there might be other issues that stem from these selectors, since we have used this piece in a few places I believe 13:10:50 I noticed that the "enter" event was being called every time the datepicker control opened 13:11:31 I don't think it's worth putting too much time into fixing this, since the code is temporary anyway 13:11:42 unless there are actual issues 13:11:55 end of topic 13:11:57 enter is supposed to be called every time, no? 13:12:04 when you open the page 13:12:11 not when you click inside a field in the page 13:12:27 correct 13:12:39 but it should be called every time a dialog opens, on that dialog. 13:12:46 yes 13:12:56 ohh, I get it! 13:12:58 sorry 13:13:07 the datepicker control is not the dialog 13:13:13 carry on, carry on 13:13:19 yeah, the selector caught sub-controls 13:13:25 right 13:13:31 it's a hack on top of a fix 13:13:32 * stefw was spacing out 13:13:36 but good enough I believe 13:14:03 we could check this in the event handler 13:14:15 too see how many elements are caught? 13:14:16 we could 13:14:24 but like I said... I wouldn't, unless there are actual errors 13:14:35 just be aware if we add controls et cetera 13:14:37 i meant, we could check the "this" variable 13:14:42 hm 13:14:52 anyway, let's do that in the PR, no? 13:15:01 yes 13:15:06 ok 13:15:07 it needs to work today 13:16:42 okay 13:16:47 do you need help with it? 13:17:13 we can discuss it in the pull request I believe 13:17:41 okay 13:18:11 #topic multipath errors 13:18:15 andreasn? 13:18:25 yup 13:18:41 so me and mvollmer discussed https://github.com/cockpit-project/cockpit/pull/2601 a bit 13:19:05 it needs some fixing to the css and some fixes to the wording 13:19:24 and I hope to get around to doing that today 13:19:33 and a fix to the behavior 13:19:42 so that we don't show both errors at the same time 13:19:47 yes 13:20:49 i'd say that after that, Cockpit is ready for multipath 13:21:02 we've listed multpath on our F23 improvements 13:21:05 but of course we don't know what people want to do 13:21:26 so let's reach out to the expoerts 13:21:30 we'll need to figure out how multipath over iscsi will work at some point 13:21:35 *ex-poets 13:22:04 i think it is orthogonal 13:23:01 next? 13:23:03 yes 13:23:18 #topic ostree updates 13:23:54 this is the latest version of the mockup https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/software-updates/software-updates-ostree-alt.png 13:24:54 petervo, stefw: does these look ok? 13:25:14 i think it's good to go. I'd like to do a bit of sprucing up of the css 13:25:21 but that doesn't need to block anything 13:25:33 sounds good 13:26:08 all right, next? 13:27:03 #topic iscsi 13:27:10 good progress 13:27:23 starting to understand the concepts 13:27:42 i am implementing the mockup straight through, pretty much 13:27:55 discovery works, login is next 13:28:21 andreasn and I had some discussion about some details already 13:28:42 like if we can change the IQN for example 13:28:45 or not 13:28:53 maybe the storaged API is too limited, maybe the mockup has too much stuff 13:29:02 yes, like the IQN 13:29:11 and whether we can decide which LUNs to add. 13:29:18 or whether we always get all 13:29:45 I haven't looked into iscsi since the spring, so I'll need to research it a bit 13:29:57 so my idea is now that I take the storaged API as gospel, and then we show the thing to the 'customer'. 13:30:06 sure 13:30:35 and if/when there is feedback, we act on it 13:31:16 so estimate, initial PR before the end of this week. 13:31:25 cool 13:31:38 after that, I am thinking to work a bit on scalability 13:31:52 mostly to see how bad it actually is 13:32:05 X number of LUNs? 13:32:18 but I can pick a cart on trello as well 13:32:26 yeah 13:32:50 *card 13:33:08 next? 13:34:09 yeah 13:34:14 #topic libvirt for testing 13:34:33 well, today I ran into some python crashes (double linked lists apparently) 13:34:48 which might be happening in the libvirt api 13:35:10 [cockpit] stefwalter opened pull request #2790: systemd: Render unit when it goes from invalid to valid (master...render-unit-fix) http://git.io/vn4Ja 13:35:19 so I added a bit of stability code and more verbose handling of resources (libvirt connections et cetera) 13:35:50 other than that virt-builder is currently aborting, so I have to see if that is my fault :) 13:35:55 the crash looked like it was inside malloc, actually. 13:36:20 memory corruption? 13:36:26 I hope not :o 13:36:47 python bindings for libvirt are compiled from c code 13:36:52 libvirt is C? and is linked into the Python interp? 13:36:54 so there might be an error lurking somewhere 13:37:05 right 13:37:26 valgrind? 13:37:31 I'm hopeful to reproduce this more cleanly tonight (or have it working?) 13:37:40 right now I need to get the builder working again 13:37:55 hmm 13:38:11 virt-build should be totally independent from our testvm.py crazyness 13:38:16 yes 13:38:37 /home/dev/.cache/virt-builder/fedora-22.x86_64.1: No space left on device 13:38:41 i'm not so sure about totally independent 13:39:06 mvollmer, we need the right ip addresses, and hostnames in order to do a successful install of ipa and/or openshift (at least) 13:39:06 I will test on master later today 13:39:20 that's afterwards though 13:39:21 I think 13:39:29 when we run our script 13:39:33 stefw, true 13:39:34 right 13:39:52 builder should deliver what we consider to be an out-of-the-box system 13:40:07 we could move a lot of what we do into the builder (ssh keys, passwords, users...) 13:40:23 but right now we have the "clean" divide between upstream and our mess 13:40:50 anyway, if I need help I'll shout out 13:40:55 otherwise this was just a status update 13:41:06 I had hoped for this to be finished by now :) 13:43:21 yep... :-) 13:43:30 #topic Any other business 13:43:36 yup, i have another agenda item 13:43:46 * URL compatibility issues 13:43:57 Mind if I go ahead? 13:44:22 * stefw guesses so 13:44:34 yes, please 13:44:35 So basically as we migrated things to components, we broke multi-machine for those menu items 13:45:06 as things moved out of shell/shell.html older cockpit's no longer knew where to find those things ... and newer cockpits no longer looked at shell/shell.html when accessing certain menu items on old cockpit machines 13:45:11 Leading to lots of "Not Found" 13:45:28 the root cause of this was obviously (my) shortsightedness 13:45:58 So ... we've tried to fix this somewhat by having newer cockpits detect when an older cockpit is in use and try shell/shell.html for certain menu items 13:46:31 however the problem remains: if an old cockpit instance adds a new one to the dashboard, most of the server menu items will just fail 13:46:45 there is one way to fix this: rename the component paths 13:47:10 in the newer versions? 13:47:13 yup 13:47:18 obviously that would break bookmarks and such 13:47:41 but at this point it's choosing between various problems ... and figuring out which one is worse 13:47:58 would we also need to provide a full pkg/shell again? 13:48:02 nope 13:48:31 right, because the fallback code doesn't trigger in the old index.js 13:48:36 yup 13:48:47 one problem that exists: switching between servers while on a section 13:48:59 will not jump to the new component 13:49:02 because they have different paths 13:49:25 hmm 13:49:31 this issue unfortunately already exists somewhat, if in a certain sub-hash of component 13:49:42 anyway ... all of this is rather messy 13:49:46 and i'd really like to clean it up 13:49:55 i've been working on #1788 and #2789 13:50:05 in order to finalize what we have in our component urls 13:50:30 and if we have the need/opportunity to change user visible urls then i'd like to clean those up too as well as some of the behavior associated with them. 13:50:49 yes 13:51:20 i have the feeling that we don't need to care about old versions too much yet 13:51:31 or do we? 13:51:37 we said we did 13:51:37 in rhel? 13:51:44 yeeeees 13:51:48 no, RHEL doesn't care so much 13:51:57 because in RHEL Extras ... you don't get support unless you're using the latest version 13:52:34 right 13:52:49 fedora 21 is abandoned already, right? 13:52:59 i think so 13:53:02 or very nearly 13:53:11 i mean, by us. 13:53:38 right 13:53:41 we don't update it anymore 13:53:57 and we don't support adding it to a dashboard, right? 13:54:02 right 13:54:41 do we like our current URLs? 13:54:45 I am not so sure. 13:55:06 i have a proposal for what i think is much better: 13:55:33 Can we have /storage/ instead of /storage/devices, for example? 13:55:39 https://raw.githubusercontent.com/stefwalter/cockpit/8b4b80894996047a19587a6b352c75d641170197/doc/guide/urls.xml 13:55:42 mvollmer, yes 13:55:49 so component urls don't change (much) 13:56:00 only the addition of /cockpit+embedder there ... as we discussed before 13:56:06 but the user visible urls change 13:56:11 so we have: 13:56:24 http://10.10.10.10/storage 13:56:33 http://10.10.10.10/@other/storage 13:56:42 http://10.10.10.10/storage#/my/sub/hash 13:56:56 http://10.10.10.10/docker#/mycontainer 13:57:13 the entire hash is passed to the components == very predictable understandable 13:57:21 @host is only present when accessing a non-local host 13:57:32 (having "localhost" in the url was confusing to people trying to understand things) 13:57:40 components can have an index.html 13:57:52 http://10.10.10.10/system 13:57:56 loads system/index.html 13:58:05 and http://10.10.10.10/system/services 13:58:05 I like leaving it up to components what to do with the hash part 13:58:08 loads system/services.html 13:58:25 and not worry about the other stuff 13:58:49 sounds great 13:58:58 this uses pushState and replaceState 13:59:01 oh, one last thing 13:59:07 always change the url for / 13:59:29 so you would never (for better or worse) end up with a url like http://10.10.10.10:9090/ 13:59:41 but always would display either: http://10.10.10.10:9090/system 13:59:42 or 13:59:48 http://10.10.10.10:9090/dashboard 13:59:58 unfortunately having / display a valid page, ended up with bugs like this: 13:59:59 what about hard reloads? 14:00:30 in cockpit-ws we answer everything with '@machine' and/or a valid package name as the first path component with index.html 14:00:40 everything else is under /cockpit... 14:00:48 obviously no package can be called 'cockpit' 14:00:51 but we can check for that 14:01:11 this is normal when using pushState() or replaceState() ... although people typically do this with mod_rewrite 14:01:17 see trello for example 14:01:38 anyway, #2789 is what makes this all possible 14:02:09 all urls need to be relative anyway to make that work 14:02:10 okay, then we agree that we fix the comp problem by using different URLs? 14:02:22 or would the new scheme introduce more comp probs? 14:02:39 there would be the case of switching between hosts (mentioned above) 14:02:43 but that needs to be f ixed anyway 14:03:07 where if you're on a certain component, and the other host doesn't have that component 14:03:10 then you get 'Not Found' 14:03:20 right 14:03:37 what if a old dashboard has a machine on it with the new URL scheme? 14:03:42 does it all work? 14:03:55 yes, the components themselves don't change url scheme with this at all 14:03:58 or are there problems because we have changed how chashes work etc? 14:04:03 only the user visible URLs 14:04:05 ahh, I see. 14:04:08 no they don't change 14:04:36 very nice 14:05:56 anyway, the first step to this is reviewing #2788 and #2789 14:06:10 if we're going to do this, i would like to have it done as soon as possible 14:06:13 our next release is coming up shortly. 14:06:42 i think i've done about half of it already 14:06:45 with the work on #2789 14:07:20 okay, first thing tomorrow 14:07:35 or petervo do you have time to review? 14:07:50 because then i can try and have the second half ready by sometime tomorrow morning 14:07:59 sure 14:09:28 i'll get to work then 14:09:41 if that's it for the meeting 14:10:00 i think it is. 14:10:04 thanks everyone! 14:10:09 #endmeeting