16:00:22 #startmeeting Cockpit public meeting 2014-10-27 16:00:23 Meeting started Mon Oct 27 16:00:22 2014 UTC. The chair is stefw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:23 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:33 #meetingname Cockpit 16:00:33 The meeting name has been set to 'cockpit' 16:00:37 it is, but as I just told stefw, I might have to jump out a bit earlier 16:00:37 #chair puiterwijk andreasn mvollmer stefw sgallagh 16:00:37 Current chairs: andreasn mvollmer puiterwijk sgallagh stefw 16:00:48 .hellomynameis andreasn 16:00:52 .hellomynameis mvo 16:00:52 stefw, and me please :-) 16:01:13 ok 16:01:13 andreasn: andreasn 'Andreas Nilsson' 16:01:14 #chair jscotka 16:01:14 Current chairs: andreasn jscotka mvollmer puiterwijk sgallagh stefw 16:01:20 thanks 16:01:30 #topic Welcome ... any agenda points? 16:01:37 mvollmer: mvo 'Marius Vollmer' 16:01:48 * current status of modularization maybe? 16:01:51 * roadmap 16:02:20 * navigation, host switcher 16:02:32 * update from jscotka on testing 16:02:53 * url scheme update? 16:03:10 [cockpit] stefwalter opened pull request #1404: ws: Allow interrupting test-server for coverage purposes (master...interrupt-test-server) http://git.io/e-w0UQ 16:03:35 erps 16:03:36 * cross iframe navigation 16:04:18 okay ... lets begin 16:04:25 yep 16:04:31 #topic Current Modularization Status 16:04:57 I'd like to note that dbus-json3 branch is ready now for porting the Network page 16:05:06 splendid 16:05:15 that was a blocker for moving dbus based pages to separate packages 16:05:31 the other blocker was the url and navigation support, than mvollmer has been working on 16:05:55 "sub navigation" is still a a bit open. 16:06:00 ah i see 16:06:11 well i'll port the Network page to the new dbus in place 16:06:13 i have a demo, but we have to check what we think of that. 16:06:17 and then it should be ready for you to move it into a package 16:06:23 when the sub-navigation is ready 16:06:24 yes 16:06:42 so we can listen to hashchange events on the window of an iframe. 16:06:48 nice 16:06:56 and thereby know what the iframe is doing. 16:07:12 #info dbus-json3 is ready for porting network page 16:07:34 that seems to work, but the code is like 10 minutes old, so... 16:07:39 #action stefw will port Network page to new dbus code 16:08:11 i make a pullrequest that adds navigation to /playground 16:08:17 that's a good idea 16:08:35 #info mvollner will make a pull request with navigation to /playground 16:08:36 #action mvollmer will test out sub task navigation in /playground 16:08:38 heh 16:08:50 the WebSocket forwarding code is done too 16:09:04 #info Websocket forwarding code is done 16:09:05 which allows all the iframes to share a WebSocket and get information such as their default host to connect to 16:09:10 cool 16:09:15 in addition this is where 'pooling' code will live 16:09:30 so that if multiple frames, for example load the package listing, the code in cockpit-main.js will just return cached info 16:09:45 ditto for multiple tasks asking to watch the same dbus objects etc. 16:09:58 we could also use this for cross-iframe navigation if necessary. 16:10:15 yes, if necessary, we could post control messages from frames to parents 16:10:37 but i like hashchange events much better 16:10:44 as you noted above 16:11:17 anything else for modularization status? 16:11:28 the asynchronous module definition code landed 16:11:34 ok, so we all have our work laid out here. 16:11:46 which allows us to also make javascript components for reuse within cockpit and elsewhere 16:11:57 each of which bring in dependencies 16:12:11 i'll rework the 'docker-logs' branch to do this 16:12:38 refactor the docker logs/terminal into a javascript component in the docker package, which is both embeddable and used within cockpit shell 16:12:57 #info asyncronous module definition code landed 16:13:07 sounds good. 16:13:08 AMD is a standard (mostly) defined here: https://github.com/amdjs/amdjs-api/wiki/AMD 16:13:28 okay ... next topic? 16:13:40 one more thing... 16:13:48 yup 16:13:50 how much do we care about URL backeards compatability? 16:14:02 i imagine that at some point we will care very much 16:14:07 with the current version? 16:14:10 yeah 16:14:14 but at this point we're breaking everything between f21 version and what's to come 16:14:37 all backwards compatibility is out the window right now ... and i think that includes the URL (ie: for bookmarks etc.) 16:14:50 I think that's ok at this point in time and space 16:14:54 yep. 16:14:57 agreed 16:15:07 #info backwards compatibility to the f21 version is not a goal right now 16:15:08 but we shouldn't crash with wron URLs of course, which I think we might do... 16:15:20 mvollmer, that would be good to double check 16:15:32 can i put you down for checking that? 16:15:38 #action mvo fuzz testing of URL input 16:15:42 great 16:15:45 yep 16:15:55 * stefw thinks we should do Roadmap topic last 16:16:02 yes 16:16:05 #topic Navigation / Host Switcher 16:16:08 it's just housekeeping 16:16:37 so still some work to be done with the navigation 16:16:38 andreasn and i showed the state of the new navigation to LHinson today from the patternfly team 16:16:46 andreasn, yes 16:16:50 Now it is okay to not be backward compatible. 16:17:13 I have some mockups for fixing it that I made after the meeting with LHinson, but I have them only on paper so far 16:17:38 and I hope it addresses the Dashboard/other Hosts confusion 16:17:52 hope to have them done and online tomorrow 16:18:13 cool 16:19:10 #info most of the new navigation is in place, but needs polishing and addressing of the multiple hosts selection 16:19:21 ok, testing update next? 16:19:24 #info andreasn have mockups on paper, will publish tomorrow 16:19:32 sounds good 16:19:36 #topic Update on testing Cockpit 16:19:46 jscotka, anything interesting to report? 16:20:01 stefw, nothing extra. only some notes. 16:20:14 notes would be interesting 16:20:25 have you run into issues that you'd like to highlight? 16:20:30 1. thanks to all for fixing compilation issues. now it it ready to work in every dir 16:20:48 no, everything now works 16:21:49 only some problems with encoding 16:22:33 If you display disc information page with info about disc, there are strange strings in case of VIRTIO discs 16:22:49 interesting, would you be able to file bugs with screenshots? 16:22:52 some crap unicode chars 16:22:53 that might have been fixed recently. 16:23:03 ah, yes does ring a bell 16:23:25 jscotka, problems with utf-8 encoding not being declared as the charset of the various pages? 16:23:26 Yep, I'll test it on wed, and will see, tomorrow there is public holliday in CZ 16:23:34 https://github.com/cockpit-project/cockpit/commit/4d97c1320e6c4c16e0aef84edbba734d3dbb9946 16:24:43 stefw, it is probably caused by some bad strings of vendoor etc. So there could be some check, that allow only display usable chars. for example only ASCII 16:24:58 i think that we only handle utf-8 16:25:06 and these strings should already be converted into utf-8 16:25:14 there was just a bug where the pages were not loading as utf-8 16:25:16 this should now be fixed 16:25:21 it would be good to check again with git master 16:25:55 #action jscotka will test on wed, to see if encoding issues are fixed in latest cockpit git master 16:25:58 I'm not now sure if it is bug in cockpit. it can be caused by strange strings provided via disc info 16:26:28 but could be fixed on cockpit side, to not show enything if string is ssomehow strange 16:27:27 i think it was just the missing encoding info in our html pages. 16:27:28 next think is that I'll work on testlib.py and vm lib to create something general 16:27:43 nice 16:27:46 that was a temporary regression while shuffling the pieces around. 16:28:01 #info jscotka working on generalizing integration test code 16:28:57 what test is the simplest one? 16:29:27 to be used as sanity check of new classes? 16:29:38 i think check-login 16:29:41 check-dbus is too simple 16:29:56 check login sounds good :-) 16:30:17 okay, I'll use them to check backward compatibility. 16:30:56 alright, next topic? 16:31:00 It is everything from my side. Thanks for nice work. 16:31:24 jscotka, thanks for joining us to help with the testing 16:31:36 #topic URL scheme update 16:32:09 alright 16:32:50 the URLs now look different, but behave the same. 16:33:06 sorry, need to head out already :/ 16:33:11 later! 16:33:30 no /storage/block/vds yet, it is still /storage-details?type=block?id=vda. 16:33:39 andreasn, ok, take care! 16:34:15 it seems pointless to convert all legacy pages to use new URLs. it should be simpler to do that when they become components. 16:34:28 mvollmer, i agree 16:34:59 #info legacy pages will retain old style urls, until they are ported to components 16:35:48 there will be an API in cockpit.js to abstract the hash syntax away from the shell and the components. 16:36:02 * stefw has commented on the API a bit 16:36:29 yes, great stuff. 16:36:48 (cockpit.location is taken, isn't it?) 16:37:50 it is indeed 16:38:15 but we could move it out of the way 16:38:17 since it's not public 16:38:19 yep 16:38:39 i didn't like navigator, actually. 16:39:14 ok, the playground will be the first to use this new API. 16:39:21 and the shell, of course. 16:39:29 playground will be the first component. 16:39:34 nod 16:39:57 and on the way, we will load packages from the target host, using the new package lookup in base. 16:40:07 right 16:40:27 and then we convert #networking to a component, I guess. 16:40:43 * stefw just noticed that #networking *does* rely on ObjectManager 16:40:53 so i have a bit more work to do on the dbus-json3 code before i can port that 16:40:56 on the fake one, no? 16:41:06 yes 16:41:53 alright, next topic? 16:41:55 but only to avoid round-trips, I think, and for collecting garbage objects. 16:42:05 mvollmer, right 16:42:14 #topic Cross Frame Navigation 16:42:29 that was covered, I think. 16:42:36 okay, good enough for now 16:42:41 mind if i insert another agenda point? 16:42:54 #topic Next release, and COPR repository 16:43:03 the playground component will use the new location API to track its hash, and the shell will listen on the iframe 16:43:18 ok. 16:43:30 i don't mind doing a release shortly 16:43:42 at one point, we did say there was something to merge before the new navigation was ready for a release 16:43:45 is that done now? 16:44:12 not sure what that was.... 16:44:38 good enough for me :) 16:44:57 we might think a bit about the first release we put into a COPR, though. 16:45:27 but maybe not too much, it's a COPR after all. 16:45:29 well people are starting to ask how they can try out the latest cockpit 16:45:35 eg: the new navigation stuff 16:45:39 yeah 16:45:44 sgallagh did say he was going to make a COPR 16:45:48 sgallagh are you around? 16:45:48 the host switcher is missing, I'd say. 16:45:53 it's confusing the way it is now. 16:46:01 mvollmer, true 16:46:44 it always feels like that I can use it, but only because I know what happens behind the scenes... :-) 16:47:15 #action stefw will ping sgallagh again about the COPR and see how we can make that work. 16:47:22 #action stefw will do a new release 16:47:45 next topic? 16:47:47 ok, roadmap house keep? 16:47:47 last one 16:47:52 #topic Roadmap 16:47:59 should we wait for andreasn to do that? 16:48:25 let's figure out what has changed. 16:48:41 I can't think of anything... 16:49:39 Should we split "Embedability and embedding"? Is Embedability nearly done/completely done? 16:49:57 hmmm, yes, quite nearly 16:50:04 we might not want to do much about "embedding" right now actually 16:50:35 stefw: I'm here now 16:50:45 ah great, hi sgallagh 16:50:52 I actually have some time today; can you remind me exactly what you want from the COPR? 16:51:03 Are we looking for nightlies, or upstream releases (or both)? 16:51:04 a place to put new releases of Cockpit 16:51:09 so that people can try them out without using Fedora rawhide 16:52:00 OK, and the plan is for it to also include its own SELinux policy, yes? 16:52:10 yes 16:52:18 ok 16:52:49 how will it work, do we just push an srpm somewhere, or build in koji against some other target? 16:53:14 stefw: I'll grant the Cockpit team permission to create builds within the COPR buildsystem 16:53:26 ok 16:53:42 Then you will just create an SRPM, upload it somewhere that it can be reached via HTTP and COPR will build it 16:54:02 I'll look into scripting this process so you can do it as part of the releases as well 16:54:22 Should be fairly easy 16:54:33 nice 16:54:54 I'll get started on that now 16:55:00 #action sgallagh will create the COPR repo and grant access so that builds can be pushed to it 16:56:59 stefw, I have updated the roadmap a bit. 16:57:16 Do you have scripts for the current release process? 16:57:25 sgallagh, no 16:57:29 it's documented 16:57:33 Link, please? 16:57:34 but not scripted 16:57:34 ... 16:57:43 https://github.com/cockpit-project/cockpit/wiki/Maintenance 16:57:49 Thank you 16:58:03 obviously, if you are so inclined, a script would be awesome 16:58:14 stefw, what's missing for "embedability"? 16:58:15 but you're already helping us a lot here with the COPR 16:58:18 (is that even a word?) 16:58:21 so please don't block on scripts 16:58:33 mvollmer, more examples 16:58:39 an example of deep embedding 16:58:43 ok, 16:58:49 where a caller takes over the providing the message transport 16:59:04 but other than that i think embedability is ready for feedback 16:59:13 not having much to embed does hamper that feedback process 16:59:16 currently just the terminal 16:59:21 that's why i'm eager to make the networking page work 16:59:25 who would do deep embedding? our shell, anyone else? 16:59:35 probably CloudForms 16:59:37 or satellite 16:59:41 if they use key based access to machines 16:59:42 oho. 16:59:45 stefw: Understood. I'll get the manual process done first in any case and update the wiki 16:59:46 and want to use their own channels 16:59:56 for carrying the messages 17:00:00 sgallagh, thanks 17:00:13 this was something explicitly requested 17:00:15 stefw, I see. 17:00:20 and it's nice that it fit into the concept of how we're building cockpit too 17:00:23 we are really building something quite big here. 17:00:28 yes, no kidding 17:02:11 alright, i think that's it then 17:02:22 #topic Open Floor 17:02:37 yep 17:03:36 ... crickets 17:03:43 #endmeeting