13:01:04 <andreasn1> #startmeeting Cockpit Weekly meeting 2016-07-18
13:01:04 <zodbot> Meeting started Mon Jul 18 13:01:04 2016 UTC.  The chair is andreasn1. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:01:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:01:04 <zodbot> The meeting name has been set to 'cockpit_weekly_meeting_2016-07-18'
13:01:09 <andreasn1> .hello andreasn
13:01:10 <zodbot> andreasn1: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
13:01:16 <dperpeet> .hello dperpeet
13:01:17 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
13:01:26 <harish_> .hello harishanand
13:01:29 <zodbot> harish_: harishanand 'Harish Anand' <harishanand95@gmail.com>
13:02:26 <andreasn1> #topic agenda
13:02:45 <andreasn1> * systemd timers
13:02:52 <dperpeet> * webpack
13:02:57 <dperpeet> * test optimizations
13:02:59 <harish_> * timers
13:03:05 <dperpeet> * subscriptions rewrite
13:03:18 <dperpeet> * stable api
13:04:03 <andreasn1> sounds good
13:04:17 <andreasn1> #topic systemd timers
13:04:37 <harish_> https://github.com/cockpit-project/cockpit/pull/4645
13:05:06 <harish_> I think now its design issues andreasn1 had mentioned are fixed.
13:05:26 <andreasn1> yeah, I haven't checked out the latest version, but it's starting to shape up really well
13:05:32 <harish_> Its major issue of datepicker-dropdown moving around a lot which clicked (after scrolling) is fixed.
13:05:42 <dperpeet> great!
13:05:48 <harish_> datepickerv1.6 still had same issues
13:06:01 <harish_> it closed all patterns.js error handle functions
13:06:16 <harish_> when datepicker was clicked.
13:06:36 <harish_> it closed all errors* i meant
13:06:39 <andreasn1> regarding your month question before, the date could be set to the 1st of every month by default
13:07:03 <andreasn1> and then it's possible to change it to the 5th, 12th or whatever by hand
13:07:16 <dperpeet> andreasn1, I think harish_ meant to issue a warning when setting to >28
13:07:23 <dperpeet> that it might not run every month
13:07:34 <andreasn1> oh, right
13:07:38 <harish_> andreasn1 it is set to 1st when a new row is added.
13:07:43 <andreasn1> ah, good
13:07:48 <andreasn1> hm, yeah, good question
13:07:54 <harish_> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/services/timers.png
13:07:55 <andreasn1> I was curious what systemd itself does there
13:08:25 <dperpeet> harish_, I think displaying a warning would be fancy, but nice
13:08:28 <andreasn1> right, I even had a note there "what do do with Feb 28 and 30/31"
13:08:31 <harish_> systemd suggested on setting end of month timers to next month starting to avoid such cases
13:08:44 <dperpeet> andreasn1, maybe blue info box?
13:08:45 <harish_> yes exactly
13:08:59 <dperpeet> harish_, very good to think of this!
13:09:06 <andreasn1> yeah, I think that could wok
13:09:09 <andreasn1> work
13:09:14 <dperpeet> this is one of the things that could annoy users
13:09:16 <dperpeet> if there is no warning
13:09:25 <dperpeet> make it accessible -> notify about the behavior
13:09:49 <dperpeet> can the day index be negative? =)
13:09:55 <dperpeet> -1: last day
13:09:58 <andreasn1> if you set it to 31, it might be that you want it to be triggered on the 31 only, but it's still good to notify those that thinks of 31 as "the end of every month"
13:10:33 <dperpeet> I'm for showing something - probably the blue info box
13:10:42 <dperpeet> warning seems out of place for something that could be intentional
13:10:46 <andreasn1> I agree with that behaviour
13:10:58 <dperpeet> harish_, what do you think?
13:11:01 <harish_> dperpeet we have it as dropdown. so it cant be negative :D
13:11:16 <dperpeet> harish_, dropdown is text, you can set anything :)
13:11:52 <harish_> yea. i have seen the blue boxes it will help. shouldn't it be shown only when a user selects 31st?
13:12:01 <dperpeet> I think the pattern is to always show them
13:12:06 <dperpeet> andreasn1 ?
13:13:05 <andreasn1> not super sure if to show by default or only if 31 is selected. I can't remember where we have this pattern elsewhere already
13:13:19 <harish_> dperpeet should I check if user input such invalid inputs from dropdowns? like negative?
13:13:30 <dperpeet> harish_, no
13:13:39 <dperpeet> I think we can move this detailed discussion to the pr
13:13:44 <harish_> okay
13:13:45 <andreasn1> yeah, lets do so
13:13:54 <harish_> I have started writing tests.
13:13:54 <andreasn1> ok, next up
13:13:57 <dperpeet> great!
13:14:07 <harish_> thanks dperpeet andreasn1
13:14:11 <andreasn1> thank you!
13:14:11 <harish_> eot
13:14:13 <dperpeet> let me know when they are in the pr
13:14:17 <dperpeet> I will take a look and trigger them
13:14:17 <andreasn1> #topic webpack
13:14:26 <harish_> sure!
13:14:27 <dperpeet> we've changed the build system
13:14:48 <dperpeet> so most devs will need to call autoconf again
13:15:06 <dperpeet> this is part of being more modular and allowing out of tree modules
13:15:27 <dperpeet> larsu and stefw put in a lot of work to make this happen
13:15:37 <dperpeet> and we have more related pull requests up
13:15:56 <dperpeet> such as https://github.com/cockpit-project/cockpit/pull/4752 (which will allow us to use ES6)
13:16:12 <dperpeet> this way the individual modules can be more independent
13:16:21 <dperpeet> eot
13:16:28 <andreasn1> nice!
13:16:39 <andreasn1> #topic test optimizations
13:17:04 <dperpeet> I added some code so our test logs contain timing info
13:17:08 <dperpeet> so we can identify hotspots
13:17:38 <dperpeet> and there is an open pr to optimize our tests to simultaneously boot multiple machines
13:17:39 <dperpeet> https://github.com/cockpit-project/cockpit/pull/4741
13:17:54 <dperpeet> some tests need more than one, and before we would start wait, wait for it to boot, then start the next...
13:18:30 <dperpeet> I think this will not just make tests run faster, but also make adding more machines easier
13:18:45 <andreasn1> nice
13:18:46 <dperpeet> you can now just declare them as a class variable in the test, and the framework will take care of provisioning them
13:18:54 <dperpeet> once the test starts, you can ssh into it
13:19:03 <dperpeet> eot
13:19:46 <andreasn1> #topic subscriptions rewrite
13:20:39 <dperpeet> so after we did some work on subscriptions last week
13:21:03 <dperpeet> a refactoring was in order to separate backend logic from the view
13:21:23 <dperpeet> in order to reuse our patterns, it made sense to rewrite it with react
13:21:25 <dperpeet> https://github.com/cockpit-project/cockpit/pull/4715
13:21:50 <dperpeet> this is a work in progress
13:22:02 <dperpeet> andreasn1, would it be ok to get the proxy stuff in as it is?
13:22:11 <dperpeet> or would you rather not include it in the rewrite
13:22:35 <andreasn1> I think it would.
13:22:44 <andreasn1> would be OK to put it in
13:23:03 <dperpeet> ok, then I'll address the other issues
13:23:14 <andreasn1> the only usecase that gets tricky is if you change your proxy, and then you have to resubscribe everything
13:23:20 <dperpeet> I agree that it makes sense to put it in
13:23:37 <andreasn1> but I feel I don't know enough about the exact workings and workflows of subscription-manager to tell
13:24:00 <dperpeet> I would prefer to get it in and then iterate on the how
13:24:06 <andreasn1> sounds good
13:24:08 <dperpeet> so we can actually support that feature
13:24:36 <andreasn1> I have the mockup on a reworked layout, but I think that's better to discuss after the meeting
13:25:02 <andreasn1> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/subscriptions/subscriptions-keys-v2.png
13:25:23 <dperpeet> ok
13:25:29 <dperpeet> I will rework the pr
13:25:34 <dperpeet> thanks for your feedback!
13:25:36 <dperpeet> eot
13:25:48 <andreasn1> #topic stable api
13:26:28 <dperpeet> we set the stable version of cockpit-bridge and cockpit-shell in https://github.com/cockpit-project/cockpit/commit/2ab6a1716eca40c1a1c16aa1ac5457959b54fb82
13:26:44 <dperpeet> this should make it easier to develop other modules
13:26:56 <dperpeet> and means that the core doesn't have to be upgraded in sync with other packages
13:27:07 <dperpeet> so YAY for reaching this goal
13:27:40 <dperpeet> eot
13:27:43 <andreasn1> nice!
13:27:52 <andreasn1> *champagne*
13:27:54 <dperpeet> :)
13:28:24 <andreasn1> 🍾
13:28:47 <andreasn1> the above emoji is a square for me, probably same for the rest of you
13:28:54 <andreasn1> http://emojipedia.org/bottle-with-popping-cork/
13:29:04 <dperpeet> yeah, some unicode
13:29:18 <andreasn1> 🎉
13:29:29 <andreasn1> 🍸
13:29:42 <andreasn1> 🎆
13:29:46 <andreasn1> all right
13:29:50 <andreasn1> #topic Open Floor
13:30:51 <harish_> dperpeet can we know which process is using up more ram space inside cockpit?
13:31:33 <dperpeet> you mean something like "top"?
13:31:37 <dperpeet> for ram
13:31:52 <dperpeet> or pieces of cockpit that run in the browser?
13:32:19 <harish_> top memory usage.. which process with id so that i can kill it ?
13:32:58 <dperpeet> I don't think we have that in cockpit
13:33:08 <petervo_> it was suggested a while back
13:33:15 <petervo_> but hasn't been implemented
13:33:23 <harish_> ohh.. we could know only services, running etc
13:34:18 <harish_> but nothing about which current process in memory now
13:34:38 <harish_> oh okay..  i was just curious. thanks petervo_
13:35:11 <andreasn1> anything else for the open floor?
13:35:54 <andreasn1> sounds like a close
13:35:56 <andreasn1> #endmeeting