13:01:47 <andreasn> #startmeeting Cockpit weekly meeting 2016-04-04 13:01:47 <zodbot> Meeting started Mon Apr 4 13:01:47 2016 UTC. The chair is andreasn. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:01:47 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:01:47 <zodbot> The meeting name has been set to 'cockpit_weekly_meeting_2016-04-04' 13:01:53 <andreasn> #topic agenda 13:02:11 <dperpeet> .hello dperpeet 13:02:12 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com> 13:02:24 <mvollmer> * Raidy storage things 13:02:26 <andreasn> .hello andreasn 13:02:27 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com> 13:02:31 <mvollmer> .hello mvo 13:02:34 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com> 13:03:53 <mvollmer> * Docker storage setup implementation 13:04:54 <andreasn> anything else? 13:05:36 <andreasn> ok, lets go 13:05:44 <stefw> .hello stefw 13:05:45 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com> 13:05:50 <andreasn> #topic Storage RAID 13:06:08 <mvollmer> right 13:06:11 <andreasn> this is the same as lvm-raid, right? 13:06:32 <mvollmer> so I wanted to add support foir "lvcreate --type raid5" (e.g.) to the storage page 13:07:15 <mvollmer> but now I think that this is too involved to do it right now 13:07:23 <mvollmer> it's too much work with the wrong priority 13:07:42 <andreasn> yeah, could be 13:07:52 <mvollmer> I am kinda excited about it, to get all that good stuff into a clean UI 13:08:13 <mvollmer> but it really is a full grown up feature all by itself 13:08:25 <mvollmer> actually, it's a number of features 13:08:49 <mvollmer> weprobably need to very design each type separately 13:08:56 <andreasn> right 13:09:05 <andreasn> each raid type? 13:09:06 <mvollmer> use cases 13:09:10 <mvollmer> yeah 13:09:47 <mvollmer> just letting people make amirror without also letting them decide on which disks it goes is a bit pointless 13:10:16 <andreasn> right, so we're looking at something that would work very differently from what we have now 13:10:24 <mvollmer> I think even striped are non-trivial, what with resizing the volume after adding a new disk. 13:10:53 <andreasn> so should we start by adding a trello card for now, make a feature page and all for it? 13:11:05 <mvollmer> yeah 13:11:28 <mvollmer> i took out of the "storage polish" card 13:11:29 <andreasn> I can set up the feature page if you create the trello card 13:11:33 <mvollmer> okay 13:12:02 <andreasn> all right. Next topic? 13:12:08 <mvollmer> yep. 13:12:18 <mvollmer> wait 13:12:46 <mvollmer> so, the result of me dropping the feature from the polish is #4027 13:13:01 <mvollmer> this gets rid of the dead-end "Make a raid volume" button 13:13:25 <mvollmer> andreasn, you need to review this, I guess 13:13:31 <andreasn> yup! 13:13:47 <andreasn> I'll check it out 13:15:15 <andreasn> all right, next oen 13:15:18 <mvollmer> yes 13:15:35 <andreasn> #topic Docker storage setup implementation 13:15:44 <mvollmer> so I started with this 13:15:58 <mvollmer> right now, the plan is to shuffle the packages a bit 13:16:11 <mvollmer> storaged -> server-storaged 13:16:16 <mvollmer> a new atomic-storaged 13:16:30 <mvollmer> and a new "storaged" package for the common parts 13:16:33 <mvollmer> such as client.js 13:16:49 <andreasn> and only atomic-storaged goes into atomic? 13:16:50 <mvollmer> first step is to get the list of drives into the browser via react 13:16:52 <stefw> does that presume storaged on Atomic Host? 13:16:54 <mvollmer> andreasn, yes. 13:16:59 <dperpeet> server-storaged vs atomic-storaged sounds confusing to me 13:17:01 <mvollmer> stefw, yes. 13:17:22 <mvollmer> yeah, what would a good name be? 13:17:32 <mvollmer> non-atomic-storaged? 13:17:33 <dperpeet> I'm not sure what the goal is 13:17:39 <mvollmer> traditional-storaged? 13:17:50 <dperpeet> are we talking about directories in /pkg or actual deliverable packages 13:17:54 <dperpeet> ? 13:17:59 <mvollmer> directories in pkg/ 13:18:10 <andreasn> server and atomic matches Fedora Server and Fedora Atomic 13:18:25 <andreasn> but yeah, could be confused with -server/-client 13:18:46 <mvollmer> vanilla-storaged? 13:18:49 <dperpeet> -server suffix for packages is very laden with meaning and preconceptions in my mind 13:19:12 <dperpeet> what is the new "storaged" supposed to contain? 13:19:20 <mvollmer> client.js and utils.js for now 13:19:39 <mvollmer> so it's a API package, like base1 13:19:54 <dperpeet> what about storage-base 13:20:00 <stefw> i'm a little worried about trying to build this on storaged to be honest 13:20:07 <mvollmer> instead of "storaged"? 13:20:13 <dperpeet> yes, and not just storaged 13:20:15 <stefw> given that it's not in atomic 13:20:43 <mvollmer> and it is difficult to get there? 13:21:03 <dperpeet> I agree that we shouldn't "hardcode" storaged 13:21:11 <dperpeet> the name of some tool, instead of what it does 13:21:20 <stefw> mvollmer, it's somewhat difficult ... either it should be containerized 13:21:32 <stefw> or somehow well maintained, and a major case made for it to be included 13:21:44 <stefw> if this is the only thing that requires it, then it becomes more difficult 13:21:57 <mvollmer> the last would apply in general, not just for Atomic, no? 13:22:14 <dperpeet> atomic is special due to its rather immutable state 13:22:17 <stefw> well in package based operating systems it's trivial to bring dependencies in 13:22:18 <mvollmer> stefw, are you sayin that we should move away from storaged in general? 13:22:22 <stefw> in comparison 13:22:26 <stefw> mvollmer, no not saying that 13:22:34 <dperpeet> people can't just install it 13:22:40 <dperpeet> (storaged) 13:22:47 <mvollmer> but atomic has higher standards? or just higher hurdles? 13:22:49 <dperpeet> either most people get it by default or none 13:22:53 <dperpeet> the issue is image size 13:22:55 <stefw> mvollmer, both 13:23:00 <dperpeet> and complexity 13:23:13 <stefw> on Atomic there's only two real use cases for storage: 1) docker containers/images and 2) volumes 13:23:22 <stefw> docker-storage-setup is the former and kubernetes storage is the latter 13:23:41 <stefw> it's much less of a free for all, and much more of a constrained use case 13:24:01 <stefw> if we could figure out how to do the docker-storage-setup without (or with optional) storaged related code, it would get used right away 13:24:08 <mvollmer> would it help to make a summary of what storaged gives us? 13:24:19 <stefw> without that, it's going to be a long time before it happens 13:24:26 <mvollmer> alright 13:24:31 <mvollmer> i hear you 13:24:45 <stefw> yup that would help 13:24:57 <mvollmer> hmm 13:24:59 <stefw> obviously containerizing storaged is an option that makes it work on atomic very easily 13:25:49 <mvollmer> so people don't have a problem with running arbitrary priviledged containers? 13:26:06 <dperpeet> well, if they want that specific functionality, why should they? 13:26:10 <dperpeet> it's like installing a package 13:26:14 <stefw> right 13:26:33 <mvollmer> so where is cockpit-bridge on Atomic now? 13:26:36 <mvollmer> in a container? 13:26:49 <mvollmer> where is base1/cockpit.js? 13:26:53 <dperpeet> no, it's always installed 13:27:02 <stefw> mvollmer, those things managed to make it into the host 13:27:12 <mvollmer> it's different for different atomics, right? 13:27:15 <stefw> because they're very small, don't have additional dependencies and so on 13:27:26 <stefw> mvollmer, technically yes, but they end up being rather similar 13:28:03 <dperpeet> cockpit-ws is in a container 13:28:17 <dperpeet> so without that, an atomic system won't answer on :9090 out of the box 13:28:38 <dperpeet> but you can add the system via ssh 13:29:13 <mvollmer> alright, I can't say the logic behind keeping storaged out of Atomic makes sense to me, but I guess it doesn't have to. 13:29:38 <dperpeet> I think with atomic it's more of a consensus on what goes in 13:29:44 <dperpeet> that's why the bar seems higher 13:29:58 <dperpeet> not a consensus _against_ what goes in 13:30:08 <stefw> mvollmer, if you would like to push towards getting storaged in, i'm not against that 13:30:15 <dperpeet> so there needs to be pressure to include it, like stef said the easiest way is to have more consumers 13:30:20 <stefw> but it's a significant effort 13:30:34 <mvollmer> stefw, okay. 13:30:41 <dperpeet> image size is a concern, also 13:30:43 <mvollmer> stefw, who should I talk to? 13:31:14 <stefw> the atomic-devel mailing list would be a good place to start 13:31:18 <stefw> https://lists.projectatomic.io/mailman/listinfo/atomic-devel 13:31:32 <mvollmer> okay, cool, thansk. 13:31:54 * mvollmer kept perl in the Maemo images just by being a stubborn asshole... :-) 13:32:19 <andreasn> eot? 13:32:27 <mvollmer> haha. 13:32:29 <mvollmer> yes. 13:32:43 <andreasn> #topic Open Floor 13:34:01 <larsu> launchpad is not building my package. did you get any email to the cockpituous account, stefw? 13:34:46 <stefw> larsu, i see "New SSH key added to your account." 13:35:15 <larsu> but no build failures? 13:35:16 <stefw> nothing else 13:35:23 <larsu> weird. I'll try further 13:37:06 <andreasn> I guess that's it 13:37:11 <andreasn> #endmeeting