13:02:26 <stefw> #startmeeting Cockpit
13:02:26 <zodbot> Meeting started Mon Aug 10 13:02:26 2015 UTC.  The chair is stefw. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:02:26 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:02:36 <mvollmer> oh, right.
13:02:49 <mvollmer> .hello mvo
13:02:50 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:03:06 <stefw> #chair dperpeet mvollmer stefw
13:03:06 <zodbot> Current chairs: dperpeet mvollmer stefw
13:03:14 <dperpeet> .hello dperpeet
13:03:16 <zodbot> dperpeet: dperpeet 'Dominik Perpeet' <dperpeet@redhat.com>
13:03:27 <stefw> #topic Agenda
13:03:38 <stefw> * No merge without docs
13:04:16 <dperpeet> * feature request OpenConnect server status https://github.com/cockpit-project/cockpit/wiki/Feature:-Ocserv
13:04:25 <stefw> * Internet Explorer
13:04:38 <mvollmer> * Moving things out of shell
13:05:29 * TonyBoston hides
13:05:30 <stefw> alrighty
13:05:37 <stefw> #topic No merge without docs
13:06:14 <stefw> There was a bit of a discussion in a Red Hat email about challenging projects not to merge code without adding related documentation in the same pull request.
13:06:28 <stefw> Since we already mostly do this, I was wondering if we should formalize it and make it a goal?
13:06:47 <stefw> As before, the Cockpit UI itself shouldn't need copious documentation
13:07:01 <stefw> but the guide needs to be updated as we add features, APIs etc.
13:07:07 <stefw> #info http://files.cockpit-project.org/guide/latest/
13:07:51 <dperpeet> formalize as in update the wiki page on contributions? https://github.com/cockpit-project/cockpit/wiki/Contributing
13:07:51 <stefw> how does that sound?
13:07:58 <stefw> yes, and check for it during review
13:07:59 <dperpeet> and the hacking.md file?
13:08:27 <dperpeet> as I think it's almost implicit now, it's good practice to actually make it an explicit requirement
13:08:50 <stefw> do we have review criteria listed anywhere?
13:09:00 <mvollmer> i don't think so
13:09:14 <dperpeet> we can add it to that page
13:09:25 <dperpeet> I can start a section
13:09:39 <stefw> cool
13:09:52 <stefw> mvollmer, are you good with that?
13:09:57 <mvollmer> sure
13:10:00 <dperpeet> part of the pull request info is on https://github.com/cockpit-project/cockpit/wiki/Roadmap
13:10:14 <dperpeet> but that's more high level
13:10:22 <mvollmer> do we need a code of conduct?
13:10:24 * mvollmer runs
13:10:26 <dperpeet> I propose we put the stuff on Contributing
13:10:29 <stefw> mvollmer, not yet?
13:10:31 <dperpeet> and link to that from the roadmap
13:10:40 <stefw> #action dperpeet will start a review criteria section in wiki and add documentation there
13:11:44 <stefw> next topic?
13:11:44 <dperpeet> for completeness sake, some of that is on https://github.com/cockpit-project/cockpit/wiki/Workflow
13:12:00 <dperpeet> next topic
13:12:06 <stefw> hmmm, true, we should split that out
13:12:30 <stefw> putting the Review criteria section on the Workflow page would be nice
13:12:47 <dperpeet> and fix links on the other two pages I mentioned
13:12:50 <dperpeet> fix / add
13:13:33 <stefw> #topic Feature OpenConnect VPN Server
13:13:43 <dperpeet> we have a feature request for https://github.com/cockpit-project/cockpit/wiki/Feature:-Ocserv
13:13:47 <stefw> This feature is being worked on by nmav, the author of the openconnect server
13:13:52 <stefw> #info https://github.com/cockpit-project/cockpit/wiki/Feature:-Ocserv
13:14:05 <stefw> #info https://github.com/cockpit-project/cockpit/pull/2550
13:14:06 <dperpeet> with some preliminary code in https://github.com/cockpit-project/cockpit/pull/2550
13:14:34 <dperpeet> I believe it fits in nicely as a tool for cockpit
13:14:45 <stefw> The feature is nice but incomplete.
13:15:07 * stefw proposes we wait for andreasn to give it some design love, and help plan out how it can be rounded out into a full feature
13:15:09 <dperpeet> yes, there is discussion on how getting info / working with the server fits into the cockpit concept
13:15:17 <dperpeet> and how to optimize actual use
13:16:05 <mvollmer> could this be an external package?
13:16:23 <mvollmer> i.e., built from a separate source tree?
13:16:49 * stefw wondered about that too ... but i feel it may be premature to get into that
13:17:10 <stefw> especially since we haven't had all that many large contributions to cockpit
13:17:13 <dperpeet> this might be a good candidate to refactor into an external package eventually
13:17:30 <sgallagh> /me turns up
13:17:32 <stefw> Does anyone know if this has any build time deps?
13:17:36 * stefw checks
13:17:42 <dperpeet> shouldn't
13:17:55 <dperpeet> it only tests for the server at runtime
13:18:10 <mvollmer> yes, let's keep in our tree if the contributor prefers that
13:18:12 <stefw> so there's no overhead to developing in tree for the time being right?
13:18:30 <dperpeet> exactly
13:18:40 <mvollmer> not for us, maybe for the author.
13:18:41 <dperpeet> and if we build it as a separate package, refactoring it out is trivial
13:19:10 <dperpeet> I think testing and integration is a lot easier right now if we have it in the tree
13:19:34 <stefw> yup
13:19:38 <dperpeet> especially if it turns out that we need to tweak something in the rest of cockpit
13:19:47 <dperpeet> since we haven't had that many plugins so far
13:20:26 <stefw> #info cockpit-ocserv as an optional subpackage ... which does not prevent later refactor into separate code repo
13:21:35 <stefw> I would like to wait for andreasn and nmav to talk and make sure this can come together design wise.
13:21:56 <dperpeet> yes, I talked to nmav a bit on Friday
13:22:11 <dperpeet> and we need to take a step back from the pull request
13:22:53 <stefw> #info Wait for design from andreasn and feature plan to be more well rounded before merging ocserv subpackage
13:23:01 <stefw> anything else?
13:23:24 <dperpeet> I'll forward the meeting notes on this to nmav
13:23:32 <dperpeet> he had scheduling conflicts
13:24:11 <stefw> #topic Internet Explorer
13:24:20 <stefw> dperpeet, have you been able to make things work with IE11?
13:24:37 <dperpeet> andreasn wasn't available for the css issues
13:24:56 <dperpeet> for the other effect I have a good idea where the problem might be
13:24:57 <stefw> is this tracked anywhere, or still just research?
13:25:12 <dperpeet> it's step-by-step debugging in windows
13:25:39 <dperpeet> if you have a couple of minutes, stefw, I think we can track it down pretty quickly
13:25:42 <sgallagh> dperpeet: Will nmav be at Flock, do you know?
13:25:55 <dperpeet> sgallagh, I don't know
13:26:18 <dperpeet> dperpeet, ie11 ends up in an infinite loop
13:26:28 <sgallagh> ok
13:26:29 <dperpeet> acquire/release of cache
13:26:38 <stefw> dperpeet, interesting
13:27:14 <dperpeet> I could show you this via remote desktop / screen sharing
13:27:19 <stefw> dperpeet, can you file a bug so we can track the problem?
13:27:22 <stefw> and then we can work on it together
13:27:48 <dperpeet> there is that bugzilla entry
13:27:58 <dperpeet> trying to find it
13:28:06 <stefw> do you want to do the back and forth there?
13:28:22 <dperpeet> I can add the stuff I have as a github issue
13:28:37 <dperpeet> do you have access to an ie11 instance?
13:28:45 <stefw> nope
13:29:19 <dperpeet> ok, let me know when you have time and I'll set up the error
13:29:23 <dperpeet> we can screenshare and talk
13:29:35 <dperpeet> it is separate from https://bugzilla.redhat.com/show_bug.cgi?id=1214789
13:29:57 <stefw> ok
13:30:15 <stefw> #topic Moving things out of shell
13:31:27 <mvollmer> right
13:31:41 <mvollmer> so I have started on moving cockpit-docker out of the shell
13:31:48 <stefw> cool
13:31:57 <dperpeet> yes, very nice
13:32:05 <mvollmer> if there is anything more important, I can suspend that, of course
13:32:37 <mvollmer> there is always the tension between rewriting it completely, and just moving code around with minimal changes...
13:32:42 <stefw> right
13:32:50 <mvollmer> for docker, I'll mostly move code
13:32:57 <stefw> do the graphs move out cleanly?
13:32:58 <dperpeet> mvollmer and I talked about this, and we believe it's good to refactor before we work on the container topic
13:33:08 <stefw> makes sense
13:33:15 <mvollmer> stefw, there are 'back references' to shell
13:33:36 <mvollmer> i guess the job isn't done until we get rid of those, too.
13:33:51 <dperpeet> I would favor an approach that doesn't rewrite too much
13:33:56 <mvollmer> yeah
13:34:07 <mvollmer> too easy to end up with a train wreck
13:34:16 <dperpeet> as long as everything docker-specfic is outside of shell/, I think it's better than what we have right now
13:34:33 <mvollmer> graphs are indeed a sore point
13:34:36 <mvollmer> also for storage
13:34:53 <mvollmer> also, we still use cockpit-wrapper for cgroup metrics
13:34:56 <dperpeet> do they need to be refactored out of shell?
13:35:05 <stefw> well yes, eventually
13:35:05 <dperpeet> graphs, that is
13:35:08 <stefw> but it can be a separate pull request
13:35:13 <mvollmer> they need to be redone, also
13:35:16 <stefw> also necessary for cockpit in a container
13:35:56 <dperpeet> I think it'd be great to just make sure to have everything docker related in the docker package
13:36:03 <dperpeet> that's a good scope for this pull request
13:36:09 <mvollmer> yes
13:36:13 <dperpeet> as the title implies :)
13:36:53 <mvollmer> i try to split things reasonably into files right away, this time.
13:37:20 <mvollmer> but the run image dialog, for example, is line for line the same, down to PageRunImage.prototype etc.
13:37:40 <mvollmer> (but it is not hooked into the legacy page machinery)
13:37:56 <mvollmer> maybe I change that once it's all working again.
13:37:58 <mvollmer> let's see.
13:38:16 <mvollmer> DockerClient is exactly the same, etc.
13:38:25 <mvollmer> still using dbus-json1 etc
13:38:33 <mvollmer> later.. :-)
13:38:34 <stefw> only for the graphs right?
13:38:38 <mvollmer> yes
13:38:41 <stefw> that's fine
13:39:17 <mvollmer> so, until you stop me, I think I'll work on this
13:39:32 <mvollmer> next up would be networking, maybe.
13:39:47 <mvollmer> heh, that's gone already, sorry.
13:39:55 <mvollmer> no, it's not.
13:40:15 <dperpeet> but as a separate pull request, please
13:40:35 <mvollmer> of course
13:40:35 <mvollmer> :-)
13:40:40 <mvollmer> ok, eot?
13:40:41 <stefw> ok, all done?
13:40:45 <stefw> #topic Open Floor
13:40:56 <mvollmer> testing on 32 bit, maybe.
13:41:15 <mvollmer> i was about to set up f22 on i686, but virt-builder doesn't have images for that
13:41:58 <mvollmer> should I try harder?
13:42:28 <stefw> i'd be happy if just the unit tests pass
13:42:33 <stefw> not sure we should care about the integration tests
13:42:39 <stefw> i heard Fedora is moving towards deprecating 32-bit
13:42:54 <stefw> sgallagh, does/will Fedora Server have 32-bit builds?
13:43:23 <sgallagh> stefw: At present, we have 32-bit install media and we support it.
13:44:10 <sgallagh> However, it's become apparent that FESCo is willing to allow individual Editions to drop this support if they want to, however we will not be doing so before F24 at the earliest.
13:44:25 <sgallagh> (Since we're past F23 Alpha and it would be inappropriate to make that decision for this release)
13:45:37 <stefw> ok, good to know
13:45:39 <sgallagh> stefw: Logistically speaking, I think Fedora Server will likely carry 32-bit media until such time as the kernel has bitrotten enough that it's more trouble than it's worth
13:45:59 <mvollmer> what about archs other than intel?
13:46:06 <mvollmer> that is, arm?
13:46:11 <mvollmer> same situation there?
13:46:16 <sgallagh> Because "repurposing old hardware" is one of our stated User Stories
13:46:22 <sgallagh> (See the MacGuyver example)
13:46:47 <sgallagh> mvollmer: We support installing Server on any armv7hl that can install using Anaconda
13:47:05 <sgallagh> We don't currently produce prebuilt images, but there have been requests, so that may change in F24.
13:47:35 <sgallagh> The aarch64 folks have been respinning Server install media for that platform, but it's been in their hands. We don't officially support secondary architectures
13:47:59 <mvollmer> so the thoughts about maybe dropping 32 bit support is only for Intel?
13:48:13 <mvollmer> arm 32 bit will be going strong for much longer?
13:48:51 <sgallagh> mvollmer: That's my understanding.
13:48:54 <mvollmer> ok
13:49:03 <sgallagh> The main issue is that no one is maintaining the i686 kernel most of the time
13:49:12 <mvollmer> testing on 32bit intel goes a long way to catch bugs on 32 bit arm, and is much easier
13:49:14 <sgallagh> i686-specific bugs tend not to get caught
13:49:38 <sgallagh> However, ARM has a dedicated team working on it, including kernel people actively doing regression testing.
13:49:41 <sgallagh> While i686 does not
13:50:03 <mvollmer> sounds like we might need a arm machine for testing
13:50:05 <stefw> I think the main issue for cockpit is that we weren't running our unit tests on 32-bit
13:50:39 <sgallagh> mvollmer: Talk to pwhalen; he can walk you through using QEMU to emulate an armv7hl machine
13:50:54 <sgallagh> Which could then be added to your automation suit
13:50:56 <sgallagh> *suite
13:51:05 <stefw> i think we need to approach this step by step
13:51:13 <stefw> and not spend too much time on it, or we can just get lost here forever
13:51:29 <dperpeet> if we can set up a machine, that'd be best I htink
13:51:31 <dperpeet> think
13:51:35 <sgallagh> stefw: FWIW, I tested Cockpit on F23 Alpha RC2 on i686 and did not notice any obvious defiiciencies
13:51:44 <dperpeet> then we can see what fails, similarly to rawhide
13:51:56 <stefw> This all started because 'make check' fails in Brew on i686
13:52:03 <stefw> so perhaps we should just fix that for now.
13:53:20 <mvollmer> andreas has found some bugs re sizes in storage
13:53:46 <mvollmer> there are some places where truncate to 32 bits somewhere in the stack
13:56:54 <stefw> so is that it for today?
13:57:21 <stefw> #endmeeting