16:00:14 <adamw> #startmeeting Fedora QA meeting
16:00:14 <zodbot> Meeting started Mon Nov  9 16:00:14 2015 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:14 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
16:00:18 <adamw> #meetingname fedora-qa
16:00:18 <zodbot> The meeting name has been set to 'fedora-qa'
16:00:21 <adamw> #topic Roll call
16:00:29 <adamw> morning folks, who's around for QA fun?
16:00:46 * pschindl is here
16:01:00 * satellit_e listening
16:01:04 * lbrabec is lurking
16:01:04 * garretraziel is here
16:01:20 <condor> lurking
16:02:07 * Southern_Gentlem here
16:02:40 <adamw> good to see you all
16:02:51 <adamw> everyone doing well?
16:03:17 <Southern_Gentlem> nothing that thanksgiving break will not solve
16:03:48 * kparal is here
16:04:02 <adamw> Southern_Gentlem: will not solve...?
16:04:18 <Southern_Gentlem> yep a week vacation from work
16:04:37 <adamw> oh i see
16:04:40 <adamw> sorry, i misread
16:04:45 <adamw> alrighty, let's get going...
16:04:52 <adamw> #topic Previous meeting follow-up
16:05:27 <adamw> #info "kparal and adamw to update Common Bugs" - that got done, we've both added stuff, I've got one more issue to add today
16:05:41 <kparal> I just added https://fedoraproject.org/wiki/Common_F23_bugs#system-upgrade-locale
16:05:45 <adamw> of course if anyone's aware of a bug causing particular trouble, throw the 'CommonBugs' keyword at it
16:05:52 <adamw> (we should probably list the abrt/selinux bug)
16:06:01 <adamw> oh, i think i already did.
16:06:07 <adamw> kparal: thanks
16:06:37 <adamw> #info "adamw to check in with bcl and wwoods on dnf-plugin-system-upgrade updates status and lorax" - well, the dnf updates went out without lorax at first, but we got lorax pushed soon after, so hopefully it didn't cause any big problems
16:07:37 <adamw> #info "adamw to draft up proposal for better handling of 'special blockers'" - didn't get that done yet, some other stuff came up
16:07:45 <adamw> #action adamw to draft up proposal for better handling of 'special blockers'
16:08:17 <adamw> ok, so from here on, each topic i've got on the agenda is some kind of f24 planning thing
16:08:29 <adamw> before we jump in, did anyone have any other topics that should be added?
16:10:12 <adamw> alrighty then
16:10:18 <adamw> #topic Release criteria and test case changes
16:11:22 <adamw> so we have a couple of proposed changes ATM - installer help from me, and freeipa upgrade from sgallagh
16:11:51 <adamw> are there other places where we need changes that anyone can think of/remember?
16:12:03 * adamw trying to remember issues that came up during validation but his brain feels like cottage cheese right now
16:12:43 <adamw> #action adamw to finish off the 'installer help' criteria / test case changes
16:12:49 <kparal> I have a few ideas
16:12:54 <kparal> but haven't proposed them on list yet
16:13:17 <kparal> for system upgrade, join bios and uefi test cases. I think the split is no longer needed now that we don't have fedup
16:13:34 <kparal> and propose N+2 upgrade criterion
16:14:46 <kparal> that's all
16:15:07 <adamw> hmm, probably reasonable for upgrade, yeah
16:15:38 <adamw> as with the freeipa upgrade thing i feel like the release criteria are becoming a fairly bad way to approach upgrade testing
16:15:41 <kparal> we can still one test case for uefi and one for bios, just to make sure we covered both. we don't need to do everything twice
16:15:48 <kparal> *keep
16:15:51 <adamw> since so little of what can potentially go wrong is actually in the frozen package set at all any more
16:15:53 <fenrus02> was that backported to f21?
16:16:01 <adamw> fenrus02: was what?
16:16:03 <fenrus02> or do they still need to use fedup for f21 -> f22
16:17:17 <fenrus02> for that matter, f21 -> f23
16:17:29 <kparal> system-upgrade is used for f21->*
16:17:46 <adamw> right
16:18:34 <adamw> #info kparal suggests combining bios and UEFI upgrade tests and proposing a criterion for N+2 upgrades
16:18:52 <fenrus02> f21-fedup is deprecated now, and when a user runs it -- informs the user of the new process?
16:18:56 <adamw> i feel like there were some other things that came up during validation but i guess i'll have to go back through meeting logs
16:19:10 <adamw> fenrus02: dnf-plugin-system-upgrade obsoletes fedup
16:19:26 <adamw> (and replaces the 'fedup' command, yes)
16:19:44 <fenrus02> excellent, thanks.
16:20:33 <adamw> alrighty then, next thing...
16:20:44 <adamw> #topic Test Day planning
16:21:08 <adamw> so we noted last week that test days aren't quite where we want them to be, who wants to volunteer to help make that better? :)
16:21:19 <adamw> anyone interested in helping co-ordinate test days overall, or want to volunteer to run a particular one?
16:21:47 <kparal> don't be shy, you'll get a cookie
16:22:13 <pschindl> I was thinking about making a talk for people from Brno about test days.
16:23:00 <pschindl> And I can focus more on test days during f24
16:23:15 <adamw> sounds great
16:23:37 <kparal> pschindl++
16:23:37 <zodbot> kparal: Karma for pschindl changed to 1 (for the f23 release cycle):  https://badges.fedoraproject.org/tags/cookie/any
16:23:37 <adamw> we do need to make sure when we reach out to devs that if they're enthusiastic, we actually wind up running a good event
16:23:48 <fenrus02> is there any feedback on why test-days are not getting people involved?  are they aware of them sufficiently in advance?
16:23:59 <adamw> it's a bad outcome if we're all like 'yeah test days are awesome! come have a test day!' and they say 'sure' and then we half-ass organizing it
16:24:09 <adamw> fenrus02: it's not so much about test days not getting people involved
16:24:27 <adamw> fenrus02: it's more that we're not running as many as we used to and maybe not running the ones we have as efficiently
16:24:40 <adamw> people have been working on other stuff, i think
16:24:45 * fenrus02 nods
16:26:04 <adamw> .#action pschindl to organize all the test days
16:26:11 <pschindl> :) cool
16:26:13 <adamw> :P
16:27:06 <adamw> i guess roshi and i will co-ordinate again and try to do a less half-assed job of it, if anyone else wants to help, please let us know...
16:27:15 <pschindl> But why not I will volunteer someone to help me :)
16:28:08 <adamw> pschindl: hehe, that's the spirit!
16:28:17 <adamw> #topic taskotron, openQA etc. targets
16:28:44 <adamw> so there might already have been some talk about this in the qa-devel meetings i'm never awake early enough to go to
16:28:46 <adamw> tflink?
16:29:21 <tflink> still trying to get openqa systems ready - hit some issues (possibly PEBKAC) on friday, will try again today
16:29:33 <adamw> i was thinking a bit more long-term
16:29:35 <tflink> oh
16:29:41 <adamw> i.e., what are our goals for openQA/taskotron for f24
16:29:52 <adamw> (and other, you know, magic robot tester things)
16:30:02 <tflink> disposable clients, definitely. I also want to have initial dist-git style tasks in place
16:30:38 <tflink> those are the main things for taskotron
16:30:42 <adamw> alrighty
16:30:54 <tflink> not as sure about openqa beyond having a public system in place
16:30:57 <adamw> #info taskotron targets for f24 cycle: disposable clients and dist-git style tasks
16:31:36 <adamw> yeah, for openQA we want to get the public deployment done first of all, beyond that i'd like to look at doing various post-install test stuff
16:32:02 <garretraziel> I also think that various desktop test would be nice
16:32:08 <garretraziel> *tests
16:32:09 <adamw> openQA has a mechanism where one test can upload a snapshot of its finished state and you can start another test from that, we just have to learn how to use it
16:32:52 <adamw> garretraziel: anything else that's a priority?
16:33:23 <garretraziel> nothing that I can think of
16:33:33 * tflink is also hoping to have beaker in place for f24
16:33:45 <adamw> #info openQA targets for f24 cycle: public deployment and post-install testing
16:33:52 <garretraziel> moving to Postgres, but this will come with public deployment
16:34:02 <adamw> garretraziel: yeah, i agree
16:34:03 <garretraziel> (so we could finally try whether GRU works for us)
16:34:29 <adamw> tflink: so on the topic of beaker: do you have any thoughts on what we can *do* with it?>
16:34:42 <tflink> pretty much whatever you want
16:34:55 <tflink> i think that upgrades would be a great fit for beaker
16:34:55 <adamw> tflink: well, let me rephrase: what we *ought to* do with it
16:35:02 <adamw> tflink: i know sudhir is interested in getting RH teams who already have tests in RH's beaker running them in a Fedora beaker
16:35:18 <adamw> i was thinking freeipa testing might make sense in beaker
16:35:27 * tflink doesn't know enough about freeipa to say
16:35:45 <tflink> kernel tests might also make sense
16:35:52 <tflink> since we have 2x bare metal machines for beaker
16:36:20 <adamw> tflink: the kernel test suite stuff?
16:36:37 <kparal> we also can have a battery of anaconda tests running in it
16:36:59 <adamw> the thing with upgrade and anaconda testing is it's kinda duplicated with openQA, i guess
16:37:29 <tflink> kinda, yeah
16:37:41 <kparal> I think the existing beaker anaconda tests cover mostly kickstarts
16:37:52 <tflink> but I still think that beaker is probably a better choice for most upgrade testing
16:37:52 <adamw> ooh, that would be super useful
16:38:05 <adamw> although in that case it's duplicating a bit with anaconda's own automated testing stuff :)
16:38:10 <kparal> and we might have an external team maintaining it, so what's not to like :)
16:38:12 <adamw> but i guess more coverage is always nice
16:38:52 <adamw> so do we want to set any definite beaker targets or is it more of a 'do the best we can' thing?
16:38:55 <tflink> oh, there are likely to be some networking changes coming f24-ish time
16:39:01 <adamw> maybe the target is 'have it set up and running *something*'?
16:39:05 <tflink> "do the best we can do "
16:39:35 <adamw> tflink: i'm willing to help out with it if there's anything i can do, though i'm starting more or less from scratch with beaker
16:40:08 <tflink> right now, we're pretty much getting auth/authz figured out
16:40:22 <tflink> blocked on both me and the beaker devs, I need to follow up on a few things
16:40:38 <tflink> after that's done, we should be ready for the production system
16:40:43 <adamw> alright
16:41:02 <adamw> #info beaker targets for f24 cycle: do the best we can, but it'd be good to have it deployed and running *something* even just as an example
16:41:22 <adamw> alrighty...anything else in this general vein?
16:41:30 <tflink> network changes
16:41:35 <adamw> tflink: can you elaborate?
16:42:05 <tflink> right now, all of our automation masters and clients are on the same network as the ppc builders, kernel test machines and arm koji
16:42:23 <tflink> which is not a good thing as we start taking more tasks from non-core-devs
16:42:56 <tflink> january-ish timeframe we're likely to be moving machines around so that the clients are more isolated and we're not sharing a network with the ppc builders anymore
16:43:09 <tflink> so that'll probably mean some downtime, hopefully not much
16:44:53 <adamw> okay
16:45:01 <tflink> the details are still being worked out but figured I would give a heads up
16:45:15 <adamw> so this is the taskotron machines?
16:45:22 <tflink> taskotron, beaker and openqa
16:45:35 <adamw> oh, okay, they're all together. roger.
16:45:49 <adamw> #info around january, taskotron/openqa/beaker hosts will be subject to some network changes
16:45:50 <tflink> the way things are looking, this will have a big effect on all of our systems outside blockerbugs
16:46:10 <adamw> another thing, i guess, is now we have bodhi 2.0, we could be trying to push more active use of its new features
16:46:25 <tflink> such as?
16:46:37 <adamw> well, taskotron integration i guess
16:46:43 <adamw> gating updates on tests
16:46:51 <adamw> and also the manual equivalent, gating updates on manual tests
16:47:17 <adamw> all that stuff is there, i think, but we haven't made any real organized effort to start using it
16:47:23 <tflink> wouldn't that need a better tcms or are you talking about putting results into bodhi by hand?
16:48:21 <adamw> ?
16:48:28 <adamw> aiui bodhi can already do all those things
16:48:38 <adamw> it gets taskotron results via fedmsg or carrier pigeon or something
16:48:53 <tflink> it queries resultsdb
16:48:55 <adamw> and when you create an update you have some boxes to check for requiring this or that or the other to pass before the update can go out
16:49:07 <adamw> but it's all just kinda 'there'
16:49:23 <adamw> anyway, sounds like no-one has really been working on it, so i guess we can table it for another time, plenty to be going on with here...
16:49:38 <tflink> yeah, no shortage of stuff to dao
16:49:39 <tflink> do
16:50:18 <adamw> alrighty then
16:50:20 <adamw> #topic Open floor
16:50:23 <adamw> any other business, folks?
16:53:24 <adamw> alrighty then, everyone can go grab a beer or something i guess
16:53:50 <adamw> also i need to figure out why boot.iso generation for rawhide isn't working so we can get an initial f24 test event up
16:54:26 <adamw> where by 'figure out' i mean 'bug dgilmore'
16:54:41 <tflink> he's on pto
16:54:57 <adamw> ok, then bug his non-union mexican equivalent
16:54:59 <adamw> (nirik)
16:55:13 <nirik> que?
16:55:22 <adamw> #action adamw to work with releng to get rawhide nightly boot.iso compose working and create an initial f24 nightly validation event
16:55:33 <adamw> nirik: rawhide boot.iso generation isn't working, be good to fix that
16:55:35 <nirik> ah yeah, I think maxamillion was looking into that too.
16:55:44 <adamw> oh, that might be why he was asking about lorax, i guess...
16:55:50 <nirik> yep
16:55:51 * adamw sets the fuse
16:58:13 <adamw> thanks for coming, folks
16:58:15 <adamw> #endmeeting