14:03:53 <mvollmer> #startmeeting meeting
14:03:53 <zodbot> Meeting started Mon Jan 18 14:03:53 2016 UTC.  The chair is mvollmer. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:03:53 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:03:53 <zodbot> The meeting name has been set to 'meeting'
14:03:55 <jscotka> dperpeet, yep, But I'm calling there vm-prep, testsuite-prep, and then vm-create for RHEL7 machine
14:03:58 <andreasn> .hello andreasn
14:03:59 <zodbot> andreasn: andreasn 'Andreas Nilsson' <anilsson@redhat.com>
14:04:02 <dperpeet> .hello dperpeet
14:04:03 <mvollmer> .hello mvo
14:04:03 <zodbot> dperpeet: dperpeet 'None' <dperpeet@redhat.com>
14:04:04 <stefw> .hello stefw
14:04:07 <zodbot> mvollmer: mvo 'Marius Vollmer' <marius.vollmer@gmail.com>
14:04:09 <zodbot> stefw: stefw 'Stef Walter' <stefw@redhat.com>
14:04:23 <mvollmer> #topic Agenda
14:04:30 <stefw> * Next step with Debian
14:04:35 <stefw> * tuned
14:04:43 <mvollmer> * Weekly image refresh
14:04:56 <mvollmer> * Sosreport
14:05:05 <petervo> * Testing containers
14:05:44 <mvollmer> Ready?
14:05:55 <andreasn> yup
14:05:59 <mvollmer> #topic Next step with Debian
14:06:26 <stefw> so how do we take the next step of getting into Debian experimental?
14:06:31 <stefw> it seems like everything is in place
14:06:35 <stefw> including shipping of licenses
14:06:40 <stefw> and  rebuilding everything after a 'make clean'
14:06:41 <mvollmer> nice
14:07:02 <mvollmer> we need to poke mbiebl etc, I'd say
14:07:07 <dperpeet> I think our blocker is getting a maintainer
14:07:40 <stefw> so when we're at FOSDEM talking with everyone about Cockpit ... should we say we don't have a maintainerc?
14:07:40 <mvollmer> yep
14:07:46 <stefw> or should we try and get one before then?
14:07:53 <stefw> seems kind of lame that we don't
14:08:00 <dperpeet> well, getting one before then would be awesome
14:08:06 <mvollmer> is mbiebl at fosdem?
14:08:13 <stefw> no idea
14:08:16 <dperpeet> but if we can't, then FOSDEM is a good place to look for one
14:08:32 <stefw> so we just sort of "let it happen" i guess?
14:08:46 <mvollmer> i guess
14:08:48 <stefw> mvollmer, what if we include the command to run on debian on cockpit-project.org/running.html?
14:08:52 <stefw> is it a handful of commands?
14:08:54 <dperpeet> we can send an e-mail to our list
14:09:02 <mvollmer> stefw, good idea
14:09:11 <dperpeet> and add a call for maintainer to our landing page
14:09:13 <mvollmer> it should be something like four/five commands
14:09:28 <stefw> ok, lets do that
14:09:36 <mvollmer> yep
14:09:53 <stefw> and should we remove big icons on running.html for any operating systems that are not being tested?
14:09:58 <dperpeet> the ubuntu ppa hasn't been updated either
14:09:59 <mvollmer> #action mvo Add commands to build from source for Debian to running.html
14:10:04 <dperpeet> so I think we can ask for that, too
14:10:19 <dperpeet> stefw, I thought we wanted to rework that page: split it into sections
14:10:24 <stefw> andreasn, would you be able to redesign running.html?
14:10:30 <dperpeet> basically "hide" everything that's not being actively tested
14:10:30 <andreasn> stefw: yep
14:10:37 <stefw> so that we have the operating systems we test listed ... and then a bullet list with links to "also"
14:10:37 <stefw> ?
14:10:41 <andreasn> stefw: and I think it makes sense to only do the tested ones
14:10:49 <andreasn> stefw: is there a list of those somewhere?
14:10:51 <stefw> well it would be nice to have arch there
14:10:57 <stefw> i would suggest turning the current list into "also"
14:11:58 <dperpeet> I think the layout shouldn't suggest a valuation of distros
14:12:09 <dperpeet> just actively tested vs not
14:12:12 <stefw> right
14:12:16 <stefw> each could be alphabetical
14:12:22 <dperpeet> yeah
14:12:22 <andreasn> it's like first tier and second tier
14:12:34 <stefw> yes, and the second ones should probably just be a list
14:12:38 <stefw> similar to the list of browsers
14:12:40 <stefw> maybe without icons?
14:12:46 <dperpeet> and a link to the wiki for contributing and bumping a distro to the first tier or even adding one
14:13:06 <dperpeet> or didn't we agree on a wiki page that people could add links to?
14:13:13 <dperpeet> e.g. the ppa
14:13:20 <dperpeet> it was built, but isn't maintained
14:13:48 <andreasn> so that's like a 3rd tier?
14:13:54 <stefw> submitting pull requests isn't hard
14:14:14 <dperpeet> stefw, right - we could link to the source then
14:14:22 <stefw> yup
14:14:31 <dperpeet> andreasn, I think that's the second tier
14:14:44 <dperpeet> 1st: actively tested, 2nd: the rest
14:14:50 <andreasn> sure
14:15:31 <andreasn> so I'll take an action to create a quick sketch and then we can bounce it a bit between us, and then I'll put together the html
14:15:42 <dperpeet> sounds good
14:15:53 <andreasn> #action andreasn to redesign the Running page on cockpit-project.org
14:16:11 <andreasn> did that work? or can only the chair do actions?
14:16:27 <mvollmer> i don't know
14:16:32 <mvollmer> #action andreasn to redesign the Running page on cockpit-project.org
14:16:45 <stefw> dun dun dun ...
14:17:14 <mvollmer> okay, next?
14:17:30 <andreasn> sure
14:17:30 <mvollmer> #topic tuned
14:18:15 <stefw> we talked about including this at our devconf talk
14:18:20 <stefw> so it would need to be done by then
14:18:23 <stefw> any takers, plans?
14:18:39 <andreasn> the designs are pretty ready I think
14:18:50 <stefw> yup those are ready
14:18:58 <mvollmer> I _think_ I am pretty much done with sosreport
14:19:09 <andreasn> and the underlying support for the stuff we want is also in, right?
14:19:31 <stefw> pretty much
14:19:38 <stefw> and we should behave gracefully in its absence
14:19:45 <stefw> there is one more thing that needs to change in tuned
14:19:45 <andreasn> right
14:19:47 <stefw> it should use polkit
14:20:09 <stefw> but we can use the 'super: true' option in its absence
14:21:10 <mvollmer> yep
14:21:36 <mvollmer> okay, what's the dead-line? end of this week? :)
14:22:08 <stefw> yeah, i think so
14:22:31 <mvollmer> what level do we need?  fully automated tests?
14:22:50 <stefw> i think a basic test shouldn't be too hard no?
14:22:59 <mvollmer> probably not
14:23:08 * mvollmer hasn't looked at the design, tbh
14:23:18 <stefw> it's basically a dialog
14:23:21 <stefw> similar to realm join
14:23:24 <stefw> but simpler is complexity
14:23:33 * mvollmer nods
14:24:06 <andreasn> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/performance-profiles/performance-profiles.png
14:24:11 <mvollmer> thanks
14:24:22 <andreasn> https://raw.githubusercontent.com/cockpit-project/cockpit-design/master/performance-profiles/performance-profiles-dialog.png
14:24:42 <mvollmer> haha, hipster lorem!
14:25:00 <stefw> woah those are gold
14:25:08 <andreasn> hehe, yeah, I tend to go for that
14:25:30 <andreasn> #info http://hipsum.co/
14:25:33 <mvollmer> haha, I am on the floor here
14:25:45 <dperpeet> :)
14:25:47 <andreasn> "knausgaard"
14:25:54 <andreasn> I didn't read them before really
14:26:10 <dperpeet> we should use that for our tests
14:26:23 <dperpeet> nicer than "foobar"
14:26:40 <stefw> "Artisanal filler text for your site or project."
14:26:41 <mvollmer> order, order
14:27:10 <mvollmer> so I'll try to juggle the sosreport and tuned deadlines?
14:27:15 <mvollmer> any other taker?
14:27:24 <dperpeet> sosreport needs to be done first, I think
14:27:34 <dperpeet> since it's almost ready
14:27:43 <stefw> yup
14:27:45 <dperpeet> I can help with testing that, mvollmer
14:27:47 <dperpeet> let me know
14:27:58 <mvollmer> okay
14:28:09 <mvollmer> dperpeet, yes, please.
14:29:17 <mvollmer> #action mvo 'finish' tuned
14:29:58 <mvollmer> next?
14:30:28 <mvollmer> #topic Weekly image refresh
14:30:49 <mvollmer> I have two PRs for that, and a third one coming
14:31:07 <mvollmer> #3470 and #3474
14:31:19 <stefw> so can you describe how this actually works?
14:31:25 <mvollmer> yep
14:31:30 <stefw> is it a good architecture? or an abuse of what we have?
14:31:34 <stefw> in your opinion?
14:31:47 <mvollmer> the first PR makes it so that github-task understands "image/..." contexts
14:32:10 <mvollmer> as soon as a PR has one of these, it wont get verify contexts automatically
14:32:26 <mvollmer> and running a image context executes vm-create -v --upload
14:32:48 <stefw> so how does the new hash get into the PR?
14:32:56 <mvollmer> the second PR adds a github-image-refresh command that can create image refresh PRs
14:33:07 <mvollmer> and can scan github to figure out which ones need creating
14:33:20 <stefw> i may be misunderstanding .. but it seems backward to create a PR that doesn't have any changes?
14:33:28 <mvollmer> the third PR will commit the new hash
14:34:13 <mvollmer> stefw, I'll 'use' the PR to coordinate things, and to publish links to the creation logs
14:34:14 <stefw> there are 3 PRs for each image refresh?
14:34:24 <mvollmer> no, sorry, that was confusing
14:34:38 <mvollmer> the feature implementation is split over three PRs.
14:34:48 <mvollmer> refreshing a image uses one PR only
14:34:54 <mvollmer> one per image
14:35:35 <dperpeet> so I create an image/... pr? or do we script that?
14:35:44 <mvollmer> dperpeet, we script that
14:35:47 <dperpeet> and then another pr gets added with a new image?
14:36:04 <mvollmer> no, the image/...PR gets updated when the image is done
14:36:11 <dperpeet> ah ok
14:36:18 <stefw> so we do lose the logs ... mostly
14:36:24 <stefw> i mean they're not in the github UI at least
14:36:32 <mvollmer> my plan was to copy them to the commit that adds the hash link
14:37:04 <dperpeet> but as a status, correct?
14:37:08 <mvollmer> yes
14:37:13 <mvollmer> copy the status
14:37:19 <dperpeet> so we have e.g. "image/fedora-23" success
14:37:27 <dperpeet> with a link to the logs
14:38:12 <mvollmer> yes, on a commit that changes the image hash link.
14:38:17 <dperpeet> is the creation of images that can't be built everywhere covered?
14:38:19 <dperpeet> e.g. rhel
14:38:21 <mvollmer> and that commit then gets verified
14:38:31 <mvollmer> dperpeet, no, that is open
14:38:59 <dperpeet> we have the things in place to narrow down verification
14:40:21 <mvollmer> yeah
14:40:22 <stefw> i'm a bit concerned about using PRs for things that have no changes
14:40:56 <mvollmer> so we wait with creating the PR until the image is done?
14:41:31 <dperpeet> stefw, I don't think the PR is a bad idea
14:41:36 <mvollmer> stefw, what is your concern?
14:41:44 <dperpeet> we decided to sync our machines via github
14:41:54 <stefw> PR is not the only github api
14:41:58 <dperpeet> true
14:42:03 <dperpeet> but it's nicely contained :)
14:42:38 <dperpeet> do you have a good alternative?
14:42:45 <dperpeet> a PR let's us keep track of the process
14:42:50 <dperpeet> and view the logs the way we're used to
14:43:00 <stefw> well no, we're copying the logs around manually
14:43:12 <petervo> a status on a master hash we are basing the new image on?
14:43:13 <stefw> that could easily go in a text message or anything
14:43:15 <stefw> so that's not a benefit
14:43:33 <dperpeet> petervo, I would hesitate to use the master status
14:43:37 <dperpeet> we could use a gist
14:43:38 <stefw> my first reaction would have been that issues are a good fit for requesting a new image be created
14:43:51 <stefw> and the pull request contains the result of that, ready to be verified, and then merged.
14:43:55 <dperpeet> true
14:44:06 <mvollmer> we can even turn a issue into a pull request
14:44:06 <dperpeet> and it can include a Fixes #issue et cetera
14:44:10 <mvollmer> via the API
14:44:10 <stefw> we can have a 'bot' label
14:44:22 <stefw> and anything that has a 'bot' label ... gets retrieved by the github-task code
14:44:28 <stefw> and considered as a task
14:44:40 <stefw> any issues
14:44:43 <stefw> that have that label ...
14:44:55 <stefw> these are issues that the bots should try and solve
14:45:10 <stefw> they can post their logs about solving them in comments
14:45:13 <stefw> and create PRs with the results
14:45:18 <stefw> for verification, review, etc.
14:45:36 <stefw> the 'bot' label is merely an optimization ... of course ... since retrieving all open issues is a big deal
14:45:50 <dperpeet> issues don't have a status, as far as I can see
14:45:52 <dperpeet> but we can add comments
14:45:59 <stefw> pull requests don't have status either
14:46:01 <stefw> commits have status
14:46:05 <stefw> the fact that a pull request shows  status
14:46:06 <dperpeet> true
14:46:11 <stefw> is because it's HEAD commit has status
14:46:14 <stefw> but the status is moot
14:46:23 <stefw> since we're not doing an image generation based off of a change
14:46:38 <stefw> and in a PR that status would be lost anyway when the HEAD commit changes to include the hash of the new image.
14:46:38 <dperpeet> do we create an issue per image
14:46:42 <dperpeet> or one to contain all of them?
14:46:47 <stefw> mvollmer, ^^
14:46:53 <stefw> do we create a PR per image ... or all of them
14:46:54 <mvollmer> one per image, I'd say
14:46:59 <stefw> i'm fine either way
14:47:10 <mvollmer> okay, sounds good
14:47:12 <dperpeet> one per image makes for nicer merging, I think
14:47:13 <stefw> so then likely it would be an issue per image too
14:47:18 <dperpeet> eah
14:47:20 <dperpeet> yeah
14:47:47 <dperpeet> this will lead to unnecessary testing
14:47:56 <dperpeet> since each pr is tested for all configurations
14:48:15 <dperpeet> we could say one pr to merge all
14:48:16 <stefw> true, but we can deal with that later
14:48:26 <stefw> we can easily make skip statuses
14:48:26 <dperpeet> sure, one each for now is easiest I htink
14:48:32 <stefw> that go green and say "Skip"
14:48:42 <dperpeet> that's a nice approach
14:49:24 <mvollmer> #action mvo to make it so
14:50:22 <mvollmer> next?
14:50:47 <stefw> yup, thanks for working on the image creation, by the way
14:51:01 <mvollmer> sure, that's long overdue
14:51:21 <petervo> testing containers... so i've been working on this going to open the pr soon
14:51:40 <mvollmer> just fyi, if you want to play with this: git push https://oauth-token@github.com/... works
14:51:58 <stefw> cool
14:52:21 <mvollmer> there is also a github content api, which is cool, but it might not be able to make symlinks
14:52:39 <mvollmer> haven't tried yet
14:53:06 <mvollmer> #topic sosreport
14:53:49 <mvollmer> i got this running also when sosreport is in a container: https://github.com/cockpit-project/cockpit/pull/3486
14:54:06 <mvollmer> some details, of course, but in the end straight forward
14:54:23 <mvollmer> some bugs as well, which I will file
14:54:25 <mvollmer> or one bug
14:54:52 <dperpeet> mvollmer, for the last topic: https://developer.github.com/v3/repos/contents/#custom-media-types regarding symlinks
14:55:01 <mvollmer> "atomic run" reuses the tools container, which somehow makes things fail on the second run
14:56:23 <mvollmer> biggest open question is: how do we decide when to use "atomic run", and with which image?
14:56:38 <stefw> so obviously we use sosreport when it's present, right?
14:56:41 <mvollmer> we can't settle this at build-time
14:56:41 <stefw> directly
14:56:55 <mvollmer> yes, we should
14:57:08 <stefw> and when it's not present, we use a container
14:57:22 <stefw> in the real world sosreport is mainly used by rhel and red hat support right?
14:57:30 <mvollmer> i can't say
14:57:30 <stefw> so shouldn't we default to the rhel container?
14:58:07 <stefw> can we start with that assumption?
14:58:16 <mvollmer> i have asked whether we can have "atomic tools-run", which provide the image name itself
14:58:20 <stefw> that if sosreport executable is not available, try to use the rhel container?
14:58:20 <andreasn> sgallagh: do you know if sosreport is used by fedora as well?
14:59:32 <mvollmer> stefw, yeah, if sosreport is there, run it directly.  else if atomic is there, run the rhel7 tools container.  else print error message.
14:59:45 <mvollmer> we can catch that error message and turn it into a nicer one in the UI.
14:59:55 <stefw> cool
14:59:59 <sgallagh> andreasn: I don't think we have infrastructure for it, but I don't know if people ever use it to manually create bundles of data for bugfixing.
15:00:24 <andreasn> sgallagh: ah, ok. Thanks!
15:00:34 <mvollmer> #action mvo tweak run-sosreport.sh as above
15:01:17 <mvollmer> with that, and when cancel still works with containers, we should be good
15:01:58 <mvollmer> okay!
15:02:16 <mvollmer> #topic Testing containers
15:02:43 <petervo> ok, sry i jumped the gun before :D
15:03:13 <petervo> i've been working on this now that we have more than just the cockpit/ws container to test
15:03:20 <petervo> My thinking was that we don't need to run these container tests on every OS.
15:03:41 <petervo> So what i've got is we have a new OS type 'containers' based on f23 that builds these containers on testsuite-prepare based on the rpms mock creates in the vm
15:03:50 <petervo> The rpms are never installed.
15:04:06 <petervo> Then we use a different nameing scheme for the test files so that they aren't picked up by ./check-verify runs on other OS's but only by container runs
15:04:11 <mvollmer> (upps, I totally missed it when you mentioned it earlier.)
15:04:58 <stefw> i agree ... just running them with one os makes sense
15:05:05 <stefw> and makes sense that they're not verify/
15:05:07 <petervo> anyone have any objections to any of that?
15:05:08 <stefw> and don't fit under check-verify
15:05:50 <stefw> not me, sounds good, verify different kind of tests
15:06:00 <stefw> we just need to get that first commit that moves the publish stuff to github-task
15:06:05 <mvollmer> yep
15:06:07 <stefw> and that's really the branching point for theshe different kinds of tests
15:06:13 <stefw> mvollmer, if you put that in a separate pull request
15:06:16 <stefw> i can review and merge
15:06:22 <stefw> because i think we've both had a pass at it right?
15:06:24 <mvollmer> okay
15:06:35 <mvollmer> #action mvo make PR for github-task refactor
15:06:52 <mvollmer> I used your commit and put some typo fixes on top
15:07:05 <mvollmer> but it's still broken, true
15:07:16 <mvollmer> check-verify --rebase is used but fails.
15:07:30 <mvollmer> i didn't test with --rebase...
15:07:55 <mvollmer> stefw, you said the testers break because of this, but not permanently, right?
15:08:10 <stefw> they do ... we next time we push a commit
15:08:12 <mvollmer> they can heal themselves on the next round, I hope
15:08:13 <stefw> we need to add a fake --rebase
15:08:21 <stefw> they get stuck on that PR
15:08:22 <stefw> forever
15:08:30 <mvollmer> ouch, I didn't know that
15:08:30 <stefw> so lets add a fake --rebase before pushing that commit again
15:09:18 <mvollmer> okay
15:11:14 <mvollmer> done?
15:11:21 <stefw> yup
15:11:24 <petervo> think so
15:11:30 <mvollmer> okay, thanks everyone!
15:11:33 <dperpeet> thanks!
15:11:37 <mvollmer> #endmeeting