04:31:47 #startmeeting INFRA working group 04:31:47 Meeting started Wed Nov 23 04:31:47 2016 UTC. The chair is uli-k. Information about MeetBot at http://wiki.debian.org/MeetBot. 04:31:47 Useful Commands: #action #agreed #help #info #idea #link #topic. 04:31:47 The meeting name has been set to 'infra_working_group' 04:31:54 #info Bryan Sullivan 04:31:56 #topic roll call 04:32:01 #info thaj 04:32:03 #info Jack Morgan 04:32:11 #info meimei 04:33:47 maybe a short update on progress on the common config files? 04:34:20 #info add two things to agenda: 04:34:20 #info Daniel Smith (migrating but listening :) ) 04:34:31 vPOD assignments for 3 projects 04:34:40 #info vPOD assignments 04:34:42 #info Jingbo Hao 04:34:53 #info update on common config files 04:35:06 #info Helen Yao 04:35:23 sorry ,i can't access to gtm , jingbo will proxy forme 04:35:34 sounds good 04:35:47 #topic vPOD assignment requests 04:36:55 #info Netready, Opera, Domino requested vPOD 04:37:08 hey Uli.. the Gluon one i spoke with Georg 04:37:10 and can provide 04:37:18 sorry.. Netready 04:37:37 ok, how about Joid for full POD 04:40:00 #info Dan explains he provides vPODs usually for three weeks and then releases. 04:40:05 #chair jmorgan1 04:40:05 Current chairs: jmorgan1 uli-k 04:42:11 sounds good! 04:42:13 agree 04:42:43 #info we offer Ericsson vPOD to Netready and Huawei vPODs to domino and to Opera. 04:42:56 #topic static tests 04:43:57 https://wiki.opnfv.org/display/security/Security+Scanning 04:46:19 #info May-meimei and Haojingbo explain we have some tools already in community 04:47:03 #info proposal to have a list of scanning tools on wiki 04:47:20 now we have flake8 in 5 projects 04:48:19 #info question: is security-scanning the right place? 04:49:35 #info question: should we also scan the test infrastructure and CI environment? 04:50:33 #agree to start a discussion with security-scanning team 04:50:34 #info I am unclear if the request was to add these additional tools to the security scanning program generally, or specifically to the infra environment for OPNFV, eg as part of the normal CI process 04:51:36 #info in the CI process these tools might provide additional info on vulnerabilities that exist in the system as being tested in CI, so that was my sense of the suggestion 04:51:39 #info suggestion to add basic info on the tools to the wiki, e.g. which errors can be found. 04:51:40 https://build.opnfv.org/ci/job/opnfv-lint-verify-master/ 04:52:08 https://gerrit.opnfv.org/gerrit/#/c/24615/ 04:52:14 #info the question is whether we have security scanning as a job in the jenkins process 04:55:21 #info we collect more information and then go forward here. 04:55:36 #info I think adding/expanding security scanning as a process in CI is a good goal, given that it adds value (e.g. finds some issues, which should be expected especially in the early stages of use, and later helps us track when those issues are resolved) 04:55:56 #topic Requirements by Dovetail on infrastructure 05:02:52 #info re Pharos spec, the question is whether a SUT should mimic the Pharos spec or more generally follow the "spirit" of the pharos spec 05:04:52 #info Jack recommends that Dovetail work with the Infra team to define the questions more clearly 05:07:14 #info OPNFV compliancy will probably not require to run on a Pharos-compliant lab. 05:09:32 #info Dovetail currently doesn't need to be integrated in some way to CI 05:11:09 #info Since dovetail will create the compliancy tests later than the OPNFV code is developed, an integration of dovetail tests to ci jobs is probably currently not necessary. 05:11:18 please schedule some time to discuss at Plugfest 05:11:46 uli-k: give wenjing the action to schedule ;) 05:12:12 #action wenjing to schedule dovetail discussion on hackfest 05:12:25 #topic common config filest 05:13:26 maybe add a link to the gerrit issue related to this? or a wiki page? for those not familiar with the goal 05:15:24 #info does this plan include also the deployed config of the OPNFV scenario, e.g. the admin-openrc.sh file (a common place and core variable set), OpenStack config settings (external network name, region name, project names, etc...) 05:16:07 #info the goal is for tests to avoid having to guess this info from the environment 05:17:01 #info there is a difference between the "intent" (how things should be built) vs the end-state (how things *were* built including any options for the settings of the VIM installations) 05:18:40 #info but in the end we need (1) easily discoverable, common settings for the install (intended and as executed); (2) to be able to specify how we want the configuration (hardware and software settings) 05:23:10 #info we need to distinguish which information should go into POD descriptor versus scenario descriptor or be dynamically created info 05:23:30 #info POD descriptor should describe the reality - what is there in the POD 05:23:59 #info scenario descriptor should describe what the installer has to do (deploy and configure during deployment) 05:24:51 #info additionally the installer needs to provide some information of the deployment to the user. This information will change for every deployment 05:27:14 #topic aob: feedback on meeting time 05:28:21 #info participants appreciate some way of rotating 05:28:54 #info makes sense to me; there are three things - the pod descriptor (actual hardware information); scenario use intent for the hardware and software settings (e.g. which NICs have which role, or the intended VIM settings); as-deployed state (including additonal VIM settings that were decided by the installer or unspecified in the scenario file) 05:29:40 #info we don't have any participation from eastcoast today 05:30:06 #info I'm good with rotating the schedule 05:31:45 #agree fdegir, jmorgan1 and uli-k will observe this for some time to develop the best way 05:33:14 #info bryan_att recommends again to put as much as possible into the IRC 05:33:16 soudns good 05:34:12 #endmeeting