13:03:37 <mvollmer> #startmeeting 13:03:37 <zodbot> Meeting started Mon Apr 20 13:03:37 2015 UTC. The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:03:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:03:48 <mvollmer> .hello mvo 13:03:49 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com> 13:04:18 <mvollmer> #topic Agenda 13:04:27 <dperpeet> .hello dperpeet 13:04:28 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com> 13:04:37 <mvollmer> * Plot zooming 13:05:04 <andreasn> .hello andreasn 13:05:06 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com> 13:05:16 <mvollmer> * Storage rewrite 13:06:18 <andreasn> * password strength 13:06:27 <stefw> * Kubernetes designs 13:06:44 <stefw> * Status: new check-storage test 13:06:51 <stefw> * Status: removing an old test 13:06:59 <stefw> .hello stefw 13:07:00 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com> 13:07:33 <mvollmer> ok, let's start. 13:07:40 <mvollmer> #topic Plot zooming 13:08:00 <mvollmer> I did some polish on https://github.com/cockpit-project/cockpit/pull/2020 13:08:05 <mvollmer> i think it getting there 13:08:13 <andreasn> it's starting to shape up indeed! 13:08:20 <mvollmer> dperpeet fixed the same bugs re formatting numbers 13:08:53 <dperpeet> merged version is now pushed 13:09:03 <dperpeet> (merged our two versions) 13:09:17 <mvollmer> I want to finish that and then fix the On/Off button, and then move on. 13:09:28 <dperpeet> #info https://github.com/cockpit-project/cockpit/pull/2182 13:09:46 <mvollmer> eot? 13:09:55 <andreasn> I think so, yes 13:09:59 <mvollmer> yep 13:10:03 <andreasn> I'll keep testing it and comment on the issue 13:10:17 <mvollmer> #topic Storage rewrite 13:10:41 <mvollmer> so that's the next big thing on my list 13:10:59 <andreasn> what's the scope of that? 13:11:03 <mvollmer> getting mentally ready for it, but no code written yet 13:11:20 <mvollmer> it will look the same as now, but without cockpitd, and with mustache. 13:11:37 <mvollmer> stefw, you had an idea for the storage rewrite? 13:11:37 <andreasn> ah, cool 13:11:50 <dperpeet> mvollmer, what's your timetable on this? 13:11:55 <petervo> how much can it be broken down? 13:11:57 <mvollmer> no idea 13:12:00 <dperpeet> I wanted to refactor docker into its own package at one point soon 13:12:11 <dperpeet> and they're both in shell 13:12:18 <stefw> i don't know if you've been following the discussion about how atomic prefers to setup an LVM thin pool for docker storage 13:12:26 <mvollmer> petervo, it is tempting to do it one go 13:12:28 <stefw> but it's the sorta thing that's begging for a UI 13:12:45 <mvollmer> a little bit 13:12:51 <stefw> it would be interesting to at least come up with an imagined implementation of how we would do that 13:12:57 <stefw> and keep it in mind during the storage refactor 13:13:00 <stefw> for example 13:13:04 <mvollmer> ahh, of course, one big change is to use the new sotraged daemon 13:13:04 <andreasn> stefw: sounds like a good idea 13:13:19 <mvollmer> all in all I would expect a couple of weeks. 13:13:21 <stefw> we might decide: "lets keep docker storage in its own code-base, and use lvm directly" 13:13:43 <stefw> or we might decide: lets use the new storaged for this, and implement it in the main storage package 13:13:52 <mvollmer> right 13:14:05 <mvollmer> there is nothing wrong with the first approach. 13:14:21 <mvollmer> ad it reduces dependencies 13:14:40 <andreasn> is the discussion on atomic-devel? 13:14:58 <stefw> this: https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2015-April/msg00033.html 13:15:22 <stefw> https://github.com/projectatomic/docker-storage-setup 13:16:39 <mvollmer> would we have UI to edit /etc/sysconfig/ and then run the docker-storage-setup script? 13:17:01 <stefw> hmmm, i had thought it would be more about resizing an already existing pool 13:17:06 <mvollmer> i see 13:17:06 <andreasn> what's in /etc/sysconfig? 13:17:11 <stefw> but obviously we would need to consider the feature properly 13:17:20 <mvollmer> yes 13:17:31 <andreasn> so it would come with a pool by default? and then it should be easy to pop in another drive and just expand that pool? 13:17:43 <andreasn> another disk 13:17:57 <stefw> i think the plan is that it comes with the pool by default 13:18:14 <stefw> there's heated discussion about this on various mailing lists, but it seems like such an LVM pool couldn't be put on your primary disk after the fact 13:18:44 <andreasn> ugh 13:18:53 <stefw> so in my mind it'd just be a resizer bar 13:18:56 <stefw> and an 'add disk' option 13:18:59 <stefw> but i could be wrong 13:19:03 <stefw> we can discuss this and research it more later 13:19:07 <mvollmer> yea 13:19:07 <andreasn> sure 13:19:39 <mvollmer> (i think docker uses devicemapper directly, no? anyway, needs research.) 13:19:56 <stefw> as i understand it "they" are trying to deprecate devicemapper use of docker 13:20:01 <stefw> because it uses a loop device 13:20:04 <stefw> that is prone to problems 13:20:12 <stefw> i think "they" is the LVM folks 13:20:21 <petervo> devicemapper doesn't mean loop files 13:20:22 <stefw> but as with all of this, i might be wrong 13:20:41 <stefw> ah, you're right 13:20:44 <petervo> there are a lot of options 13:21:13 <petervo> that docker supports, and figuring out exactly what it's using isn't always so easy 13:21:33 <stefw> the various storage backends are provided as options to docker 13:21:37 <mvollmer> my impression from a large distance is that "they" use lvm to create a thin pool, and then go and put stuff on top of it via devicemapper 13:21:38 <stefw> on the command line 13:21:41 <mvollmer> and not via lvm. 13:21:45 <stefw> mvollmer, aha 13:21:50 <stefw> yes, that sounds right 13:22:14 <mvollmer> and the lvm people don't like their thinpools being used that way, maybe. 13:22:37 <mvollmer> but, not really our problem, no? 13:22:38 <stefw> well i think they don't like loop being used 13:22:41 <stefw> no it's not our problem 13:22:49 <stefw> our problem is just to provide a ui for the atomic storage configuration 13:22:50 <petervo> the main issues i think is that loop files are not stable 13:22:59 <stefw> which is a thinpool divided between root fs and docker storage 13:23:03 <stefw> and moving that bar back and forth 13:23:04 <stefw> if we can 13:23:30 <andreasn> that would be cool 13:23:49 <jscotka> petervo, mvollmer stefw dperpeet I have little bit troubles with managing storages. I have fear that that have so bit amount of features, that is is unable to do it well. 13:24:05 <stefw> well thist is very well scoped 13:24:16 <stefw> and that's why i wanted to bring it to mvollmer's attention before the storage refactor 13:24:28 <stefw> so he can decide whether it fits into the main storage package, or perhaps should be done separately 13:24:37 <jscotka> I have experiences from anaconda storage management, and in each version I have to learn how to do same thing. 13:25:02 <andreasn> another thing for storage is the iscsi work that fabian wanted to work on, not sure when that will happen though 13:25:11 <mvollmer> yep, I keep this in mind. 13:25:28 <mvollmer> at least there can be links between docker and storage 13:25:43 <stefw> indeed 13:25:57 <mvollmer> ok, next? 13:26:00 <dperpeet> there probably have to be, in order to use docker properly 13:26:16 <mvollmer> #topic password strength 13:26:48 <andreasn> https://github.com/cockpit-project/cockpit/pull/2061 13:27:10 <andreasn> this one is close to done 13:27:24 <andreasn> great work by fridex 13:27:34 <stefw> cool 13:28:09 <mvollmer> yep 13:28:10 <andreasn> I'll do a patch to move the bar up under the entry later today 13:28:17 <stefw> does it look like the designs? 13:28:34 <stefw> which is to say, "i hope so" 13:28:43 <andreasn> it's close, but not 100% there 13:28:46 <stefw> k 13:29:13 <andreasn> he needed some help with the layout, so I'll make a pull request to fix the last layout issue 13:29:39 <andreasn> next topic 13:29:49 <dperpeet> andreasn, make sure to fix the typo in css https://github.com/cockpit-project/cockpit/pull/2061/files#diff-46172ae369a98a67b65db5d9cfc6f28cR487 13:29:59 <dperpeet> strength 13:30:06 <dperpeet> saves time on review later 13:30:18 <andreasn> hups! 13:30:21 <andreasn> yep 13:30:51 <mvollmer> #topic Kubernetes designs 13:31:24 <stefw> i've worked on some more of the kubernetes dashboard designs 13:31:34 <stefw> they're nearly all there now, with the exception of the 'add node' dialog 13:31:46 <stefw> https://github.com/cockpit-project/cockpit/wiki/Feature:-Kubernetes:-Basic-Dashboard 13:31:55 <stefw> https://github.com/cockpit-project/cockpit/wiki/Feature:-Kubernetes:-Basic-Graphs 13:32:03 <stefw> https://github.com/cockpit-project/cockpit/wiki/Feature:-Kubernetes:-Deploy-application 13:32:08 <stefw> https://github.com/cockpit-project/cockpit/wiki/Feature:-Kubernetes:-Adjust-service 13:32:21 <stefw> subin has been implementing the 'Deploy application' and is just tweaking a few of the looks and behavior 13:32:27 <stefw> i'm working on the graphs 13:32:43 <andreasn> looks like very solid designs 13:32:54 <stefw> andreasn, thanks for your help 13:33:16 <stefw> i'm aiming to share the design of 'add node' with that of our normal machines dashboard, and rework the cockpit-setup.js dialogs a bit 13:33:43 <stefw> that's it from me 13:33:59 <andreasn> what of the pages is the add node design on? 13:34:14 <stefw> https://github.com/cockpit-project/cockpit/wiki/Feature:-Kubernetes:-Add-cluster-node 13:34:21 <stefw> no wireframes yet 13:34:34 <andreasn> ah, ok 13:36:45 <andreasn> next? 13:36:49 <mvollmer> ok 13:37:02 <mvollmer> #topic Status: new check-storage test 13:37:34 <mvollmer> stefw? 13:37:42 <stefw> jscotka, ^^ 13:37:44 <stefw> any updates? 13:38:35 <stefw> i guess not 13:38:56 <jscotka> stefw, ah sorry, I've missed that 13:39:03 <stefw> no worries 13:39:19 <jscotka> not, any update. I have another issues now 13:39:32 <jscotka> but I've checked old one 13:39:53 <jscotka> and found that is not so easy to rewrite, as other tests 13:40:23 <jscotka> because on many places there are hardcoded QEMU disc 13:41:23 <mvollmer> is that more difficult to port than changing the names? 13:41:41 <dperpeet> jscotka, short of plugging special drives into bare metal machines, I don't see any good alternatives to creating emulated disks 13:41:51 <jscotka> yes, that could ve ideally soved by variables, and dynamically found names. 13:42:49 <dperpeet> the new test system is already a bit fragile sometimes... I hope dynamically found names don't make it more so 13:43:08 <jscotka> so probably there is problem, if some part of cockpit for ctorage change and also old test will change causes more troubles with rebase new test to new version 13:43:43 <mvollmer> yes, we need to get the new tests running again. 13:43:54 <jscotka> dperpeet, for example in libdisc library I have function, that when disc is created, name is returned as variable 13:43:54 <dperpeet> mvollmer, I haven't stabilized them yet 13:44:10 <dperpeet> the last two days I've been busy with other issues 13:44:32 <jscotka> so I think about to rewrite old test, to use some varibles, to be then easy to port the new test 13:44:35 <jscotka> mvollmer, ^ 13:44:47 <dperpeet> that's a good plan 13:44:50 <mvollmer> yes 13:45:22 <jscotka> than some changes in cockpit will not cause so big issues for new tests 13:45:58 <jscotka> so okay. cool. I'm not sure if I will have time for that this week, but I'll do my best 13:46:32 <mvollmer> ok, I'll keep in contact when I start rewriting the storage code 13:46:51 <mvollmer> the tests will need to be changed for that as well, I am sure 13:46:55 <jscotka> thanks 13:47:03 <jscotka> sound good 13:47:13 <mvollmer> ok, next? 13:47:17 <jscotka> yep 13:47:27 <mvollmer> #topic Status: removing an old test 13:47:35 <dperpeet> like I said, not stable enough yet 13:47:46 <stefw> next topic? 13:47:50 <dperpeet> I've stabilized parts of the script 13:47:54 <stefw> :) 13:47:56 <dperpeet> but it can still stall/hang 13:47:59 <dperpeet> eot 13:48:06 <jscotka> which part is the most frabile? 13:48:07 <mvollmer> :-) 13:48:19 <dperpeet> jscotka, connecting to a machine, waiting, resetting 13:48:29 <dperpeet> there are some issues with the network, dhcp pool, ssh timeouts 13:48:37 <dperpeet> and network resetting on restored machines 13:48:41 <dperpeet> network states 13:48:55 <dperpeet> to name a few 13:49:18 <dperpeet> and if the script fails in the wrong place, everything breaks :D 13:49:27 <jscotka> probably libvirt is nor prepared for so intensive working, seems 13:49:38 <dperpeet> I'll spend another day on it 13:49:49 <jscotka> dperpeet, yep, script is fault tolerant :-) 13:49:52 <dperpeet> and then we'll see 13:50:21 <dperpeet> jscotka, I can share a WIP with you tomorrow if you want 13:50:26 <dperpeet> then you can look at my changes 13:50:31 <jscotka> dperpeet, perfect 13:50:39 <jscotka> thanks 13:50:41 <dperpeet> eot³. 13:52:31 <andreasn> anything else on the agenda? 13:53:32 <mvollmer> no 13:53:51 <mvollmer> any other business? 13:54:12 <sgallagh> Just one thing 13:54:17 <sgallagh> (sorry I'm late) 13:54:26 <mvollmer> np :) 13:54:55 <sgallagh> The Fedora GSoC admins are discussing the slot assignments. We wanted to confirm the Cockpit team still wants two slots. 13:55:25 <sgallagh> (If the answer is yes, you're probably going to get them both) 13:55:46 <dperpeet> I think both candidates show promise 13:55:58 <dperpeet> I meant topics 13:56:01 <dperpeet> three topics 13:56:06 <dperpeet> can't get anything right, heh 13:56:07 <andreasn> what were they now again? 13:56:17 <dperpeet> ui for rolekit 13:56:22 <dperpeet> systemd timers 13:56:26 <dperpeet> and docker volume support 13:57:08 <andreasn> sounds like a good list 13:57:13 <sgallagh> We're definitely going to accept someone for the rolekit UI; which of the other two do we want more? 13:57:32 <dperpeet> systemd timers are more isolated 13:57:47 <sgallagh> Makes sense to me 13:57:48 <dperpeet> docker volumes probably more popular - and a bit more challenging 13:58:05 <dperpeet> our docker environment is a bit more volatile 13:58:19 <dperpeet> so I think for GSoC timers would be the better choice 13:58:31 <dperpeet> stefw, ? 13:59:07 <stefw> i think we want volumes more, but it should be dependent on the student's ability 13:59:10 <stefw> i agree that they're harder 14:00:04 <dperpeet> we would gain more from docker volumes... and we could adjust the level of mentoring if necessary 14:00:45 <andreasn> volumes makes the docker experience a lot more complete 14:01:03 <andreasn> so it would be a bigger gain for us if it's completed 14:01:34 <dperpeet> ok, then I say go for volumes... I'd be willing to put in extra help if necessary to get it done 14:01:35 <sgallagh> Actually, I just took another look at the proposals; we can't do the docker one 14:01:49 <sgallagh> The only one of the three applicants to volunteer for that one was Branislav; who was ineligible. 14:02:18 <sgallagh> Sorry, should have checked that more carefully. 14:02:54 <mvollmer> ok, rolekit and systemd, then? 14:03:04 <sgallagh> Yeah, looks that way. 14:03:14 <mvollmer> ok! 14:03:25 <sgallagh> Turner England on rolekit UI, Jakub Skorepa on timers? 14:03:33 <dperpeet> yes 14:04:21 <mvollmer> alright, are we done? 14:04:30 <sgallagh> Thanks! 14:04:33 <andreasn> I think so 14:04:35 <mvollmer> #endmeeting