16:02:53 #startmeeting Infra WG Meeting 16:02:53 Meeting started Mon Dec 18 16:02:53 2017 UTC. The chair is fdegir. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:02:53 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:02:53 The meeting name has been set to 'infra_wg_meeting' 16:03:50 #topic Roll Call 16:04:15 #info Joe Kidder 16:04:16 #info Aric Gardner 16:04:30 #info David McBride 16:04:31 #info Fatih Degirmenci 16:04:45 #info Tianwei Wu 16:04:56 #link Agenda - https://wiki.opnfv.org/display/INF/Infra+Working+Group 16:06:21 #topic Release Critiera 16:09:13 #info David spoke with OpenStack Release project about topic - they use CI to judge if something needs to be release or not 16:10:02 in order for basic promotion to work, we must ensure when we test scenarios, we only change the scenario 16:10:26 and keep everything else frozen 16:10:45 feel free to info comments 16:10:54 #info In order for basic promotion to work, we must ensure when we test scenarios, we only change the scenario 16:11:10 #info Meaning that everything else should be frozen; test fw/cases, infra, etc 16:11:31 #info Apart from this, we need a way to find out which scenario is impacted by certain change in order to run test that scenario 16:11:48 #info CI Evolution was proposed/approved long before XCI was even created 16:12:15 #info And due to us failing to make CI Evolution real, we started XCI to show that that's the way 16:13:17 #info A basic schemet could be 16:13:30 #info - patchset verification: healthcheck 16:13:41 #info - post merge: smoke (?) 16:13:49 #info - daily: functest + yardstick 16:14:02 #info - weekly: performance/stress/etc. 16:14:23 #info Each of these stages promoting scenarios to the next one or demoting 16:15:11 #info Test WG should come up with the scope for the test loops; what tests should be used where 16:16:11 #info Promotion is not only for scenarios; test projects should also have promotion to enable certain test cases that are used for testing scenarios 16:16:50 #topic Pharos Spec refresh 16:17:01 fdegir: what do you mean by "what tests should be used where" 16:17:25 do you mean daily, weekly tests, etc? 16:17:42 dmcbride: like is is sufficient to run smoke test as part of post merge to promote a scenario to daily/baremetal runs? 16:18:46 dmcbride: similar thing is valid for daily/weekly as well 16:19:10 #link Pharos Spec etherpad - https://etherpad.opnfv.org/p/Pharos_Specification2.0 16:23:29 #topic POD allocation to installers 16:23:37 #info Compass: https://build.opnfv.org/ci/label/compass-baremetal/ 16:23:47 #info Fuel: https://build.opnfv.org/ci/label/fuel-baremetal/ 16:23:56 #info Joid: https://build.opnfv.org/ci/label/joid-baremetal/ 16:24:05 #info Daisy: https://build.opnfv.org/ci/label/daisy-baremetal/ 16:24:27 #info Apex: https://build.opnfv.org/ci/label/apex-baremetal-master/ and https://build.opnfv.org/ci/label/apex-baremetal-euphrates/ 16:25:00 #info MCP/Fuel 16:25:23 #info Armband: https://build.opnfv.org/ci/label/armband-baremetal/ 16:26:42 #info huawei-pod12 will connect jenkins this week 16:29:17 well, I still don't believe adding more resources will solve much 16:30:45 #info each installer has two CI POD except Compass which has three and Fuel which has two POD per arch 16:31:54 #info discussion on patch - https://gerrit.opnfv.org/gerrit/#/c/48755 16:33:30 the reason we have this "light" process to approve resources as CI resources to ensure they don't go down & up unnecessarily 16:33:52 and once a resource is approved as CI project, adding the permission to push results to test DB should be done by Test WG 16:34:09 #info who owns making sure a CI POD is listed in the test DB? 16:34:12 cause they have better visibility with regards to if the tests are producing good results 16:34:26 I mean, the failures are not related to the resources themselves 16:35:54 #info once a resource is approved as CI project, adding the permission to push results to test DB should be done by Test WG 16:36:47 #action bramwelt will work on documenting the process for future releases 16:37:43 I think when we have the "dynamic allocaiton" then the responsibility goes to Infra WG + lab owners 16:37:51 to ensure we always have enough capacity 16:38:06 but until that happens, we just do preliminary checks and installers need to ensure pod stays as it is 16:38:24 #topic JIRA issues 16:39:20 Nokia POD is allocated for long duration test 16:39:51 will look 16:40:56 #info INFRA-195 request for StorPerf POD - looking for baremetal POD 16:42:00 #info will look at this after the holidays to help StorPerf project find hardware resources 16:43:00 #topic Converting INFO files to yaml 16:43:27 #link https://gerrit.opnfv.org/gerrit/#/c/48413/ 16:44:18 LGTM; I'm waiting for LF Releng to come to a conclusion first 16:46:29 #action bramwelt to work with LF Releng to resolve this discussion 16:58:45 #topic Pharos dashboard - INFRA-149 16:59:09 #info bramwelt suggests use Jenkins as the default 17:00:31 #info jmorgan1 thinks that if Jenkins is used then Jenkins needs to be better monitored for accuracy 17:01:47 jmorgan1: promotion https://hastebin.com/nisosogawa.pl 17:02:03 #info Reminder that we won't be meeting next two weeks and next meeting is January 9th 17:02:03 Merry Christmas! 17:02:24 #undo 17:02:35 #info Reminder that we won't be meeting next two weeks and next meeting is January 8th 17:02:49 #endmeeting 17:03:26 #endmeeting