16:00:06 #startmeeting Fedora QA meeting 16:00:06 Meeting started Mon Nov 18 16:00:06 2013 UTC. The chair is adamw. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:06 Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:00:10 #meetingname fedora-qa 16:00:10 The meeting name has been set to 'fedora-qa' 16:00:17 #topic Roll call 16:00:35 ahoyhoy folks, who's around for another week of QA swashbucklin'? 16:00:48 * nirik is lurking around in the back 16:00:54 * kparal is around, whatever swashbucklin' is 16:01:01 * mkrizek is here 16:01:25 * roshi is here 16:01:44 * jskladan is lurking 16:01:51 * jreznik is lurking too 16:02:22 kparal: first one buckles one's swash, then one swashes one's buckle 16:02:37 * tflink is around, in another meeting, though 16:03:40 * pschindl is here 16:04:27 adamw: you're giving my english skills a hard time :) 16:04:39 don't sweat it :) 16:04:51 #topic Previous meeting follow-up 16:05:06 "roshi to help out adamw with CommonsBugs page" - roshi? 16:05:26 done 16:05:32 though, it's an ongoing process :) 16:05:48 so, worked on, I guess would be better phrasing 16:06:09 yup 16:06:27 #info "roshi to help out adamw with CommonsBugs page" - this was done, roshi and adamw together updated the page for F20 Beta 16:06:40 one more for you: " roshi to file Final TC1 compose request" 16:06:43 looks like that was also done 16:06:47 yup 16:06:50 (spoiler alert!) 16:06:55 * pwhalen lurks 16:07:45 * satellit_f20 listening 16:07:47 * adamw notices the worrying amount of lurking going on around this here boat 16:07:50 * adamw grabs harpoon gun 16:08:03 * Viking-Ice 50% in 50% out 16:08:37 #info "roshi to file Final TC1 compose request" - done, adamw added another package to the request and it was built on 11-14: https://fedorahosted.org/rel-eng/ticket/5808 16:08:49 #topic Fedora 20 Final status 16:09:22 so, TC1 is out and in testing 16:09:35 we have a fairly long list of accepted blockers that we're still waiting on fixes for, and some proposed blockers from TC1 testing 16:09:53 probably early enough in the cycle that we don't need to do a blocker meeting today, unless anyone thinks otherwise? 16:10:08 wednesday is fine I think 16:10:22 * Viking-Ice goes checking that list 16:10:22 wednesday seems fine 16:10:46 adamw: btw. I plan to send a change deadline reminder tomorrow, could include blockers there too unless you wants to do it so (as you do, but later) 16:10:57 jreznik: fine by me 16:11:08 ok 16:12:04 as a heads up, we're planning to upgrade the blocker tracking app in the next day or so 16:12:16 seemed relevant to discussion around meeting times 16:12:47 yup small enough to wait for Wednesday 16:12:54 thanks tflink 16:13:02 #info blocker tracking app will be updated 'in the next day or so' 16:13:23 we're waiting on an update to be pushed stable 16:13:38 i was planning to file the TC2 request today, with the new anaconda build and anything else that looks relevant 16:13:42 if that's OK for everyone? 16:14:01 looks like tc1 is missing quite a few of the arm images 16:14:20 * satellit_f20 is 32 bit installer fixed? 16:14:34 i think dgilmore said something about that 16:15:01 satellit_: not yet, looks like we got a bit further figuring out what's going on but not all the way yet 16:15:18 dgilmore: what was the story with ARM images in TC1? 16:15:51 Unable to create appliance : Failed to build transaction : yumex-3.0.13-1.fc20.noarch requires python-pexpect 16:16:44 right, i recall seeing that error message. 16:17:14 for those looking to help with arm testing, the installer can be tested using qemu, I've added updated instructions to the wiki for usage, please edit as needed. 16:17:20 #info several ARM images failed to compose for TC1 due to yumex dependency issue, will try to ensure it's resolved for TC2 16:18:54 there's quite a lot of further test coverage needed, it'd be great to get as much of the matrix as possible done as early as possible 16:19:07 even though we have obvious showstoppers atm 16:19:54 adamw, will cover arm today 16:19:55 would be nice to have as much coverage as early possible, indeed 16:20:01 * satellit_ minor fixes for sugar-runner needed https://bugzilla.redhat.com/show_bug.cgi?id=1030418 16:21:03 * satellit_ http://bugs.sugarlabs.org/ticket/4258 wrong naming in control panel peter says fixes are available 16:21:41 satellit_: thanks 16:21:50 as long as pbrobinson is on it, sounds like it'll get fixed 16:21:58 sugar has some minor : ) 16:23:45 adamw: yep, it's a minor annoyance as opposed to any particular issue 16:25:15 rockin' 16:25:36 #info still lots of gaps in the matrices from TC1 testing, we should aim to get as close to full coverage as we can with TC2 16:25:46 #info TC2 request will likely be filed today 16:26:57 anything else on Final? 16:28:20 * roshi has nothing 16:28:59 moving right along then... 16:29:01 #topic Open floor 16:29:12 didn't really see any other specific topics worth listing 16:29:22 but if you have anything about fedora.next or test days for instance, now's the time! 16:29:43 if anyone wants to test the new blockerbugs version, it's available in stg 16:29:48 https://qa.stg.fedoraproject.org/blockerbugs/ 16:30:10 adamw, the next/wg stuff got put on ice until after new year 16:30:24 we have no clue ( and neither to the WG ) what exactly they want from us 16:30:51 s/to/do 16:31:30 but I would say our stand point is simply installer + what ever comes from the baseWG 16:31:31 #info new blocker bugs upgrade is in staging: https://qa.stg.fedoraproject.org/blockerbugs/ 16:31:35 rest sub communities 16:31:52 Viking-Ice: i think that's a reasonable starting point 16:32:05 I have one topic - adamw recently commented to one Predictable Network Interface Names feature, that it was never implemented at all... I'd like to have some QA coverage on at least system wide changes we have for F20 as we talked about that some time ago... I know, hard times for QA but during release but... I can prepare a list 16:32:24 Viking-Ice: but as you say it's pretty difficult to figure out what people are expecting of us at present :/ 16:32:29 jreznik, it's implemented the problem the dell stuff did not get removed 16:32:51 right, i said it 'effectively wasn't implemented as described' because biosdevname is gazumping it. 16:32:52 Viking-Ice: well, it was just an example... 16:32:53 adamw, we in serverWG have not agreed where we are heading amongst our selves 16:32:58 * satellit_ wish eth0 and wifi names were simpler 16:33:08 jreznik: well, my report about that was basically a result of me testing it, as part of us testing major Changes. :) 16:33:28 jreznik, f21 will have systemd-networkd I assume so.. new network units hurray ;) 16:33:28 satellit_: yep, we're maybe oldschoolers :) 16:33:33 jreznik: i'd already written in multiple bugs about it, talked to notting about it, etc. that note was just a way of making sure fesco was aware this problem existed. 16:33:34 adamw: well, it's F19 one :D 16:34:02 but still it's good you raised that question 16:34:24 https://bugzilla.redhat.com/buglist.cgi?component=Changes Tracking&product=Fedora 16:34:35 biosdevname should be removed obsoleted/deleted killed gazunked zombified shot stabbed and buried 6 feet under 16:34:46 it's yesterdays news 16:35:14 jreznik: of the f20 approved system-wide changes, i'd say really the only ones we haven't covered to some extent which maybe it would be nice to have covered are the new features in NM 16:35:50 Viking-Ice: notting's going to commit that for F21 shortly (or he did already) 16:35:54 I expect for NM, there's test day planned, right? 16:36:21 adamw, he should do that for 20 as well 16:36:39 jreznik: no, there is no NM test day planned. 16:36:40 jreznik, if either of the Dan's have approach us with it 16:37:01 we do not autocreate test days for features 16:37:12 Viking-Ice: i'd really rather not do it this late for F20, it's a bit of a messy area - f19 already burned us - and right now we're moderately confident the f20 behaviour is at least a) predictable and b) sane 16:37:38 it's not what we wrote down on the feature page, but at least it's not changing the names of interfaces between installation and boot like f19 was :/ 16:38:06 I disagree we should removed it while it's still the chance 16:38:06 adamw: when/where/how to have the btrfs and LVM thinp convo? 16:38:07 ok 16:38:22 what 'convo' is this, cmurf? 16:38:41 adamw: conversation? 16:38:49 yes sorry for the lingo, i'm lazy 16:39:00 i know what 'convo' is short for 16:39:07 i am unclear what conversation you are referring to 16:39:24 the one with dlehman, and whoever else, about making btrfs a tech preview or not 16:39:34 * Viking-Ice had no idea what convo was for thought alcoholic beverage 16:39:35 to at least clarify what things are edge cases, and should be supported 16:39:46 line in the sand so to speak 16:40:06 well, if you're talking about f20, 'when' would be 'as soon as possible' 16:40:06 cmurf: we talked with guys a bit in #anaconda but no clear result 16:40:17 I guess after what stunt marketing did we need to cover *all* lvm thinp stuff 16:40:19 adamw: i'm even suggesting that it doesn't need to be for f20 16:40:20 'where' would be '#anaconda or somewhere else anaconda folks are listening' 16:40:36 and 'how' would be 'tactfully'? :) 16:40:47 Viking-Ice: yeah, point, marketing is clearly involved 16:41:31 adamw, well I would say we wheren't ready for lvm thinp but marketing went ahead and advertized it 16:41:52 was LVM thinp in Rawhide for more than 10 hours before branch? 16:42:09 because it didn't work at all, i mean at all, until beta test candidates 16:42:25 "Cloud and Virtualization Enhancements 16:42:25 OS Installer Support for LVM Thin Provisioning – With the introduction of thin provisioning via Logical Volume Manager (LVM) in the Linux kernel, Fedora 20 can now support the configuration of thin clients during OS installation." 16:42:29 Viking-Ice: what's advertised in alpha/beta notes does not mean it has to be in final 16:42:53 jreznik, I'm pretty sure all RHEL customers http://www.redhat.com/about/news/archive/2013/11/fedora-20-heisenbug-now-available-in-beta-release 16:42:55 disagree... 16:43:37 so I guess what got stated there is that sand in the line cmurf was looking for 16:43:38 anyway, i think the Btrfs and Thinp, line in sand, also relates to adamw's feedback to Manual Partitioning UI 16:43:43 well it clearly doesn't HAVE to be, but viking-ice is obviously right that listing it at alpha and beta then changing our minds for final isn't _ideal_ 16:43:51 they're all related things 16:44:08 Viking-Ice: Fedora is not RHEL - so we will have different set of features than RHEL as always 16:44:16 And the way I see it, Manual Partitioning should be decoupled from the installer. 16:44:39 jreznik, Fedora is not RHEL you should explain that to some of your coworkers ;) 16:44:43 adamw: it's for what Alpha/Beta is - to test stuff, ask people to take a look and delist in case it's not there 16:44:47 The sorts of sane things people need to do with Thinp and Btrfs can't be done with the installer now, and yet the UI is too complicated, and there's one guy working on storage stuff. 16:44:59 And a big reason why I think that is, is because the UI is installer context only, not general purpose. 16:45:00 jreznik, but advertizing something then retract that does not work well 16:45:13 Viking-Ice: right, so I don't get you pointing to redhat press release and talking about not ours customer 16:45:15 s 16:45:49 So who would care to contribute much effort to that when it's a.) a RHEL/Fedora only installer and b.) not a GUI that can be used to create storage for use other than for installing an OS. 16:46:27 This also relates to Viking-Ice's email to the anaconda list that went unanswered essentially, which is stabilizing the installer. 16:46:43 I think a huge number of bugs are in custom partitioning compared to any other single area. 16:47:53 Anyway, maybe this actually maybe this needs to be brought to one of the WG's like the workstation WG or something and see if they want to flush this out - as if they don't already have enough to chew on... 16:47:55 jreznik: I think viking's point is that press releases put out by RH's press office are fairly widely distributed and read by important folks 16:48:16 adamw, right 16:48:21 cmurf: i'm not sure it'd be any single WG's responsibility :/ 16:48:36 adamw, specially the cloud section these days 16:48:40 I think server WG could almost care less about this except having kickstart functionality 16:48:43 it all depends on how this stuff about whether different products can have different install experiences and schedules and stuff shakes out 16:49:06 adamw, we might be having a competing installer to anaconda 16:49:07 and cloud WG may not care about installer UI at all either as far as I can tell 16:49:17 adamw, sooner rather then later 16:49:20 adamw: but it does not force us to ship something we do not trust to 16:50:41 manual partitioning is simultaneously too complicated and not capable enough... 16:52:15 adamw, I asked the anconda folks the other day about all the customized installer ideas for wg ( because we in serverWG would need custom netinstaller iso ) and they said that would only be limited to custom spokes 16:53:17 okay 16:53:20 And on the other hand, it's not fair to always go to anaconda folks and basically say "gimme" 16:53:22 so we clearly have a _bigger_ mess here 16:53:46 but cmurf's idea about de-emphasizing thinp and btrfs is something we at least have the potential to do for f20 if we think it's the right thing to do 16:54:04 " Viking-Ice: well, I think we could show different spokes based on the WG 16:54:04 Viking-Ice: and if a WG wants some specific functionality, there is the Anaconda addon API they can use to write a custom addon" 16:54:17 adamw: it might be as simple as me not looking for anymore bugs seeing as the vast majority of them are ones i found, filed, and nominated as blockers 16:54:20 btrfs i'm not sure about - and it'd be more complex to 'conditionally take out' - but thinp should 'lift out' quite easily, to be made available only with a parameter or only in custom part or something 16:54:35 * kparal is for de-emphasizing btrfs and thinp and rather spending the time on blivet unit testing 16:54:36 if i stop doing that voluntarily, probably 90% of the urgency goes away 16:54:41 what do others feel about proposing that thinp be made less prominent? 16:55:12 both brtfs as well as thinp should be in stage of experimental 16:55:20 marketing wize 16:55:36 or feature preview or what they call it these day not ready for production so to speak 16:55:53 well what's funny is that Btrfs developers consider it experimental still, yet it was made an unhidden feature in Fedora circa F16. 16:56:28 And then LVM thinp is kinda sorta considered stable but somehow ended up in the installer without any preview period at all. 16:56:33 users should be notified that these two filesystems are experimental and the installation might not proceed smoothly. and we should not take them as blockers\ 16:58:10 kparal: for thinp that seems reasonable, for Btrfs that seems like a regression only now that the camel's nose is well inside the tent 16:58:30 let's call it a fix :) 16:59:04 I'd call it a policy to explicitly allow kicking Btrfs cans down the road without an actual plan. 16:59:26 I think there should be a plan so we know what sorts of exposure there is, and what to test, etc. 16:59:39 cmurf, right Josef will come and let us know when it's good enough 17:00:27 Btrfs is good enough. The openSUSE folks have a lot of this stuff working in their installer, and they don't have broken kernel updates. 17:01:03 Fedora GRUB2 is behind upstream's Btrfs fixes. 17:01:14 kparal: anaconda guys were more inclined to allow it boot time over that warning 17:01:22 Grubby is confused about Btrfs, not the other way around. 17:01:30 we need more/new installer and dev team+ 17:02:11 The installer has no idea what to think of 100 snapshots of root, so it shows them as 100 independent installations without any differentiation at all. 17:02:12 Etc. 17:03:13 cmurf, as well as this http://www.spinics.net/lists/linux-btrfs/msg25502.html 17:03:54 which manifests itself like this " is initially mounted readonly by the initramfs, and then after switching 17:03:54 to the real system, /home is attempted to be mounted in parallel with / 17:03:54 being remounted rw. If remounting rw happens first, boot proceeds. If 17:03:54 mounting /home is attempted to realy, it fails." 17:04:49 so there are some issues with dracut/systemd and btrfs snapshots ro/rw 17:04:58 so we have kparal's proposal: 17:05:02 "users should be notified that these two filesystems are experimental and the installation might not proceed smoothly. and we should not take them as blockers\" 17:05:09 ack 17:05:13 do we want to vote on that? 17:05:20 already did ;) 17:05:22 =) 17:05:24 anyone else? 17:05:26 can we, just our team alone? 17:05:27 ack 17:05:33 kparal: let me clarify: 17:05:35 i agree with the first part, I don't agree with the 2nd 17:05:49 Users should be warned. We should still take Btrfs blockers. 17:06:03 we cannot and should not block on experimental 17:06:07 cmurf: the reason why we do it is to not to block on it 17:06:22 We've been blocking on it for what, 2 years? 17:06:28 otherwise it's nonsense block on something that we consider experimental 17:06:29 cmurf: I meant that we might not consider btrfs and thinp to have same weight as ext4, for example 17:06:30 Oh wait, we've been blocking on some bugs, but not other bugs. 17:06:49 propose #agreed we will propose to anaconda team and/or fesco that anaconda and F20 marketing be modified to put LVM thinp in 'feature preview mode': the installer should hide it or warn that it is unsupported, and marketing materials should either leave it out or list it as a preview 17:06:52 but we can still take blocker for really important cases 17:06:53 cmurf: and it's something we want to change to lesser overhead with blocking on something we do not think it's there 17:07:02 (I'll make an identical separate proposal for btrfs so we can vote on them separately) 17:07:05 Well thinp is a bit out of scope seeing as it's a year old compared to 7 years for Btrfs. 17:07:10 adamw, just lvm thinp 17:07:18 vote on thinp first 17:07:22 ack 17:07:34 ack 17:07:36 ack for me 17:07:36 ack 17:07:39 ack 17:07:42 ack 17:07:45 i think that passes 17:07:46 jreznik: I think we need to differentiate Btrfs problems from other problems. 17:07:48 +1 ach 17:07:50 ack 17:07:52 #agreed we will propose to anaconda team and/or fesco that anaconda and F20 marketing be modified to put LVM thinp in 'feature preview mode': the installer should hide it or warn that it is unsupported, and marketing materials should either leave it out or list it as a preview 17:08:05 so for btrfs do we want to vote on an identical proposal, or take a different approach? 17:08:06 adamw: I'll take care of this as part of thinp change 17:08:21 #action jreznik to move forward with proposing switch to 'feature preview mode' for thinp 17:09:03 thoughts on btrfs specifically now thinp's out of the way? 17:09:05 adamw: Please submit it to FESCo if you think we need to invoke the fallback plan 17:09:23 (Which it sounds like we do) 17:09:24 And btw on thinp, I've yet to see any beta related bugs filed on it. *shrug* 17:09:34 sgallagh: deferring to jreznik 17:09:38 ack 17:10:00 sgallagh: the contingency plan is...somewhat sparse: https://fedoraproject.org/wiki/Changes/InstallerLVMThinProvisioningSupport#Contingency_Plan 17:10:09 cmurf: It didn't work at Alpha, so it probably should have been deferred then 17:10:13 so we're sort of inventing one. :) 17:10:39 The issues with thinp are that due to its fixes, conventional LVM seems to have some new bugs that are regressions. 17:10:41 adamw: Hmm, I could have swarn the contingency plan was "remove it from the drop-down box" 17:10:50 sgallagh: me too 17:11:02 welp, yeah, that's more or less what we're suggesting 17:11:06 jreznik: What are you saying "me too" to? 17:11:18 so if we don't have a concrete proposal for btrfs we should probably start wrapping up 17:11:20 it's 11 mins over 17:11:23 sgallagh: I thought the same 17:11:43 I'd OK with the same proposal for btrfs. of course it's just a proposal and anaconda team's opinion is most important here 17:11:46 adamw: put the question to one of the lists? And then discuss in a week? 17:12:13 Almost any bug at this point is an F21 RFE 17:13:04 so btrfs next? 17:14:02 the thing for btrfs is i'm not sure we could cleanly lift it out at this point 17:14:17 we could take it out of the installation options drop-down and make it custom only... 17:14:21 I think doing that would be inappropriate anyway. 17:14:30 but it actually works fairly well from installation options, so i'm not sure that addresses anything 17:14:40 That's the only one what works reliably. 17:14:43 what=that 17:14:57 All of the problems are Manual Partitioning problems. 17:15:13 adamw, think of it this way it's a bit worrying in relation with btrfs that harald's patch has been sitting there on their mailing listfor 5 months without a reply. 17:15:24 If I have 1000 snapshots, I can't even use Manual Partitioning to blow away the Btrfs volume. 17:15:33 Guided can do that. 17:15:35 and there are *issues* with btrfs and dracut/systemd/fstab 17:15:36 fesco#1140 reopened for thinp 17:15:39 sgallagh: ^^^ 17:15:42 jreznik: ack 17:15:49 cross-ML discussion with anaconda then? /me is hungry 17:16:03 kparal, enough food in the beer ;) 17:16:05 kparal: me too 17:16:33 Tech preview for Btrfs is a hammer. We need a scalpal. 17:17:01 Viking-Ice: Czech say that beer is a liquid beer 17:17:02 OK, seems like we don't really have a btrfs proposal at present, so let's wind it up 17:17:11 er 17:17:12 cmurf: you want an action item to try and move it forward? 17:17:24 Viking-Ice: beer is a liquid bread :-) 17:17:39 kparal: or you? or both of you? :) 17:17:59 #action cmurf and kparal to discuss status of btrfs with anaconda team 17:18:00 there! 17:18:09 hmm 17:18:09 fine 17:18:17 whatever, need to eat! :) 17:18:18 and adamw is off the hook haha 17:18:24 clever 17:18:37 well hey, i never thought of that! 17:18:39 ;) 17:18:43 * adamw sets quantum fuse 17:18:56 hey where is that btrfs proposal ? 17:19:35 just copy paste the previous one 17:19:40 what the hell? 17:20:34 Viking-Ice: sorry, it didn't look like it had the votes to go through in the same form 17:20:38 but if you want to vote on it, we can 17:20:52 adamw, who's against it ? 17:20:58 i am as written. 17:21:01 i am as written too 17:21:11 and me and kparal are both with it 17:21:28 propose #agreed we will propose to anaconda team and/or fesco that anaconda and F20 marketing be modified to put btrfs thinp in 'feature preview mode': the installer should hide it or warn that it is unsupported, and marketing materials should either leave it out or list it as a preview 17:21:29 no, I'm for dinner and against everything else 17:21:29 To back out Btrfs that much, that broadly, I think is beyond this venue's voting power. 17:21:32 grr 17:21:41 propose #agreed we will propose to anaconda team and/or fesco that anaconda and F20 marketing be modified to put btrfs in 'feature preview mode': the installer should hide it or warn that it is unsupported, and marketing materials should either leave it out or list it as a preview 17:21:58 That needs to go to a WG or FESCO, or at least involve the anaconda team, and Josef or Eric S 17:21:58 cmurf: we're not voting to _do_ anything, only to propose it to the people who can do it / require it to be done 17:21:59 ack due to known issues with btrfs/fstab/systemd/dracut 17:22:20 nack on the basis that we can't really make that change to btrfs cleanly this late 17:22:21 which upstreams seems to be ignoring or considering features 17:22:26 (thinp lifts out much more easily) 17:22:38 adamw, so install broken setup for users great ;) 17:23:07 nack on the proposal 17:23:14 I think we should have a longer discussion about the possibilities 17:23:22 nack at the moment 17:23:37 agreed 17:23:57 good to know your guys perspective on installing broken setup for our end user base 17:24:08 I just wanted a line in the sand, not 25 dump drunks of sand dropped on Btrfs. 17:24:19 haha drunks = trucks 17:24:20 we could have left FESCO to ack/nack this and take the blame or praise 17:24:34 Viking-Ice: you could take it to fesco as a personal proposal if you feel strongly about it 17:24:45 but looks like it's not got the votes to be a QA group proposal 17:24:45 Might be interesting to see what happens. 17:24:45 adamw, I said my mind here 17:24:46 * kparal goes afk 17:24:54 okay, restarting the quantum fuse! 17:24:56 But that's a lot of rope to hand over to FESCO. 17:24:56 * jreznik has to go now too 17:25:04 I'm not to blame when the raise contions occures for our end users 17:25:19 Viking-Ice: It's not a new problem. 17:25:28 cmurf, really... 17:25:33 then keep tit 17:25:45 charming 17:26:50 thanks for coming, folks 17:26:51 #endmeeting