17:01:27 #startmeeting ironic_qa 17:01:28 Meeting started Wed May 25 17:01:27 2016 UTC and is due to finish in 60 minutes. The chair is krtaylor. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:29 geguileo: debug is fine I guess. Not much real difference 17:01:30 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:32 The meeting name has been set to 'ironic_qa' 17:01:42 o/ 17:01:43 o/ 17:01:46 o/ 17:02:12 o/ 17:02:17 o/ 17:02:25 hi everyone, I'm hosting this week, jlvillal is away 17:02:42 hey krtaylor :) 17:02:46 As always the agenda is at: https://wiki.openstack.org/wiki/Meetings/Ironic-QA 17:02:49 hi mjturek1 17:02:59 its a pretty light agenda this week 17:03:20 #topic Announcements 17:03:33 so any announcement this week? 17:03:40 krtaylor, may I give a Info? 17:03:45 one announcement from me - we now have tests for microversions in tempest - https://review.openstack.org/#/c/260358/ 17:04:05 watanabe_isao, sure, you have the floor 17:04:14 vdrok, excellent! 17:04:15 #Info Fujitsu iRMC CI gave its first test result to Ironic, yesterday (5/25). Currently the CI is not so stable due to some intra network issue. And we set it to non-voting for now. We will try our best to fix the issue, and start to vote ASAP. 17:04:56 watanabe_isao, it should be non-voting for a while, until it proved to be robust 17:05:08 but thats good news! 17:05:12 great work watanabe_isao! 17:05:17 \o/ 17:05:31 krtaylor, sure. 17:05:37 rloo, thank you. 17:05:56 ok, any other announcements? 17:06:17 #topic Grenade 17:06:28 great progress this week! 17:06:50 #link https://etherpad.openstack.org/p/ironic-newton-grenade-whiteboard 17:07:29 anyone want to make any comments or raise any topics on grenade? 17:07:44 just that we need reviews, sounds like things are passing just fine :) 17:07:55 patches are on the etherpad there 17:08:04 yep, looks like 8 patch sets are left 17:08:08 awesome 17:08:14 * devananda sneaks in the back, catches up 17:08:40 morning devananda ! :) 17:09:11 anything else? 17:09:32 #topic Functional testing 17:09:48 I'm not aware of any progress here, anyone? 17:10:01 * jroll hasn't heard anything 17:10:09 sorry can i ask a dumb question about grenade tests. 17:10:25 once those patches are *in*, we have grenade tests working, right? 17:10:32 then do we add more tests to grenade? 17:10:59 rloo: yep, grenade is pretty stable, grenade partial is not atm 17:11:09 and I think we don't add tests to grenade 17:11:14 it just runs smoke 17:11:35 vdrok: ok, so next thing is to get grenade partial working? 17:11:43 maybe we'll add something in resorce_create and resource_verify, but dunno 17:11:47 well, I'd like to make sure smoke covers everything we care about, e.g. rebuild 17:11:49 vdrok: I mean, after you party and take a break :) 17:12:08 but yes, the next would be grenade partial working. which implies getting rolling upgrades working. :) 17:12:16 (well, and making grenade a voting job, ofc) 17:12:22 rloo: yes, it mostly works, I guess the reason it's unstable is concurrency 2 17:12:33 ok, just want to make sure there is a list of things-to-do 17:13:28 cool 17:13:31 shall we move on? 17:13:35 ok, so I think we are past functional 17:13:36 jroll: isn't partial just cold upgrading ironic ironic without everything else? 17:13:40 what are the chances we'll get grenade testing on some of hte current stable branches? 17:13:55 vdrok: there are two forms of partial upgrade that I think we need to cover 17:14:01 1. upgrade some ironic services 17:14:09 vdrok: it's making sure new ironic-conductor works with old ironic-api, which is the basis for rolling upgrades 17:14:11 2. upgrade some openstack services but not others 17:14:29 devananda: (2) is completely different, and something we should work on, but as a separate task 17:14:31 (imo) 17:14:35 lets jump back to this topic in the open discussion 17:14:39 jroll: agreed. but it's also a "partial upgrade" 17:14:43 krtaylor: sure, sorry 17:14:49 krtaylor: +1 17:14:49 aha, the reason I ask is I saw it passing a couple of times :) 17:15:17 #topic 3rd party CI 17:15:39 * jroll is excited about this topic 17:15:43 I just sent an email for more eyes on the status of the teams 17:15:51 in the driver wiki 17:15:54 * rloo likes to see jroll excited 17:15:59 <[1]cdearborn> o/ 17:16:24 krtaylor, do I need to provide any Info (of iRMC CI) to you to update the driver wiki? 17:16:25 I have talked to a few teams and made a couple of changes, but I doubt it is complete 17:16:46 so I see CI systems that say they're reporting on every patch, that are not reporting on every patch 17:16:56 e.g. irmc just started reporting today, I don't think that's enough data 17:17:04 watanabe_isao, yes, please review the ironic/driver page 17:17:10 oneview reports on patches touching ironic/drivers/ only, apparently 17:17:19 krtaylor, sure sir. 17:17:20 #link https://wiki.openstack.org/wiki/Ironic/Drivers 17:17:43 jroll, I don't doubt it 17:17:43 cisco must also be filtering based on file, I don't see it on e.g. https://review.openstack.org/#/c/318497/ 17:17:44 jroll: I believe that is hardware capacity issues combinded with providing timely feedback 17:17:47 true, I talked about it on the Summit with some people. We just don't have enough hardware to run on every patch 17:18:21 jroll, I'd like to get this table sanity checked for sure 17:18:26 well, those systems need to get there IMO 17:18:29 from the spec: "It runs the expected tests for every patch set that is not excluded. Reasons for this exclusion will be documented and approved by the ironic team." 17:18:54 I don't remember seeing any exclusions documented, let alone approving them 17:19:16 yes, and we also said that it didn't have to be in the 4 hour window to start 17:19:27 yep 17:19:32 the spec also says "unless that change is to code or documentation that can not impact the driver" 17:19:39 certainly ironic/utils/ can impact drivers 17:19:43 almost certainly* 17:19:55 4hrs is the recommended time to turn around a comment 17:20:08 well, 8 hours in Newton, 4 in Ocata 17:20:18 Maybe we should relax this requirement? Ironic testing requires hardware... 17:20:19 ironic patches usually don't come in so fast to make that a problem :) 17:20:33 right, there aren't a lot of patches 17:20:40 this was a known caveat when we introduced it 17:20:53 vendors said it would be fine, given the estimates on number of patches 17:21:20 exactly, lets see commenting and if it is past 8hrs evaluate then 17:21:33 +1 17:21:33 I'm trying to reduce our testing time, but yesterday I was with 18 patches on my queue at some point... 17:21:51 with the addition that I expect every patch running in CI 17:21:55 some of the large patch sets that get rebased periodically might be affecting this right now 17:21:57 or rather, following the rules upstream CI does 17:21:58 eg, the network integration 17:22:29 jroll: what was the estimated # of patches per day mentioned at the summit? do you recall? 17:22:37 I don't think teams should just give up, run through the queue and see how long it takes 17:22:37 sure, we won't panic if some CI can't handle the load of a large series being uploaded 17:22:40 I don't, sorry 17:22:48 I think it was 30 17:22:57 * krtaylor looks at his notes 17:23:14 this is the exclusion list for upstream CI https://github.com/openstack-infra/project-config/blob/master/zuul/layout.yaml#L971-L979 17:23:14 yesterday, there were 45 patches for 24 hours. 17:23:28 that's 30 revisions to patches. 17:23:42 but that is abnormal 17:24:42 jroll: that exclusion list seems fine for 3rd party too, IMO 17:24:51 devananda: yep, that's my thought 17:25:33 agreed 17:25:58 so yeah, just wanted to point out the requirements, and that there are CIs that say they fulfill the requirement but don't in reality 17:26:07 well, I'll be happy to correct info on the wiki status table, but I probably shouldn't be the one policing it 17:26:19 krtaylor: yeah, I'm happy to fix it too 17:26:25 Agreed, thiagop, any chance you can update your filter to match the above link of sorts, excluding the other vendor drivers so we can see how long repsonses are in? 17:26:37 krtaylor: just curious where the "reports on everything" came from :) 17:26:39 jroll, thanks! 17:26:45 jroll: have we stated an expectation that 3rdparty CI test other projects in the ironic group? 17:27:01 devananda: we have not, and I don't expect to need that 17:27:12 jroll, like I said at summit, most of the info was from either the etherpad, infra account info, etc 17:27:13 eg, ironic-lib 17:27:23 devananda: perhaps make it optional if they're concerned about it breaking 17:27:26 TheJulia: I can, yes 17:27:35 devananda: we have depends-on if we as developers think a patch may be problematic 17:27:46 thiagop: That would be awesome :) 17:28:14 TheJulia: but the average time for builds on the current CI is 80min 17:28:51 TheJulia: on the new CI, using nodepool, I dropped it to 36min so far 17:28:55 O_o 17:29:01 ah, that sounds better 17:29:06 oh that does sound far better 17:29:17 thiagop: nice! 17:29:33 but it's not stable yet... 17:29:48 working on it today/tomorrow 17:29:57 * krtaylor needs to see if the CI dashboard will show some historical info to make a determination which teams really have CI 17:30:06 what was the old CI using, just curious? 17:30:36 jroll: it was building devstack on a KVM in a custom script 17:30:44 ah 17:30:49 nodepool caching really REALLY helps to cut time 17:30:54 yep 17:31:32 thiagop, mmedvede from my team has some really good optimization experience 17:32:21 so did we get to a conclusion on CI topics? 17:32:21 krtaylor: I'll talk to him/her as soon as my tests are passing. Thanks! 17:32:51 thiagop, sure np, he now runs the third party CI working group meetings 17:33:02 well, conclusions I've seen: 1) follow the guidelines, 2) myself or kurt need to update the wiki thing 17:33:03 if most vendors have same issues wrt optimization, would it help to have some documentation about best practise or whatever? 17:33:20 thiagop, what CI cloud are you using for your nodepool, please? KVM? 17:33:44 rloo, I don't see why not, that makes sense 17:34:23 mjturek1, ^^^ 17:35:03 I think that is an area that we can share our experience and at least start docs for ironic CI 17:35:25 ++ 17:35:29 so lets move on 17:35:34 watanabe_isao: the nodepool is in our internal cloud of the lab 17:35:45 #topic General QA 17:35:49 krtaylor: sure thing 17:35:56 other topics? 17:36:15 * krtaylor thinks we should combine general and open topics in future meetings 17:36:22 +1 17:36:32 +1 17:36:52 well then, lets open the floor to open discussion 17:36:53 so remind me, what's the purpose of https://wiki.openstack.org/wiki/Ironic/Drivers 17:37:05 #topic Open Discussion 17:37:07 vs the marketplace one vs there is some other list of drivers 17:37:24 rloo, not much, and the info there is old 17:37:28 rloo: some of the historical data on the wiki should, IMO, be removed 17:37:46 * jroll doesn't like wikis either 17:37:50 rloo, I was using it as a place to create a table (because no etherpad tables) 17:37:55 so let's decide/describe what is in each page, so we don't duplicate and whatever. 17:38:11 or eliminate some maybe :) 17:38:19 krtaylor: the last table on the wiki looks like where you're tracking that status, yes? 17:38:20 but that is true for a lot of our wiki sub pages 17:38:22 consolidate information... 17:38:34 devananda, yes 17:38:59 wiki cleanup - maybe a good workday kinda activity 17:39:26 let's remove the rest of the data on that page, replacing with a link to stackalytics drivers page and some info on process to update it ? 17:39:27 krtaylor: even after cleaning up the wiki, is the wiki meant to be kept up-to-date, and if so, who keeps it up-to-date? 17:39:54 devananda, I'd second that 17:40:05 or do as devananda suggests ) 17:40:06 devananda, that info is next to the table too 17:40:11 and at the end of Newton, let's remove that table, too 17:40:21 yes 17:40:30 then just CI docs 17:40:49 then we get a gerrit trail for changes 17:41:00 and reviews, etc 17:41:01 yup 17:41:25 yay peer review 17:41:48 so, do we need to revisit grenade/rolling upgrades discussion? 17:41:59 I'd be in favor of basically ceasing to use the wiki as much as possible, especially for documentation 17:42:09 devananda: ++ 17:42:19 ++ 17:42:30 for tracking things like krtaylor has been doing, it's a little better than an etherpad, but not much 17:42:58 krtaylor: would you like to do the honors of trimming that page down? :) 17:43:08 there is a table plugin for etherpads :) 17:43:16 krtaylor: there is?! 17:43:22 devananda, sure and yes 17:43:45 we use the etherpad table plugin internally 17:43:55 mmmmmm. I need to find that ... 17:43:58 anyway :) 17:44:00 hm, maybe an upgrade to infro etherpad is in order 17:44:02 rolling upgrades 17:44:37 jroll: we've talked about the different combinatorial sets of upgrade testing we want, eg. in the summit 'pad 17:44:38 lol 17:44:47 mhm 17:46:01 I think it'd be helpfu, when folks say 'partial upgrades', to specify which one 17:46:33 well, so grenade-partial has historically always meant "partial upgrade of the service under test" 17:47:02 so I prefer to keep that meaning 17:47:07 fair 'nuf 17:47:20 no projects in openstack currently test "full upgrade of a single service in the cloud" 17:47:45 I'm pretty sure I recall that, when ironic was going through graduation process, we were required to have an "upgrade ironic before nova" test 17:47:49 so I'm not really concerned with testing that (yet) 17:47:49 so we did, at one point 17:48:12 interesting 17:48:19 I'd be curious if nova folks still care about that 17:48:22 thus my ongoing confusion when folks talk about it as though it never was 17:48:26 me too :) 17:48:53 I don't remember that fwiw 17:49:25 i'll dig around for a second ... 17:49:37 devananda: if we had that test, what happened to it? 17:50:03 devananda: or do you mean, they wanted that test, but we didn't get it done. is that what nova keeps asking us for? 17:50:04 rloo: if it's grenade-partial-ironic, then it sat not working for the last two years 17:50:17 nova keeps asking us for tempest-full 17:50:21 (as they should) 17:50:48 ironic is a teenager :D 17:50:57 hehheh 17:51:17 jroll: https://review.openstack.org/#/c/111859/ 17:51:31 jroll: yea, grenade-sideways 17:51:41 devananda: oh, that, that was for the migration from nova-bm though 17:51:54 right 17:51:57 so it was :) 17:52:26 Ah. so we never had that after the nova-bm migration 17:52:48 never mind then :) 17:52:53 right, that was a one time thing 17:53:39 so idk, I think ironic vN with nova vN-1 is a good thing to test, but let's take one thing at a time and get rolling upgrades working 17:53:48 I *think* that will actually test that, too 17:53:48 jroll: agreed 17:53:56 well, not quite, meh 17:54:05 so it would be good if someone would write down what grenade-partial means/types of tests it will include, etc. 17:54:09 we could add a "finish the ironic upgrade" step 17:54:17 jroll: ++ 17:54:20 rloo: it will be ==grenade, but only upgrade ironic-conductor 17:54:59 QA folks, is there documentation somewhere about the types of tests that ironic has? 17:55:29 no that I'm aware of 17:55:40 * krtaylor scribbles down a note 17:56:29 ok, feels like this is winding down, maybe we continue this in -ironic? 17:56:59 wfm 17:57:13 anything else? 17:57:30 Thanks everyone 17:57:40 thx krtaylor 17:57:49 #endmeeting