14:01:12 <tflink> #startmeeting
14:01:12 <zodbot> Meeting started Mon May 11 14:01:12 2015 UTC.  The chair is tflink. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:01:12 <tflink> #meetingname fedora-qadevel
14:01:12 <tflink> #topic role call
14:01:12 <zodbot> The meeting name has been set to 'fedora-qadevel'
14:01:24 <tflink> #chair kparal mkrizek
14:01:24 <zodbot> Current chairs: kparal mkrizek tflink
14:01:33 * mkrizek is here
14:01:36 * kparal is here
14:01:50 <tflink> hrm, no jskladan?
14:02:19 * tflink doesn't see any of his nicks online
14:02:43 <kparal> I pinged him on social networks
14:02:52 <kparal> but he doesn't seem to be online
14:03:22 <tflink> ok, we'll get started and maybe he'll join later on
14:03:30 <tflink> who wants to go first with status updates?
14:03:45 * tflink can
14:03:50 <tflink> #topic tflink status report
14:03:58 <tflink> #info got rid of lockbox-comm01.qa, migrated the last systems over to infra's ansible repo
14:03:59 <tflink> #info set up machines for the eventual beaker-stg to enable possible work during freeze
14:03:59 <tflink> #info rebuilt qadevel and qadevel.stg in infra, tested proxy routes to make sure they still work
14:03:59 <tflink> #info built new libtaskotron, resultsdb packages and deployed bits for depcheck workaround to dev/stg/prod
14:03:59 <tflink> #info discussed pending patch to add beaker roles to infra ansible (required for beaker-stg work)
14:04:31 <mkrizek> what do we run on qadevel?
14:04:33 <tflink> oh, forgot one
14:04:46 <tflink> #info ansible-ized the virthosts used for beaker's VM clients
14:04:53 <tflink> mkrizek: nothing at the moment
14:05:12 <kparal> I used lockbox-comm01.qa few days ago, but I forget what I needed it to log in to
14:05:14 <tflink> I got started with putting phabricator on it but never finished that task
14:05:25 <mkrizek> should we re-deploy the CI we were running there?
14:05:28 <kparal> mkrizek: do you remember where I needed to log in to?
14:05:42 <mkrizek> kparal: the phabricator machine
14:05:44 <tflink> that would probably make sense
14:05:58 <kparal> ah, right. so how do you currently log in to Phab machine?
14:06:16 <tflink> ssh key
14:06:35 <tflink> I keep forgetting that I might be the only one with ssh access to it, though - and that's not a good thing
14:06:52 <mkrizek> ok, I am putting it the CI on my todo list
14:07:03 * tflink puts deploying buildbot on qadevel on his todo list for the day
14:07:10 <tflink> it's going to have problems with the ssl certs, though
14:07:11 <kparal> that's probably why I tried to go through qa lockbox. but I've asked martin to do it anyway in the end
14:07:29 <tflink> yeah, cloud is separate from everything else - it doesn't need lockbox
14:08:13 <tflink> bah, I had forgotten about the SSL issue :(
14:09:29 <tflink> any other comments/questions?
14:09:36 <mkrizek> nope
14:09:58 <tflink> who's next?
14:10:02 <mkrizek> I'll go
14:10:08 <mkrizek> #topic mkrizek status report
14:10:12 <mkrizek> #info started to address concerns mentioned in the review of remote execution
14:10:15 <kparal> I had the topic half way written already :)
14:10:17 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/D356
14:10:24 <mkrizek> #info started to put pieces together for taskotron to start emitting fedmsgs, in progress
14:10:28 <mkrizek> #link https://phab.qadevel.cloud.fedoraproject.org/T387
14:10:36 <mkrizek> #info might need start a conversation on what fedmsgs (per-update/per-build) we want to start with
14:11:02 <tflink> i thought that we had that figured out already but it sounds like not so much?
14:11:11 <kparal> some of that we already discussed with martin, but it's probably a good idea to put it into text into a ticket or a mailing list
14:11:27 <mkrizek> yeah but neither me or kparal remembers the outcome of discussion :)
14:12:03 <tflink> IIRC, it was per-build fedmsgs because that allows for better filtering in fmn
14:12:20 <tflink> and bodhi2 can figure stuff out from per-build fedmsgs
14:12:39 <tflink> since we won't have to make comments in bodhi once that upgrade happens
14:13:32 <mkrizek> didn't we discuss something about putting all packages affected by depcheck into the fedmsg?
14:13:49 <mkrizek> would that imply using per-update?
14:14:25 <mkrizek> er, scratch the last question
14:14:54 <tflink> yeah, that's right
14:15:07 <mkrizek> ok
14:15:28 <tflink> looking back through qa-devel@, it looks like we decided on a fedmsg with all the affected builds listed inside it
14:15:42 <mkrizek> yep
14:16:08 * tflink wonders if we'd be better off emitting per-build messages with url to log file, though
14:16:49 <mkrizek> I think that the list with packages can be used by consumers
14:17:18 <tflink> yeah, we'll have to look into what fmn can do with the fedmsgs before sending notifications to users
14:17:25 <kparal> our major question when talking about this was whether we're targetting other systems as consumers, or package maintainers through fmn
14:17:52 <tflink> both, I think
14:17:57 <kparal> because there are quite a few concerns regarding package maintainers directly consuming this. no rate limiting, etc
14:18:17 <tflink> bodhi2 will understand results as incoming fedmsgs and fmn will notify packagers of any failures
14:18:35 <kparal> well, I don't think it's going to scale
14:18:45 <tflink> yeah, you have a point
14:18:50 <kparal> but I think it's best to have this as a separate discussion
14:19:05 <mkrizek> yeah let's continue on ml
14:19:14 <tflink> currently, we kind of hide the fact that depcheck and upgradepath are run many times by only notifying users once or on state change
14:19:15 <tflink> agreed
14:19:27 <kparal> tflink: right
14:19:35 <tflink> who wants the #action to start a thread?
14:19:45 * mkrizek volunteers
14:20:09 <kparal> mkrizek: I'll help you to list all the concerns we've discovered
14:20:30 <tflink> #action mkrizek to start thread on qa-devel@ about what kind of fedmsgs we'll be emitting and when so that we interoperate with bodhi and don't overwhelm users etc.
14:20:54 <mkrizek> cool, I don't have anything else
14:21:03 * tflink wonders if we could put some logic in resultsdb-backend to effectively rate-limit the fedmsgs but that can be saved for the list discussion
14:21:14 <tflink> kparal: i think you're up
14:21:18 <mkrizek> yeah we could
14:21:39 <kparal> #info better explain certain upgradepath and depcheck failures
14:21:39 <kparal> #link https://phab.qadevel.cloud.fedoraproject.org/D365
14:21:39 <kparal> #link https://phab.qadevel.cloud.fedoraproject.org/D368
14:21:53 <kparal> #info heavily reworked Phabricator documentation. If you read through it, it will save you some Herald rules when watching for ticket changes. You'll also be able to subscribe to Phab tickets without a project set (common for bug reports).
14:21:54 <kparal> #link https://fedoraproject.org/wiki/QA/Phabricator
14:22:42 <kparal> I realized I was missing some bug reports where reporters haven't filled in a project, this should fix it
14:22:53 * tflink just noticed that ticket till filed 2 months ago :-/
14:23:27 <kparal> tflink: well I've found out just because you replied to one of that tickets and assigned it a project
14:23:45 <kparal> otherwise I wouldn't have a clue that there are some tickets like that
14:23:59 <kparal> *have had
14:23:59 <tflink> https://phab.qadevel.cloud.fedoraproject.org/T437 is the ticket I was talking about, for reference
14:24:31 <kparal> that's it from me
14:25:19 <tflink> thanks for getting the docs updated
14:25:27 <tflink> any other questions/comments?
14:25:52 <kparal> not here
14:26:07 <mkrizek> none
14:26:11 <tflink> ok, moving on - couple of discussion topics this week
14:26:24 <tflink> #topic to RHEL or not to RHEL
14:26:48 <tflink> #link https://lists.fedoraproject.org/pipermail/qa-devel/2015-May/001216.html
14:27:05 * kparal catching up with that email
14:27:08 * mkrizek is on the fence here
14:27:32 <tflink> I just started that thread over the weekend so I'm not sure that's enough time for everyone to understand the issue well enough for discussion here
14:28:52 <tflink> I think that it's going to mostly come down to the answer to one question: how valuable would the testing we do be and is it worth the amount of time that we'd be spending on it
14:29:24 <mkrizek> the testing?
14:29:37 <kparal> this is just about the virthosts, right?
14:29:42 <tflink> by using fedora in production, we'd be doing some testing, yes
14:29:58 <mkrizek> ok, just wasn't sure what you mean exactly
14:30:05 <tflink> everything - taskotron master, resultsdb etc.
14:30:12 <tflink> and virthosts
14:30:44 <tflink> but the virthosts is what is prompting me to start the conversation now - I want to get this figured out before we start deploying anything for disposable clients
14:30:57 <mkrizek> the packaging for epel part scares me
14:30:59 <kparal> if I ever needed virt-in-virt, I assume it's going to work better in Fedora, because it will be newer. but that's just one "maybe" point.
14:31:08 <kparal> *I->we
14:31:27 * tflink would prefer to avoid virt-in-virt for now, at least
14:32:16 <tflink> yeah, the packaging work wouldn't be trivial but I think that should be mostly a one-time-per-release cost rather than an ongoing issue
14:32:28 <tflink> epel packaging work, I mean
14:32:58 <tflink> it wouldn't be so much of an issue if some of the epel proposals discussed at last flock took off but I'm not sure what the satus of those are
14:33:19 <tflink> being able to designate packages to have a shorter maintenance lifetime, mostly
14:34:25 <tflink> if we do go the fedora route for the virthosts, someone is going to have to learn how they're deployed
14:35:11 <tflink> with el7 virthosts, they'd be pretty much the same as what infra does but fedora would be different enough that I'd rather have someone else who knows how all that is done (bus rule)
14:35:38 <tflink> that'll require some passwords, though and I'd want to clear that with infra before doing it
14:35:49 <tflink> using fedora will require a conversation with infra, anyways
14:36:34 <tflink> but if there's not much immediate conversation, we can save it for the list. I mostly wanted to bring the topic up so it doesn't just sit on the list forever :)
14:37:26 * kparal feels he can't help much with this decision
14:38:05 <mkrizek> let's leave it for the list then?
14:38:47 <tflink> kparal: one option requires more packaging work which you could help with :)
14:39:09 <tflink> ok, moving on to the next topic but without josef, I'm not sure I see a point
14:39:17 * kparal hates packaging with passion
14:39:20 <kparal> but will help if needed
14:39:33 <tflink> kparal: shall we skip the 'vm booting' topic until we can find josef?
14:39:41 <kparal> hmm
14:39:51 <kparal> I'll talk to him tomorrow
14:39:59 <tflink> k, sounds good
14:40:03 <kparal> and we can sync up in the evening on irc
14:40:03 * tflink is game for either route
14:40:46 <tflink> for the record - we were going to talk about who's going to be working on the vm booting stuff for disposable clients but if josef's not here, there's not much point in discussing it now
14:41:01 <tflink> #topic meeting format and useful-ness
14:41:23 <tflink> we haven't talked about this for a while but I'm curious to find out what you all think
14:41:45 <tflink> 1) is the current format of requesting pre-prepared #infos working well enough?
14:42:13 <kparal> I think it's fine
14:42:14 <tflink> 2) does the format of weekly meetings and skipping the planning bits every other week make for a good use of time?
14:42:23 <mkrizek> I am ok with the current approach
14:43:03 <tflink> ok, just wanted to follow up and make sure that this doesn't become a waste of time :)
14:43:17 <tflink> which brings us to:
14:43:26 <kparal> 2) also works for m
14:43:27 <kparal> e
14:43:44 <tflink> actually one other thing
14:44:02 <tflink> does anyone have suggestions on how to improve these meetings or make them more useful?
14:44:36 * mkrizek got nothing
14:44:57 * tflink is amused on how he's phrasing these questions like there are 20 people here
14:45:22 <tflink> just wanted to see if there were ideas :)
14:45:30 <tflink> which brings us to (actually this time):
14:45:35 <tflink> #topic open floor
14:45:51 <kparal> nothing here
14:46:47 <tflink> ok, I think we're done with this for the week
14:46:52 <tflink> thanks for coming, everyone
14:46:55 <mkrizek> thanks
14:46:56 * tflink will send out minutes shortly
14:47:01 <tflink> #endmeeting