14:00:23 <mvollmer> #startmeeting weekly meeting
14:00:23 <zodbot> Meeting started Mon Mar  7 14:00:23 2016 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:00:23 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:00:23 <zodbot> The meeting name has been set to 'weekly_meeting'
14:00:26 <andreasn_> others that are not only you and me are allowed to run the meeting as well :)
14:00:28 <mvollmer> .hello mvo
14:00:29 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:00:33 <andreasn> .hello andreasn
14:00:40 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:00:42 <mvollmer> #topic Agenda
14:00:55 <andreasn> #troubleshooting
14:01:03 <andreasn> #storage fixes
14:01:12 <mvollmer> #fedora-24
14:01:38 <mvollmer> let's wait a bit
14:01:43 <andreasn> sure
14:01:46 * mvollmer makes tea
14:02:54 * larsu wonders how this works
14:03:07 <larsu> .hello larsu
14:03:08 <zodbot> larsu: Sorry, but you don't exist
14:03:13 <larsu> uh oh
14:03:18 <mvollmer> :-)
14:03:30 <mvollmer> the .hello is for your fedorapeople account
14:03:36 <mvollmer> i don't know why we do it, actually
14:03:50 <mvollmer> to connect your irc nick with the fedora account
14:04:00 <larsu> me neither, but it seemed like something I should do if I want to attend the meeting :)
14:04:16 <mvollmer> yeah, hmm.
14:04:32 <mvollmer> i guess you will be in the transscript anyway
14:05:33 <mvollmer> alright, let's go
14:05:40 <mvollmer> larsu, anything for the agenda?
14:06:22 <larsu> could talk about #debian real quick - but there's no a lot of news
14:06:45 <mvollmer> sounds good
14:07:02 <mvollmer> (heh, did we just invent a new #convention? :-)
14:07:12 <andreasn> hehe
14:07:22 <mvollmer> #topic Troubleshooting
14:07:32 <andreasn> all right
14:07:49 <andreasn> so I met with larsu, stefw and dperpeet to talk about this a bit more in detail
14:08:05 <andreasn> #link https://github.com/cockpit-project/cockpit/wiki/Feature:-Troubleshooting
14:08:38 <andreasn> and there are some things that is currently missing in the design
14:08:46 <andreasn> such as, how do you dismiss things
14:09:11 <mvollmer> yeah, didn't we have some idea?
14:09:12 <andreasn> and possibly never have them show ever again
14:09:15 <mvollmer> *ideas
14:09:39 <andreasn> and one idea there is to make it a dashboard display thing
14:09:58 <mvollmer> we would store dismissals in the journal
14:10:18 <andreasn> because you might not care about SELinux errors on the highest level, but it makes sense to still show it on the SELinux page
14:10:28 <mvollmer> or are you talking about 'filters' that also apply to future events?
14:10:35 <mvollmer> right
14:10:48 <andreasn> yes, exactly, and mostly about how the user experience of that would be
14:11:11 <andreasn> so I have some more work to do there
14:11:16 <mvollmer> yeah, and then we are talking about, is the dashboard config per user, per machine, or what
14:11:29 <mvollmer> i guess we have to tackle this
14:11:35 <larsu> mvollmer: we could have something like "I've seen these errors" in the journal, but not "I never want to see this kind of error again"
14:11:37 <andreasn> yes, exactly
14:11:51 <mvollmer> larsu, yes
14:12:18 <andreasn> the third option would be "per browser", but that is just terrible if an admin has several devices
14:12:29 <mvollmer> it could be like the machine color, "i want this machine to be blue, and not show selinux errors"
14:12:38 <larsu> right
14:13:26 <andreasn> there is also the case where you are several admins per server. If I have a server that I admin together with larsu, he might care deeply about the selinux errors, while I don't
14:13:39 <mvollmer> yep
14:13:43 <mvollmer> and he might hate blue
14:14:05 <andreasn> or be unable to see the difference between the red and the green server, due to color blindness
14:14:12 <andreasn> etc
14:14:36 <mvollmer> but the color could be treated like the hostname, and there might be a sticker on the actual machine in that color etc
14:14:47 <mvollmer> so it makes sense to not make it per-user
14:14:48 <andreasn> yes, that's true
14:15:29 <mvollmer> we used to have pictures of the simpsons on our machines...
14:15:52 <mvollmer> anyway
14:16:14 <andreasn> at Nokia or at Red Hat?
14:16:21 <mvollmer> andreasn, can we make progress without these configurations?  just with dismissals?
14:16:28 <mvollmer> andreasn, at the university
14:16:32 <stefw> mvollmer, yes, i think so
14:16:33 <andreasn> ah
14:17:01 * larsu is still unsure about the whole dismissal concept to be honest
14:17:22 <mvollmer> implementation or ui?
14:17:26 <larsu> ui
14:17:26 <andreasn> so I think the best is to work out the lower levels first, such as the selinux page, the container page (for the scanning), storage page errors etc.
14:17:44 <larsu> mvollmer: but I trust you guys to know more about the use cases than I do right now :)
14:17:48 <stefw> andreasn, is going to work on the initial designs for it
14:18:05 <mvollmer> andreasn, yes, that sounds good
14:18:50 <andreasn> it seems I'm also didn't post a link to the OSX server notification settings ui
14:18:56 <andreasn> I'll add that to the page
14:19:22 <andreasn> but there is previous art from Windows server, vsphere and some oracle ui there
14:20:29 <andreasn> there was also the question of being able to carry out actions already at the highest level
14:21:24 <mvollmer> repair actions?
14:21:36 <mvollmer> or just dismissal?
14:21:37 <andreasn> yes, I think so, right stefw?
14:21:55 <stefw> well dismissal and rescan/refresh for cases where it makes sense
14:22:10 <mvollmer> okay
14:22:42 <andreasn> I think that was it. Still a lot of details to figure out
14:23:03 <andreasn> but it's making progress
14:23:07 <mvollmer> really nice
14:23:10 <andreasn> eot
14:23:18 <mvollmer> thanks!
14:23:28 <mvollmer> #topic storage fixes
14:23:35 <mvollmer> andreasn?
14:23:45 <andreasn> ah, yes
14:24:11 <andreasn> so we made good progress of the first of the storage papercuts
14:24:44 <andreasn> I also sent a note to the Patternfly mailing list about the slider element
14:25:18 <andreasn> and Matt, who's involved in another storage project said they probably have use for it there too
14:25:43 <andreasn> so we'll see if it ends up in Patternfly proper in the end
14:26:02 <mvollmer> that'd be nice
14:26:03 <andreasn> I filed an issue about it here https://github.com/patternfly/patternfly/issues/210
14:26:20 <mvollmer> the storage sliders are unfortunately blocked on some "devil in the details"
14:26:23 <andreasn> so there is a bit of html+css for it, but how much javascript is it?
14:26:30 <stefw> too much
14:26:59 <andreasn> one minor issue is also that it does inline styling
14:27:06 <andreasn> when it sets the width
14:27:09 <stefw> i need to see how much can be removed
14:27:13 <stefw> hmmm, interesting
14:27:17 <stefw> i'm working on CSP for the docker page
14:27:20 <stefw> so that's a good thing to fix
14:27:45 <stefw> hmmm, i don't think that's inline styling actually
14:27:48 <stefw> due to jQuery magic
14:27:54 <stefw> it sets the style property directly
14:27:57 <stefw> rather than using the style= attribute
14:28:06 <stefw> or is there something else i'm missing?
14:28:09 <stefw> it works with CSP
14:28:12 <andreasn> oh
14:28:13 <stefw> without the inline-style exception
14:28:21 <stefw> at least git master does
14:28:55 <andreasn> <div style="width: 67.9167%;" class="slider-bar"><div class="slider-thumb"></div></div>
14:29:05 <andreasn> is what I get in my browser
14:29:37 <andreasn> but that is not vunerable to CSP?
14:29:59 <stefw> that's the result,
14:30:09 <stefw> of the inspector
14:30:15 <andreasn> aah
14:30:15 <stefw> and not what the code is doing
14:30:21 <stefw> but i'll keep my eye open for this
14:30:24 <stefw> it's a good thing to check for
14:30:27 <andreasn> yeah
14:30:57 <mvollmer> there is more stuff coming re storage polish
14:31:14 <andreasn> what do you want to tackle next?
14:31:17 <mvollmer> andreasn, do you have any priorities in mind?
14:31:27 <mvollmer> not sure
14:31:39 <mvollmer> you have some layout ideas for the details page, right?
14:31:46 <andreasn> prefilled names? or is that full of bees?
14:32:03 <mvollmer> no, i don't think so
14:32:10 <andreasn> yes, that I do. I have some mockups, but I need to go over that again briefly
14:32:15 <mvollmer> ok
14:32:25 <mvollmer> there is also the big raid thing
14:32:32 <mvollmer> where we use lvm2 to make raids
14:32:42 <mvollmer> that needs work in storaged also
14:33:04 <andreasn> I tried to read up on that, but I kind of didn't quite understand it
14:33:14 <mvollmer> my plan is to first make a bigger dialog for creating logical volumes
14:33:29 <mvollmer> where you can select the kind of volume you wantr
14:33:37 <mvollmer> maybe finally tackle stripes
14:33:50 <andreasn> ah, so not only raid0, because that is what it is not basically?
14:34:00 <andreasn> not/now
14:34:10 <mvollmer> all raid types
14:34:46 <andreasn> so right now when one creates a volume, you just get name and disk selection
14:34:52 <andreasn> but also a raid control in that case?
14:35:13 <mvollmer> hmm
14:35:25 <mvollmer> when you create a volume _group_, you get name and disks.
14:35:38 <mvollmer> when you create a volume, you get name and size
14:35:44 <mvollmer> and in the future
14:35:56 <mvollmer> possibly type (raid5, raid6, ...)
14:36:03 <mvollmer> and stripes
14:36:05 <andreasn> ah, right
14:36:06 <mvollmer> and chunk size
14:36:23 <mvollmer> and metadata size
14:36:37 <mvollmer> and metadata chunksize
14:36:42 <mvollmer> :)
14:36:51 <mvollmer> well, there are lots, we have to stop somehwere
14:37:08 <andreasn> yes
14:37:23 <mvollmer> question: should a "thin pool" be a kind of volume?  or something else entirely
14:37:34 <mvollmer> you can't make a filesystem on it
14:37:46 <mvollmer> but it has the some kind of options
14:37:50 <mvollmer> when creating one
14:38:03 <mvollmer> so I guess we put it in the same dialog
14:38:09 <andreasn> what is thin pools now again?
14:38:19 <mvollmer> this will be more clear as I work on it, I hope
14:38:47 <mvollmer> you can have "thinly provisioned volumes", which are bigger than the disk that you have
14:38:52 <andreasn> oh, that thing
14:39:04 <mvollmer> so you can lie to your customers
14:39:20 <mvollmer> but you need a "pool" for those volumes
14:39:31 <andreasn> mulkieran also filed a bunch of multipath issues
14:39:35 <mvollmer> we can maybe hide these pools a bit better
14:39:54 <mvollmer> yes, I have to check those
14:40:05 <mvollmer> i guess they are all correct
14:40:16 <mvollmer> but need to be fixed lower in the stack
14:40:22 <andreasn> ah, right
14:40:35 <andreasn> better move on with the agenda I guess
14:40:35 <mvollmer> people have promised d-bus apis for multipath
14:40:40 <andreasn> 40 minutes in already
14:40:46 <mvollmer> so this will be good input for them
14:40:51 <mvollmer> right
14:41:15 <mvollmer> #topic Fedora 24
14:41:30 <mvollmer> stefw has started with Fedora 24
14:41:36 <mvollmer> and I am continuing
14:41:54 <mvollmer> number of little details, but I think it looks good
14:42:10 <mvollmer> pretty good actually for something that was just branched
14:42:35 <mvollmer> we need --allowerasing to install docker, for example
14:42:44 <mvollmer> which shouldn't be necessary later on
14:43:16 <mvollmer> and switch off gpgcheck, I guess
14:43:26 <andreasn> oh, f24 branched properly now?
14:43:52 <mvollmer> yes, looks like it. :-)
14:44:55 <mvollmer> andreasn, was there some trouble?  I haven't heard any news either way
14:45:24 <andreasn> there was a massive breakdownish thing with glibc locales or something
14:45:27 <andreasn> but I think it was sorted out
14:45:34 <mvollmer> oh
14:46:20 <mvollmer> okay
14:46:27 <mvollmer> #topic Debian
14:46:31 <mvollmer> larsu?
14:46:49 <larsu> ya, like I said, not a lot of news
14:47:10 <larsu> I've reached out to mbiebl and andreas (who did the storaged work)
14:47:13 <andreasn> https://www.happyassassin.net/2016/02/29/fedora-24-and-rawhide-whats-goin-on-aka-why-is-everything-awful/
14:47:22 <andreasn> that was the F24 thing
14:47:57 <larsu> mbiebl hasn't resoponded yet and andreas isn't interested in maintaining storaged or cockpit in debian (not enough time), but he'd help out and maybe even co-maintain
14:48:06 <mvollmer> okay
14:48:22 <mvollmer> storaged upstream is also interested in packaging for debian
14:48:23 <stefw> one question that came up was whether it would help if we made our own repository
14:48:28 <larsu> he put a first storaged package into experimental - I tried it and it works fine (some modules seem disabled though)
14:48:38 <stefw> whether interim, or to demonstrate that the packaging work is largely done, testing is underway
14:48:42 <andreasn> note - Andreas Henriksson, not me :)
14:48:43 <larsu> we could pull that for our CI testing if we want
14:48:51 <mvollmer> yes
14:48:55 <larsu> andreasn: right, sorry, I don't know his nick
14:49:18 <larsu> mvollmer: "yes" we want to?
14:49:36 <mvollmer> "yes" we could :-)
14:49:48 <mvollmer> i think we want, yeah
14:49:52 <larsu> would allow us to enable more tests
14:50:24 <larsu> and shouldn't be that hard to do, just enable experimental for those packages
14:50:25 <mvollmer> yep
14:50:34 <larsu> ok I'll look into that
14:50:53 <mvollmer> great
14:51:03 <larsu> I agree with stefw, having a repository would be a good way to show people what's already working
14:51:17 <larsu> and maybe motivate someone to do the additional work to get it in
14:51:19 <stefw> ideally we would have a builder, perhaps osbs?
14:51:25 <stefw> opensuse build service?
14:51:33 <stefw> i believe it can build debian stuff
14:51:37 <stefw> or is there a better approach?
14:51:41 <mvollmer> yes, that looked workable
14:51:48 <larsu> oh it can? That'd be cool
14:52:59 <larsu> I'll look into that as well
14:53:52 <mvollmer> if we would be able to upload to experimental
14:54:06 <mvollmer> would we do that as sources, or as source+binary?
14:54:19 <mvollmer> i.e., would that allow us to use a debian builder?
14:55:15 <larsu> there are builders for experimental afaik
14:55:35 * larsu wonders what it takes to get upload rights for that...
14:55:57 <mvollmer> experimental also needs to go through NEW, right?
14:56:15 <larsu> not sure
14:56:26 * larsu doesn't know the debian process well
14:56:28 <mvollmer> going through NEW is a important milestone, I'd say
14:57:12 <mvollmer> once we pass that, my understanding is that cockpit would be ready to be distributed by debian, legally etc
14:57:18 <larsu> the NEW queue has stuff for experimental in it, so I guess so
14:57:24 <larsu> but storaged is already in there...
14:58:12 <stefw> i think that because none of us are able to push directly into any debian repo
14:58:21 <stefw> it's important for us to have a repo of what we consider to be latest and stable
14:58:27 <larsu> right
14:58:31 <stefw> that allows other packagers from debian based operating systems
14:58:38 <stefw> to pull from that repo at the schedule that they thing is best
14:58:51 <stefw> think
14:59:23 <larsu> should we maintain two versions of the package then? One for CI and one for release?
15:00:42 <stefw> i don't think we would maintain the CI built packages in a repo
15:00:47 <stefw> or is there a good reason to do so?
15:01:15 <larsu> I mean the debian directory
15:01:26 <larsu> I wonder how much of a difference there would be between the two
15:02:01 <stefw> in the RPMs we do have some differences
15:02:08 <stefw> you can search for 'gitcommit' in the tools/cockpit.spec
15:02:10 <stefw> to give you an idea
15:02:31 <stefw> some of it is intermittent ... eg: a feature is ready for merging to master ... but not ready for release
15:03:20 <larsu> seems to be stuff like "turn on debug info" as well?
15:03:51 <stefw> yup, force debug info to be included
15:03:57 <stefw> the test-assets stuff should be killed soon
15:04:03 <stefw> so there won't be that much difference
15:04:15 <stefw> it'll basically boil down to building from a tarball vs building from a git extract (ie: autogen.sh vs configure)
15:04:20 <stefw> versions
15:04:26 <stefw> debuginfo tweaks
15:04:30 <stefw> stuff like that
15:04:38 <larsu> right
15:05:53 <mvollmer> done?
15:06:08 <mvollmer> #topic aob
15:06:08 <larsu> yeah I think so
15:07:05 <mvollmer> okay!
15:07:11 <mvollmer> thanks everyone.
15:07:18 <mvollmer> #endmeeting