13:05:42 <mvollmer> #startmeeting meeting
13:05:42 <zodbot> Meeting started Mon Jun 13 13:05:42 2016 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:05:42 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:05:42 <zodbot> The meeting name has been set to 'meeting'
13:05:51 <mvollmer> .hello mvo
13:05:52 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
13:05:57 <mvollmer> #topic Agenda
13:06:06 <mvollmer> * master build failure checks
13:06:25 <mvollmer> * fedora-24 updates-testing?
13:06:25 <stefw> * broken 0.110 release
13:06:39 <harish__> * timer
13:06:40 <mvollmer> * network teaming
13:06:41 <stefw> * Are we ready to declare API stable?
13:06:48 <mvollmer> * fedora-24 Atomic Host
13:07:01 <dperpeet> .hello dperpeet
13:07:02 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
13:07:07 <stefw> .hello stefw
13:07:08 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
13:07:35 <mvollmer> * docker storage setup (if there is time)
13:08:08 <mvollmer> alright, shall we start?
13:08:31 <mvollmer> #topic master build failure check
13:08:55 <stefw> Is this the work that I did? or another topic?
13:08:56 <mvollmer> so we have decided to reserve some time each week to check the situation of the master tests
13:09:09 <mvollmer> stefw, I think it is something else
13:09:11 * stefw says aha
13:09:13 <dperpeet> we discussed this last week
13:09:16 <dperpeet> somewhat
13:09:22 <dperpeet> and decided that the current state isn't very great
13:09:35 <dperpeet> since it's easy to stop caring when everything is red anyway
13:10:07 <mvollmer> so, fedora-24:
13:10:24 <mvollmer> woah, that looked better last week.
13:10:35 <mvollmer> five failures.
13:10:50 <mvollmer> shall we assign an action point?
13:11:00 <mvollmer> https://fedorapeople.org/groups/cockpit/logs/master-891f6a8d-verify-fedora-24/log.html
13:11:11 <dperpeet> one important part of this: we said that we wouldn't look for longer than a specific length of time
13:11:32 <stefw> so said another way, is this about trying to solve known issues?
13:11:38 <dperpeet> we haven't updated the fedora-24 in two months
13:11:49 <dperpeet> the fedora-24 image
13:12:17 <dperpeet> we should see if there's an issue we need to get on top of / write a workaround after all
13:12:22 <mvollmer> stefw, yes, since all failures on master should be known issues
13:13:10 <mvollmer> so fedora-24 produces audit messages.
13:13:53 <mvollmer> https://github.com/cockpit-project/cockpit/issues/4270
13:14:30 <mvollmer> https://bugzilla.redhat.com/show_bug.cgi?id=1324456
13:14:38 <dperpeet> mvollmer, I don't think it's worth looking at master f24 failures right now
13:14:51 <dperpeet> like I said, the images are 2months old
13:15:02 <dperpeet> the newer images keep getting blocked and delayed
13:15:08 <mvollmer> well, so we expect the bug to be fixed?
13:15:29 <dperpeet> https://fedorapeople.org/groups/cockpit/logs/pull-4545-db7f26ea-verify-fedora-24/log.html
13:16:04 <dperpeet> it isn't
13:16:15 <dperpeet> (and I need to patch the naughty issue code again, apparently)
13:16:27 <mvollmer> okay, but it's only some selinux policy misconfig, right?
13:16:55 <dperpeet> needs a rebuild to test, probably
13:17:33 <mvollmer> so, moving on to rhel-7. :-)
13:17:46 <stefw> so in general should we be more active in adding known issues? getting new images?
13:17:49 <stefw> and then solving them?
13:18:10 <mvollmer> stefw, I don't think we know yet...
13:18:34 <mvollmer> right now I am thinking we should more actively report what happens to known issues that any of us follows
13:18:42 <dperpeet> I think we should discuss the generalities now, instead of looking at the individual images
13:19:03 <dperpeet> I think we aren't fully utilizing the fact that we keep re-checking
13:19:11 <mvollmer> so for rhel-7, storaged is too old.
13:20:04 <dperpeet> well, the fact that we haven't been able to update our f24 image in a long time should be a warning sign
13:20:29 <dperpeet> I would prefer more known issues
13:20:33 <dperpeet> as long as they are reported
13:20:43 <stefw> should we somehow bring them into the status display?
13:20:53 <dperpeet> I was thinking about that
13:20:58 <dperpeet> what would that gain us?
13:21:02 <dperpeet> it's really a case by case thing
13:21:10 <mvollmer> what about showing the age of known issues that happen on master?
13:21:29 <mvollmer> if a known issue is five months old, that's bad
13:21:39 <mvollmer> and we might need to do something
13:21:53 <dperpeet> I think just the number of known issue failures would be a good start
13:22:00 <stefw> yup. basically ever known issue is something that is broken for actual users
13:22:04 <mvollmer> so a better display of which known issues are still happening
13:22:19 <mvollmer> on master and elsehwere
13:22:50 <dperpeet> should we try linking reports and our testing again?
13:22:56 <dperpeet> with a lower update frequency
13:23:09 <dperpeet> with included backoff
13:23:12 <mvollmer> dperpeet, would you like to tink about that a bit?
13:23:20 <dperpeet> yeah, let me think about that for a bit offline
13:23:22 <mvollmer> meeting time is precious... :-)
13:23:28 <mvollmer> cool thanks.
13:23:36 <dperpeet> we can look at failures again next week, let's set a limit of <10 minutes
13:23:51 <mvollmer> that's very little, but we can't afford more
13:24:04 <mvollmer> well...
13:24:19 <mvollmer> #topic fedora-24 updates-testing
13:24:40 <mvollmer> i was thinking that fedora has updates-testing enabled until the release
13:25:08 <mvollmer> and in any case i thought it is helpful to test updates-testing now
13:25:14 <mvollmer> for fedora-24
13:25:29 <stefw> can we just leave the configuration for fedora-24 on the default?
13:25:35 <mvollmer> until we move on and fedora-testing is f24
13:25:42 <stefw> so when updates-testing is switched off upstream, our images automatically get that change?
13:26:05 <mvollmer> yes, we can do that
13:26:15 <stefw> with that tweak (ie: automatically going from updates-testing -> updates, when upstream does) i think this makes a lot of sense.
13:26:19 <stefw> ie: test what the users are actually using.
13:26:49 <mvollmer> yeah
13:26:54 <dperpeet> I like that
13:27:02 <mvollmer> so I guess I would argue for fedora 24 to actually change the default
13:27:13 <mvollmer> but I agree that we should just follow
13:27:21 <mvollmer> and I don't care _that_ much, of course
13:27:54 <mvollmer> I can do one-off testing for interesting packages in updates-testing
13:28:01 <mvollmer> such as atomic 1.10 now
13:29:01 <dperpeet> mvollmer, you'll update the pr?
13:29:28 <mvollmer> yes
13:29:47 <mvollmer> #topic  broken 0.110 release
13:30:24 <stefw> so the 0.110 release was broken
13:30:30 <stefw> and this is partially my fault
13:30:49 <stefw> previously I was running the koji/fedora-23 or koji/fedora-24 tests manually
13:30:51 <stefw> before tagging the release
13:30:54 <dperpeet> at least you weren't the one who tagged a broken release :)
13:31:18 <stefw> well since our goal is to automate this, we have to look for systemic failures that can be solved from now on.
13:31:32 <stefw> rather than one time fixes of the actual problem at hand.
13:32:16 <stefw> the actual problem was that a certain file was'n included in the tarball
13:32:26 <stefw> but there's two deeper issues
13:32:32 <stefw> it wasn't detected before the change was merged
13:32:48 <stefw> so I created this: https://github.com/cockpit-project/cockpit/pull/4563
13:32:57 <stefw> to better handle that case, and tested that it failed
13:33:05 <stefw> but the second deeper issue is one that i haven't solved
13:33:39 <stefw> and that is to somehow bring in the additional packaging tests such as koji/fedora-23 into the release process
13:33:40 <stefw> perhaps testing master with that?
13:34:15 <dperpeet> I think we should run the tests as part of the release process
13:34:25 <dperpeet> but running on master as a daily would be good
13:34:35 <dperpeet> otherwise we overload other systems
13:35:04 <stefw> so we would need to gate the tagging based on the tests on a given commit, not run the CI tests as part of the actual automated release process.
13:35:21 <dperpeet> yes, I have put some thoughts into a process like that
13:35:23 <stefw> so basically only tag when things are green enough
13:35:36 <stefw> ok good to know
13:35:45 <dperpeet> I don't think all of that logic belongs in cockpit
13:35:56 <stefw> right
13:36:16 <dperpeet> I can gather my thoughts somewhat and we can discuss this outside of the meeting
13:36:41 <dperpeet> we need different checks for different releases anyway
13:37:42 <stefw> ok
13:37:53 <stefw> i guess that's end of this topic then, until later
13:38:10 <mvollmer> oky
13:38:22 <mvollmer> #topic timer
13:38:30 <harish__> hi, as per mock up https://trello.com/c/1B2lZViZ/74-timers-and-cron ,
13:38:36 <harish__> I have finished till "repeat monthly" option on the playground.
13:38:43 <harish__> here
13:38:47 <harish__> https://github.com/harishanand95/cockpit/tree/timer
13:39:02 <harish__> Now the work left is on creating "repeat yearly" option
13:39:11 <harish__> which has bootstrap-datepicker
13:39:27 <harish__> and work left is on displaying "not loaded" timers in playground app
13:39:36 <harish__> After this I think the playground app should be ready and
13:39:45 <harish__> then we will have almost all the functions needed for adding it to services/timer.
13:39:47 <dperpeet> harish__, did you look into using the value of the dropdown so that adding different intervals becomes easier?
13:39:57 <dperpeet> e.g. use the number of hours
13:40:22 <harish__> yea. i have marked it for addition. i had a doubt
13:40:43 <harish__> if we are to use seconds as value,then
13:41:02 <harish__> for week it would result in big value right?
13:41:14 <dperpeet> harish__, not big for a machine
13:41:26 <harish__> what about repeat yearly case?
13:41:27 <dperpeet> when you look at unix timestamps, counting seconds worked for quite a while :)
13:42:16 <harish__> okay. but it makes sense to have them like that
13:43:05 <harish__> https://github.com/cockpit-project/cockpit/pull/4503 this pr on timer last run and next run time needs andreasn review.
13:43:46 <dperpeet> I'll do some more reviewing, andreas won't get to it before next week
13:44:00 <harish__> andreasn told me to add table header
13:44:27 <harish__> now header is available for all services tables
13:44:34 <dperpeet> great
13:44:37 <dperpeet> nice progress
13:45:08 <harish__> thanks dperpeet. i think of finishing playground this week possibly by Wednesday
13:45:19 <harish__> after that i will do the blog
13:45:22 <mvollmer> good stuff
13:45:24 <dperpeet> good
13:45:32 <dperpeet> thanks!
13:45:33 <harish__> thanks everyone :D
13:45:42 <mvollmer> next? :-)
13:45:45 <harish__> thats it from me
13:45:46 <dperpeet> yes
13:45:49 <mvollmer> #topic network teaming
13:45:53 <mvollmer> so I started
13:45:58 <mvollmer> goes as expected
13:46:31 <mvollmer> my current plan is to make a super simple ui
13:46:41 <mvollmer> only offer a choice of "runner"
13:46:51 <mvollmer> and then get feedback what else is important
13:47:09 <mvollmer> e.g., is there ever a need to use something else than "ethtool" for watching links?
13:47:18 <mvollmer> if so, can't teamd do that automatically?
13:47:31 <mvollmer> e.g., for non-ethernet links
13:48:14 <mvollmer> found one bug: if you give invalid JSON to networkmanager, it gets into a loop... :)
13:48:31 <dperpeet> :)
13:48:43 <mvollmer> so, business as usual there. eot.
13:48:59 <mvollmer> #topic Are we ready to declare API stable?
13:49:38 <stefw> right, so we did the module cleanup
13:49:39 <dperpeet> the big question there is what do declare stable
13:49:45 <stefw> in the base package ...
13:49:59 <dperpeet> https://trello.com/c/fhh4BHjL/301-0-110-stable-api-cleanup-base-package
13:50:02 <stefw> this is the javascript in the base package we're talking about
13:51:29 <stefw> are there any major objections to declaring the base package API stable?
13:51:45 <dperpeet> we haven't cleaned up cockpit.js
13:51:48 <stefw> i do have some cleanup i'd like to do on how things are included in <script> tags, but I'm pretty certain that this won't break the API.
13:52:07 <stefw> dperpeet, what are you referring to in particular? anything worth calling out?
13:53:05 <dperpeet> nothing in particular - we should see if there is unused stuff, check comments, maybe restructure to see if everything needs to be exposed that is
13:53:23 <dperpeet> also I would like to wait and see if our new packaging will break anything
13:53:41 <dperpeet> I haven't seen any of that, so I have no idea
13:54:02 <stefw> hmmm, so we'll never have a perfect API
13:54:07 <stefw> but we have to have a stable API
13:54:22 <dperpeet> yeah, but the packaging change is a big one
13:54:28 <dperpeet> well, build system rather
13:54:28 <stefw> i'm fine with waiting a short while longer, but not for arbitrary requirements
13:54:40 <stefw> right, yes, worth having a few releases with the current stuff removed from the base package
13:54:43 <dperpeet> I don't say we should wait for all of that to land
13:54:50 <dperpeet> just to judge if it'll work at all
13:54:57 <stefw> should we have a "stable candidate"?
13:55:01 <stefw> larsu, what do you think?
13:55:03 <dperpeet> I like that
13:55:19 <dperpeet> also announce that
13:55:27 <dperpeet> to give extra feedback opportunities
13:55:44 <dperpeet> people are using the API for things (or want to use it) in ways we aren't aware of
13:56:48 <stefw> ok, i'll think about the <script> tag inclusion stuff, and then work on the candidate
13:57:29 <dperpeet> I'm fine with calling out a candidate next week for the release
13:59:08 <dperpeet> mvollmer, next topic?
13:59:09 <stefw> ok, sounds good
13:59:19 <mvollmer> yep
13:59:24 <mvollmer> #topic fedora-24 Atomic Host
13:59:38 <mvollmer> so i had planned to switch fedora-atomic to fedora 24
13:59:46 <mvollmer> but I got confused with cloud vs atomic...
13:59:56 <mvollmer> so there is no Fedora 24 Atomic Host
14:00:09 <mvollmer> they will start working on it once Fedora 24 is released
14:00:28 <mvollmer> and after that we might start seeing the docker storage setup UI in Cockpit
14:00:46 <mvollmer> eot
14:01:01 <mvollmer> one more?
14:01:08 <mvollmer> #topic docker storage setup
14:01:27 <mvollmer> so tests should pass on all our platforms
14:01:34 <mvollmer> but the feature is disabled on all platforms
14:01:46 <mvollmer> so we only test whether the run-time detection works
14:02:04 <mvollmer> but the tests have also been green already in fedora-24 plus updates-testing
14:02:22 <mvollmer> and I could give karma to atomic 1.10
14:03:00 <mvollmer> I also made this PR: https://github.com/projectatomic/atomic/pull/418
14:03:03 <mvollmer> let's see
14:03:38 <mvollmer> next sprint I might do some atomic d-bus work
14:04:12 <mvollmer> done
14:04:23 <mvollmer> #topic any other business
14:05:46 <mvollmer> none, I guess.
14:05:55 <mvollmer> thanks everyone!
14:05:59 <mvollmer> #endmeeting