15:02:12 <adamw> #startmeeting Fedora QA meeting
15:02:12 <zodbot> Meeting started Mon Apr  4 15:02:12 2016 UTC.  The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:02:12 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:02:12 <zodbot> The meeting name has been set to 'fedora_qa_meeting'
15:02:16 <adamw> #meetingname fedora-qa
15:02:16 <zodbot> The meeting name has been set to 'fedora-qa'
15:02:18 <adamw> #topic Roll call
15:02:22 <adamw> ahoyhoy folks!
15:02:32 <tflink> .hello tflink
15:02:33 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
15:02:37 * garretraziel greets adamw
15:02:40 <handsome_pirate> Ahoy, me hearties!
15:02:54 <adamw> ahoy garretraziel
15:02:58 * satellit_e listening
15:03:15 * pschindl is here
15:06:00 <adamw> hum, was hoping we'd have cmurf
15:06:07 <adamw> ah well
15:06:47 <handsome_pirate> adamw:  Want me to be cmurf?  I could be cmurf if you want.  Why do we want cmurf?
15:07:27 <adamw> he wanted to talk liveusb-creator
15:07:33 <adamw> #chair tflink pschindl
15:07:33 <zodbot> Current chairs: adamw pschindl tflink
15:07:40 <adamw> #topic Previous meeting follow-up
15:08:56 <adamw> #info "adamw and kparal to work on common bugs" - we got that done, https://fedoraproject.org/wiki/Common_F24_bugs looks good
15:09:36 <adamw> "adamw and tflink to sort out a reply to apeter about the testdays webap" - tflink, you took care of that i think?
15:09:43 <tflink> yeah
15:09:59 <tflink> the links in the wiki were wrong, fixed those and created the test day
15:11:46 <adamw> cool, thanks
15:11:59 <adamw> #info "adamw and tflink to sort out a reply to apeter about the testdays webap" - tflink took care of this, provided accurate links and helped set up the test day
15:13:26 <adamw> #info "adamw to blog / microblog about l10n Test Day" - I did that (blog and G+ and twitter), attendance was still not great though I think :(
15:14:15 <handsome_pirate> adamw:  sorry, was busy last week.
15:14:16 <adamw> that's all the action items, any other last week followup before we move on?
15:14:22 <adamw> handsome_pirate: no probs, it happens
15:15:27 <adamw> alrighty, moving on
15:15:38 <adamw> #topic Fedora 24 status
15:15:53 <adamw> so i was keeping this on here just to briefly let folks know why f24's been a pile of fail lately...
15:17:18 <adamw> basically a bad change to anaconda (it was an attempt to deal with the glibc locale changes that didn't work out so well) got out to f24 stable, unfortunately. with that change, depending on where you are and whether you have a network connection when anaconda starts, it will just crash at start.
15:17:39 <adamw> anaconda folks gave us a fix and we tested it and it worked, so they submitted it for stable...
15:18:23 <adamw> ...whereupon it turned out the fix included use of 'rich dependencies' in the package (something like "Requires: (apple or orange)") and it turns out the 'masher' tool can't deal with that at all.
15:18:37 <adamw> so releng had to tell anaconda 'sorry, but you can't do that' and anaconda had to come up with something else, and that's where we stand now.
15:19:11 <adamw> sbueno tells me she's going to do an f24 build today with some other way of dealing with the dependencies, and then hopefully f24 should be installable and the openQA results shouldn't look so sad any more.
15:19:53 <adamw> #info f24 anaconda has been broken in many cases for the last week or so due to an unfortunate combination of issues, should be un-broken shortly if we can karma another anaconda update promptly
15:20:15 * kparal is here
15:20:19 <adamw> hi kparal
15:20:33 <adamw> other than that, well, let's take a look at the schedule...
15:21:14 <adamw> Beta freeze is 2016-04-19, go/no-go is 2016-04-28, so keep those dates in mind
15:21:41 <adamw> we haven't had a 'candidate' (like a TC) or a validation event for nightlies because of the anaconda mess, i figured there was no point until that's sorted out; once it is we'll get a nightly event created
15:22:16 <adamw> #info validation events will resume once the anaconda mess is sorted out, Beta freeze is 2016-04-19, go/no-go is 2016-04-28
15:22:23 <adamw> any other f24 status stuff? questions, notes?
15:24:04 <adamw> allllrighty then
15:24:07 * adamw resumes the monologue
15:24:22 <adamw> I think next week we can rename the QA meeting "And Another Thing...With AdamW"
15:24:36 <adamw> #topic Fedora Media Writer status and test planning
15:24:40 <adamw> so, this was the topic cmurf suggested
15:24:41 <tflink> qa meeting: "that time when adam talks at us" :-D
15:25:27 <adamw> for anyone who isn't aware, 'Fedora Media Writer' is apparently what they're calling the big rewrite of liveusb-creator that's happening for this cycle
15:25:45 <kparal> adamw: have you heard from sumantro and arvind whether they're going to organize that test day?
15:25:48 <adamw> this is of interest to us, well, because liveusb-creator is a supported USB writing method so we need to test it, but *especially* because there's a plan to make it the 'default download' for Workstation
15:25:59 <adamw> kparal: sumantro pinged me today but it was at like 5:30am my time
15:26:04 <adamw> bit of a timezone issue there :/
15:26:05 <adamw> i'll email them
15:26:39 <kparal> ok. and teach them to ping publicly, so that we can respond instead if possible
15:26:42 <adamw> for anyone who isn't aware - sumantro and arvind are a couple of new RH interns who'll be helping with Fedora QA, they introduced themselves on the list, they'll be working on stuff like test days and so on
15:26:45 <adamw> yep, point
15:27:34 <adamw> so yeah - that Change is https://fedoraproject.org/wiki/Changes/LUCasPrimaryDownloadable
15:27:57 * kparal is looking forward to nuking all other usb writing methods from the test matrix ;-)
15:28:16 <adamw> the idea is basically that when you go to download Workstation you won't get a .iso file and some links you can click for instructions on what to do with it, you'll get this 'media writer' tool for your platform, which can download the ISO and write it to USB for you. that's AIUI anyhow.
15:28:19 * satellit_e is it working?
15:28:21 <adamw> kparal: ahahahaha, good one.
15:28:24 <adamw> satellit: that's kind of the question =)
15:28:31 <adamw> i honestly haven't looked at it at all myself
15:28:38 <kparal> the current build has broken deps
15:28:43 <adamw> but from a couple of mails i've seen it sounds like it may not be in great shape
15:28:51 <kparal> well, missing deps
15:29:06 <kparal> I didn't go further than that
15:29:34 <adamw> i think i saw a mail about functionality issues too at some point, but i may of course be dreaming it
15:29:42 <satellit_e> very hard to use: only downloads f23 atm....default download is /  which means navigating to user/home/downloads for f24 .iso's
15:29:48 <adamw> or drunk. or whatever. /me pours more fine canadian whisky on his cornflakes
15:29:56 <adamw> satellit: ah right, it was you who gave it a try wasn't it?
15:29:58 <adamw> thanks for that
15:30:26 <adamw> just lemme write a couple of quick infos
15:30:48 <adamw> #info Fedora Media Writer is the rewrite of liveusb-creator which is slated to become the default Workstation download, thus it's quite important
15:31:12 <adamw> #info currently kparal reports that the package has dep issues and satellit_e reports that the tool has several interface and default functionality problems
15:31:37 <adamw> so to me at least it kinda sounds like we should organize a test day for this thing before beta, and see if we need to start ringing alarm bells
15:31:47 <kparal> the tracker bug is helpful to seeing the issues: https://bugzilla.redhat.com/show_bug.cgi?id=1310542
15:31:48 <satellit_e> +1
15:32:02 <adamw> i would be a bit worried if anyone wanted to ship this thing at Final without a dry run at Beta to see how it goes
15:32:07 <adamw> kparal: thanks
15:32:16 <kparal> satellit_e: could you report the problem of using / as a default download directory?
15:32:18 <adamw> #info that bug (1310542) is the tracker bug for issues with the new tool
15:32:45 <kparal> satellit_e: of if you did, add it to the tracker bug? that would be great
15:32:52 <satellit_e> simpler fix: use old interface with default to (dd) and have mbr overwrite button wher persistence wa
15:32:56 <satellit_e> was
15:33:40 <satellit_e> new interface makes it hard to find spins   hidden under -- title
15:34:10 <adamw> so to make sure this actually happens and the ball doesn't hit the floor, i'm thinking of #action'ing sumantro and arvind to set up the test day and me and kparal to keep an eye out and make sure it happens and come up with a fallback (i.e. do it ourselves) if it doesn't - sound reasonable?
15:34:28 <adamw> satellit: we can figure out the details of fixes / design improvements in tickets and such i think
15:34:35 <satellit_e> k
15:35:17 <kparal> pschindl: you help out with test days these days, want to take this one? (overseeing sumantro and arvind)?
15:35:24 <adamw> ah right, he'd be a better candidate
15:35:48 <kparal> now, I'm just good at throwing my work on other people backs :)
15:35:52 <pschindl> kparal: sure
15:35:53 <kparal> *no
15:35:57 <kparal> pschindl: thanks
15:36:14 <satellit_e> FYI https://bugzilla.redhat.com/show_bug.cgi?id=1310542#c7
15:37:08 <kparal> satellit_e: the default mode is going to be dd
15:37:47 <kparal> they just didn't create a new build yet
15:38:05 <adamw> #action sumantro and arvind (new RH interns) to set up Test Day for Fedora Media Writer before Beta freeze (2016-04-19)
15:38:37 <adamw> #action adamw and pschindl to oversee the Test Day and make sure planning is well underway by next week (2016-04-11), otherwise step in
15:38:56 <adamw> yay, lots of cooks for that one!
15:39:26 <adamw> #info ticket for Test Day is https://fedorahosted.org/fedora-qa/ticket/483
15:40:04 <adamw> anything else on this before we move on?
15:40:05 <kparal> pschindl: we should also ping mbriza to find out if fedora media writer is getting those issues fixed before the test day
15:40:16 <mbriza> which issues?
15:40:32 <kparal> mbriza: all those tracked under https://bugzilla.redhat.com/show_bug.cgi?id=1310542 :-)
15:40:35 <kparal> mbriza: hello
15:40:37 <mbriza> hey
15:40:47 <satellit_e> I still think haveing a butto to append liveusb-write --reset-mbr checkbox
15:40:56 <kparal> I think we can take this coversation out of the meeting
15:40:56 <satellit_e> button*
15:41:07 <kparal> mbriza: could you perhaps join #fedora-qa ?
15:41:16 <mbriza> kparal: sure, let's continue there?
15:41:22 <kparal> mbriza: yes
15:41:29 <mbriza> ok, satellit_e: i'll reply there
15:41:35 <satellit_e> k
15:43:41 <adamw> kparal: good point
15:43:50 <adamw> kparal: i'll add a ticket comment for that
15:44:01 <adamw> #topic Anaconda package update testing improvement
15:44:06 <adamw> so...this is a big topic that's a bit mushy at present
15:44:18 <adamw> but i thought it merited some initial meeting discussion and just to make sure people know about it
15:44:39 <adamw> this is about a releng ticket I filed last week: https://fedorahosted.org/rel-eng/ticket/6383
15:45:35 <adamw> the whole f24 anaconda mess made me very sad since we really should be capable of making that...not happen. we've known for a while that the chicken-and-egg problem with anaconda updates going to stable is a real pain point in our process, but this time i kinda really want to do something about it
15:45:53 <adamw> does everyone know what i mean by 'chicken and egg problem' or should I recap it?>
15:46:14 <tflink> it sounds to me like there are 2 sticking points: how the "test images" are generated and what is done for testing
15:46:19 <tflink> 2 primary
15:47:01 <kparal> we were able to test new anaconda builds from older lives
15:47:06 <kparal> but not netinst
15:47:13 <kparal> is that the problem you're talking about?
15:47:13 <tflink> I'm very interested in the test image generation part, though - it's going to be an issue/topic for general automation before long
15:47:48 <adamw> kparal: yes
15:48:10 <adamw> kparal: and updating packages on live isn't always sufficient even for testing live install
15:48:42 <tflink> has releng weighed in on the testing image bit?
15:48:45 <adamw> tflink: 1) is the real 'sticking point', 2) is an...interesting topic for discussion which is going in lots of interesting directions, but bottom line if we had images we definitely have stuff to run on them
15:48:58 <adamw> tflink: dennis has replied in the ticket and we've chatted a bit on IRC
15:49:17 <tflink> which ticket?
15:49:25 <adamw> 6383, at least i thought he'd commented there?
15:49:27 * adamw checks
15:49:33 <handsome_pirate> tflink:  so, make pungi a taskotron task?
15:49:37 <tflink> i don't see anything from him
15:49:38 <kparal> what's the second sticking point?
15:49:42 <adamw> huh, no, he hasn't.
15:49:53 <adamw> kparal: tflink's #2, "what test should be run"
15:50:02 <adamw> i don't really see that as a sticking point, though
15:50:02 <tflink> handsome_pirate: that's certainly an option but I'd rather not go down that road without talking with releng first
15:50:03 <kparal> ok
15:50:18 <tflink> yeah, #1 is the bigger fish
15:50:21 <adamw> so lemme try and remember / summarize what dgilmore said
15:50:36 <handsome_pirate> tflink:  It would be nice, though, and we can set the triggers on anaconda or kernel builds
15:50:40 <handsome_pirate> or whatever
15:50:45 <adamw> he's basically on board with the idea but i get the impression it's not something releng is entirely set up to do right now, it requires some work
15:51:15 <adamw> we also didn't have the same instinct about exactly how much of a compose should actually be done - my instinct was more or less a full compose or at least build every image we can possibly throw a test at, dgilmore was thinking more along the lines of 'build one boot.iso'
15:51:38 <tflink> do you know what bits they're missing?
15:51:43 <handsome_pirate> That would certainly be faster
15:52:02 <adamw> well, if we don't do a full-fat compose the same as a nightly or candidate compose, there'd need to be a new pungi config
15:52:23 <handsome_pirate> ahhh
15:52:37 <adamw> and i guess there needs to be a thing, whatever it is, that listens for updates (and knows what updates are important) and actually runs the compose.
15:52:47 <adamw> i don't know if there's anything more beyond that.
15:52:48 <tflink> unless we can use whatever anaconda's using to generate test images
15:52:58 <tflink> for the short term, at least
15:53:00 <adamw> yeah, that's what anaconda people were talking about. i...am not so sure
15:53:14 <adamw> so again i might be wrong here and i don't want to misrepresent
15:53:26 <adamw> but I *think* we may have been thinking that anaconda's process is a bit more awesome than it actually is
15:53:29 <tflink> i mean the tooling, not sure about using the internal stuff
15:54:09 <adamw> basically i'm not sure they're really at the point of reliably producing testable images that are sufficiently similar to 'real' images for our purposes.
15:54:17 <tflink> if we end up making something "new", my first thoughts would be to either send signals to a releng system to do the image building or write something for taskotron which does a test compose
15:54:48 <adamw> the other problem with doing it anaconda's way (which i think is to bypass pungi and just go direct to lorax) is fedmsg, i guess.
15:54:59 <tflink> most of the bits are in place to support building test images - the biggest thing we'd need is more disk space for artifacts, figuring out what to trigger on and the elephant in the room of  actually building something
15:55:09 <tflink> fedmsg?
15:55:10 <adamw> i'm really struggling with it making sense for anyone other than releng to do this myself
15:55:20 <adamw> tflink: presumably whatever anaconda uses doesn't emit fedmsgs
15:55:20 <tflink> long term, yeah
15:55:24 <adamw> so how do we start the testing?
15:55:31 <tflink> oh
15:55:38 <adamw> with releng-pungi that's all already done.
15:56:02 <adamw> i mean, releng is our team that engineers releases. pungi is our tool for composing them. it seems odd that we'd replicate all of that ourselves, or have anaconda do it. but maybe i'm missing stuff.
15:56:17 <tflink> how is anaconda triggering the testing?
15:56:18 <adamw> #action adamw to get dgilmore to chime in on the ticket with his thoughts
15:56:30 <adamw> i think the answer is either 'jenkins' or 'by hand'.
15:56:34 <handsome_pirate> adamw:  I'm certainly for using pungi
15:56:34 <tflink> there are pieces in place to monitor github and emit fedmsgs if that's an option
15:56:40 <adamw> hold on, let me dig out an email before i dig myself any deeper holes
15:56:52 <adamw> or was it an irc message
15:56:52 <adamw> bahhh
15:58:01 <tflink> in case folks reading this in retrospect misunderstand - I'd really rather not write and maintain our own bits for building images, even for testing. If there's no other sane option, there's no other sane option but it's certainly not my first choice
15:59:07 <adamw> ok yeah, so here's a bit of discussion with bcl - this is all super early stuff, of course, no-one is staked to their positions here (I don't think)
15:59:11 <dgilmore> tflink: afaik they use jenkins and lorax
15:59:20 <adamw> 31-03-2016 14:44:00 < bcl!~bcl@neil.brianlane.com: and I'd do a lorax run against testing, not a full compose.
15:59:20 <adamw> 31-03-2016 14:44:35 > adamw: sorry, can't quite parse the second line?
15:59:20 <adamw> 31-03-2016 14:44:56 < bcl!~bcl@neil.brianlane.com: run lorax not pungi+lorax
15:59:20 <adamw> 31-03-2016 14:45:29 < bcl!~bcl@neil.brianlane.com: against testing, or wherever it is packages end up when they get built
15:59:31 <tflink> yeah, but where does the decision to start come from?
15:59:38 <handsome_pirate> tflink:  I'm just suggesting we use taskotron to trigger images
15:59:44 <handsome_pirate> not do the actual builds
15:59:55 <adamw> tflink: right, that's going to be some kind of new thing whatever approach we pick, i think
16:00:01 <adamw> whoopsie - we're at time here
16:00:04 <adamw> and we have to do blocker review
16:00:18 <adamw> everyone OK if we carry on discussion in the ticket and maybe pick it up next week?
16:00:37 * handsome_pirate is +1
16:00:49 <adamw> did anyone have anything super important for open floor?
16:00:50 <tflink> sure, I doubt this is going to be a short-term thing anyways
16:01:00 <adamw> i wrote a thing that runs anaconda kickstart-tests in openQA. it's crazy! more news later.
16:01:04 * kparal has nothing for open floor
16:01:38 <adamw> #info open floor will be skipped due to lack of time
16:01:42 * adamw sets very short meeting fuse
16:01:58 <adamw> #info discussion of this anaconda testing topic to continue in ticket, list, wherever
16:02:17 <adamw> thanks for coming everyone!
16:02:30 <adamw> blocker review in #fedora-blocker-review very soon (i'll kick it off and leave it open for a few minutes for folks to get coffee etc)
16:02:32 <adamw> #endmeeting