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