13:01:00 <andreasn_> #startmeeting Cockpit weekly meeting 2016-07-11
13:01:00 <zodbot> Meeting started Mon Jul 11 13:01:00 2016 UTC.  The chair is andreasn_. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:01:00 <zodbot> The meeting name has been set to 'cockpit_weekly_meeting_2016-07-11'
13:01:08 <andreasn_> .hello andreasn
13:01:09 <zodbot> andreasn_: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:01:19 <mvollmer> .hello mvo
13:01:20 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:01:33 <larsu> .hello larsu
13:01:34 <zodbot> larsu: larsu 'Lars Uebernickel' <lars@uebernic.de>
13:02:10 <harish__> .hello harishanand
13:02:11 <zodbot> harish__: harishanand 'Harish Anand' <harishanand95@gmail.com>
13:02:25 <dperpeet> .hello dperpeet
13:02:26 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
13:03:03 <andreasn_> #topic agenda
13:03:13 <andreasn_> * Networking MTU
13:03:22 <andreasn_> * Subscriptions
13:03:28 <harish__> * timers
13:04:59 <andreasn_> anything else?
13:05:04 <andreasn_> we can start with this
13:05:10 <andreasn_> #topic Networking MTU
13:05:21 <andreasn_> #info https://github.com/cockpit-project/cockpit/pull/4655
13:06:40 <dperpeet> what is this blocking on right now?
13:06:42 <andreasn_> so, this one is pretty urgent, right?
13:06:53 <dperpeet> well, we shouldn't merge anything that doesn't work
13:07:05 <andreasn_> mvollmer commented he wanted to merge as is, but I would like to see some changes to the UI
13:07:16 <mvollmer> I am ok either way
13:07:18 <dperpeet> but I think it wouldn't need to be 100% polished, since users have been requesting that functionality
13:07:19 <andreasn_> but if anything needs to go in today, I would be fine as is
13:07:27 <mvollmer> i have just started hacking on the new UI
13:07:30 <dperpeet> how large are the changes?
13:07:40 <mvollmer> not big
13:07:50 <mvollmer> might be done today
13:07:54 <andreasn_> the next release is on Wednesday, right?
13:07:57 <dperpeet> if we can implement + verify them by tomorrow late morning, I'd be fine
13:08:03 <dperpeet> mid-day tomorrow probably
13:08:19 <mvollmer> okay
13:08:24 <dperpeet> andreasn_, is the current version bad?
13:08:27 <mvollmer> i leave the old stuff untouched
13:08:28 <dperpeet> then merging is out of the question
13:08:31 <mvollmer> just in case
13:08:36 <mvollmer> and make a new PR
13:08:51 <andreasn_> all right
13:09:05 <dperpeet> andreasn_, to be clear: would the current state be ok?
13:09:07 <dperpeet> or bad?
13:09:09 <mvollmer> I would like to say "Automatic" instead of "Default 1500"
13:09:29 <andreasn_> because we don't know that the Default is 1500?
13:09:59 <andreasn_> and err... I guess it's called Automatic rather than Default?
13:10:11 <mvollmer> correct
13:10:21 <andreasn_> yeah, then Atomatic makes sense
13:10:27 <larsu> there's an automatic MTU size mode?
13:10:41 <mvollmer> that's what NM calls it
13:10:57 <mvollmer> i don't know whether it actually goes and measures stuff
13:11:13 <mvollmer> in fact, NM seems to be buggy re actually setting the MTU
13:11:41 <mvollmer> andreasn_, however, NM will tell us the actual MTU, in addition to the configured one.
13:11:54 <mvollmer> i don't know whether we want to go there
13:12:08 <mvollmer> actual != configured is always a bug, no?
13:12:17 <andreasn_> yeah, that sounds terrible
13:12:50 <andreasn_> but I'm no networking guru, so I won't judge the systems :)
13:13:28 <mvollmer> i guess people will tell us if it is important
13:13:33 <andreasn_> yeah
13:13:34 <mvollmer> like they told us about MTU
13:13:39 <mvollmer> so....
13:13:59 <andreasn_> so anyway, if the new UI goes into the release, I'm happy
13:14:07 <andreasn_> but I care less about in what PR it happens
13:14:26 <andreasn_> moving on?
13:14:47 <dperpeet> no
13:14:51 <dperpeet> andreasn_, is the current version bad?
13:14:52 <dperpeet> or ok?
13:14:55 <dperpeet> state of the pr
13:15:07 <dperpeet> just so we know
13:15:24 <andreasn_> I would need to run it again
13:15:25 <dperpeet> i.e. maybe there are small things we can change to make it mergeable
13:15:52 <dperpeet> as long as it says needswork, it won't go in
13:16:03 <andreasn_> testing quickly again now
13:16:07 <dperpeet> and obviously it's better not to have it in than to merge something bad
13:16:12 <dperpeet> we can talk after the meeting, also
13:16:26 <andreasn_> sounds good
13:16:32 <andreasn_> all right, next up
13:16:37 <andreasn_> #topic subscriptions
13:16:44 <dperpeet> well, subscriptions are finally covered by CI
13:16:51 <andreasn_> #info https://github.com/cockpit-project/cockpit/pull/4697
13:17:10 <dperpeet> we also added the organization field
13:17:11 <andreasn_> great to have a local testing server to test with
13:17:15 <dperpeet> yeah
13:17:26 <dperpeet> do we need to document that better? or is it ok to look at the tests?
13:17:43 <andreasn_> I've been fearing that someone at work would come and slap my fingers if I did too crazy stuff :)
13:18:07 <dperpeet> I was wondering if it's worth adding a bit of code to testlib so that we can pause the test after setUp
13:18:12 <dperpeet> :)
13:18:20 <andreasn_> some instructions of what info to provide the test server with might be nicer that digging through the source
13:18:47 <dperpeet> would a good place for that be at the top of the integration test?
13:18:54 <andreasn_> yeah, could be
13:19:02 <github> [cockpit] mvollmer opened pull request #4710: networking: Use links instead of buttons to open dialogs (master...network-links-not-buttons) https://git.io/vKZbV
13:19:05 <andreasn_> I mostly had issues finding the "organization"
13:19:11 <dperpeet> I can add user names that work with the test image
13:19:18 <dperpeet> ok, I'll add some info there
13:19:24 <andreasn_> sounds good
13:19:34 <dperpeet> there's some extra work there soon
13:19:47 <dperpeet> I'm currently working on activation keys and using a proxy
13:21:13 <andreasn_> how does activation keys work?
13:21:20 <andreasn_> (out of curiosity)
13:21:27 <dperpeet> you don't need username and password
13:21:34 <andreasn_> ah, cool
13:21:36 <dperpeet> someone on the server prepared everything you need
13:21:39 <dperpeet> basically a one time password
13:21:44 <dperpeet> all the subscriptions et cetera
13:22:00 <dperpeet> then you don't need to worry about passing all the right settings
13:22:07 <andreasn_> neat
13:23:39 <andreasn_> that's it on that
13:23:42 <andreasn_> next up
13:23:44 <andreasn_> ?
13:23:47 <dperpeet> sure
13:23:50 <andreasn_> #topic systemd timers
13:24:02 <harish__> andreasn dperpeet i have updated systemd-timers https://github.com/cockpit-project/cockpit/pull/4645
13:24:21 <harish__> dperpeet, currently we have creation of timers along with a new service file creation in #4645.
13:24:27 <harish__> Shouldn't we also look at setting up timers for existing service files?
13:24:37 <harish__> andreasn suggested on having " setting up timers for existing service files" as a next follow-up pr.
13:25:01 <andreasn_> I thought that might be most straight forward, rather than piling on the existing PR
13:25:21 <dperpeet> I'm not quite sure about the systemd opinion on this
13:25:43 <harish__> But he had it in the mock-up, I think i got confused with the word "command" in the mockup. :(
13:25:46 <dperpeet> but it looks like setting up timers for existing service files would be good in a follow-up
13:25:55 <dperpeet> so the pr doesn't grow too large
13:26:27 <harish__> okay. I think thats good too.
13:27:08 <harish__> andreasn_
13:27:08 <andreasn_> looks good so far, but I'll keep testing
13:27:21 <harish__> since we use bootstrap-datepicker  for selecting calendar time , any time we click the datepicker input field, all the existing invalid input messages was getting hidden.
13:27:35 <harish__> I have fixed it now in #4645 now.
13:27:41 <andreasn_> that's good
13:27:44 <harish__> andreasn also I haven't used patterns.js for error messages there now.
13:27:59 <andreasn_> are you planning on doing that?
13:28:00 <dperpeet> I don't think this can go in without integration tests
13:28:31 <harish__> I checked in host.js for system-time, i think its done in the similar way
13:28:52 <harish__> it was mentioned as an issue in bootstrap-datepicker
13:29:21 <harish__> may be fixed in newer versions.
13:29:38 <harish__> why are we using datepicker v1.4?
13:30:06 <andreasn_> is there a newer version?
13:30:18 <harish__> v1.6 i think
13:30:55 <andreasn_> does it have the fix for hiding the input messages?
13:31:00 <andreasn_> for not hiding
13:31:28 <dperpeet> if 1.6 fixes issues we have, that's a good reason to update :)
13:31:36 <harish__> i hope so. i haven't checked it.
13:32:12 <harish__> there was also scrolling issues. the datepicker i think has difficulty in finding its location
13:32:20 <dperpeet> harish__, if we need the newer version, we can update datepicker in a separate pr
13:32:27 <harish__> when a scroller exists.
13:32:29 <andreasn_> yeah, if updating to 1.6 fixes an issue, that's a better solution than to work around it
13:33:02 <harish__> yeah i agree. I hope it doesnt add more problems :)
13:33:40 <andreasn_> dperpeet: do you think it's better if harish__ does the update of bootstrap-datepicker as a separate PR?
13:33:49 <dperpeet> harish__, let me know if you need help making a pr to update datepicker
13:33:57 <dperpeet> yes, we need that as a separate pr
13:33:59 <dperpeet> to see if tests fail
13:34:05 <harish__> yea.. i may need help doing that
13:34:33 <harish__> https://medium.com/@harishanand95/gsoc-week-6-timer-design-changes-c179d46cefc#.as4uter1t
13:35:22 <dperpeet> harish__, let's tackle that tomorrow or on Wednesday then, if you have time
13:35:33 <harish__> yea sure
13:35:57 <andreasn_> all right, anything more on timers?
13:36:06 <harish__> https://github.com/cockpit-project/cockpit/issues/1964 dperpeet
13:36:22 <harish__> i hope the update fixes this too
13:36:43 <dperpeet> good point, I will try that again when we look at the update
13:37:05 <harish__> ok thanks. eot
13:37:12 <andreasn_> #topic open floor
13:38:20 <andreasn_> so, to return to the MTU issue, I took another look at it
13:38:22 <mvollmer> the atomic storage stuff is moving forward
13:39:01 <andreasn_> http://pasteboard.co/acyNtRGCW.png
13:39:14 <andreasn_> mvollmer: or am I looking at an outdated version of the PR?
13:39:35 <mvollmer> andreasn_, that's the current state
13:40:46 <andreasn_> my biggest issue with this state is it's a two-state thing (automatic/custom), but the only way to switch between them is to clear the field, so it's almost a one-state
13:41:20 <mvollmer> yeah, I am making it a radio button
13:41:45 <andreasn_> cool. Then I'm good with it
13:41:56 <andreasn_> thanks!
13:42:51 <andreasn_> let me know when you want me to take another look
13:42:55 <mvollmer> andreasn_, can we have a input box in the middle of a sentence?
13:43:08 <mvollmer> with l10n etc?
13:43:22 <mvollmer> impossible is nothing, of course
13:43:25 <dperpeet> mvollmer, not good design I think
13:43:39 <andreasn_> that's true, it will get messed up in some languages
13:43:59 <andreasn_> I was thinking it might be ok since the thing after it is just a unit of measure
13:44:05 <andreasn_> but maybe it's not
13:44:54 <andreasn_> and if we're running with the idea that it's not a unit, but rather "I want to set MTU to 1500"
13:45:06 <andreasn_> we can skip the "Bytes" part
13:45:10 <andreasn_> I'll update the mockup
13:47:45 <andreasn_> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/network/mtu-size-dialog-v3.png
13:48:27 <mvollmer> andreasn_, I left out the "MTU" label, even
13:48:43 <andreasn_> where?
13:48:49 <dperpeet> should we scope this outside of the meeting?
13:48:53 <andreasn_> yeah
13:49:07 <andreasn_> all right, I think that was all
13:49:26 <github> [cockpit] mvollmer opened pull request #4711: networking: Use radio buttons for MTU dialog (master...network-better-mtu) https://git.io/vKZhB
13:49:37 <mvollmer> roger
13:49:38 <andreasn_> thanks everyone!
13:49:42 <andreasn_> #endmeeting