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