04:31:47 <uli-k> #startmeeting INFRA working group
04:31:47 <collabot`> 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 <collabot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
04:31:47 <collabot`> The meeting name has been set to 'infra_working_group'
04:31:54 <bryan_att> #info Bryan Sullivan
04:31:56 <uli-k> #topic roll call
04:32:01 <thaj> #info thaj
04:32:03 <jmorgan1> #info Jack Morgan
04:32:11 <May-meimei> #info meimei
04:33:47 <bryan_att> maybe a short update on  progress on the common config files?
04:34:20 <uli-k> #info add two things to agenda:
04:34:20 <DanSmithEricsson> #info Daniel Smith (migrating but listening :) )
04:34:31 <uli-k> vPOD assignments for 3 projects
04:34:40 <uli-k> #info vPOD assignments
04:34:42 <Kingpoo> #info Jingbo Hao
04:34:53 <uli-k> #info update on common config files
04:35:06 <HelenYao> #info Helen Yao
04:35:23 <May-meimei> sorry ,i can't access to gtm , jingbo will proxy forme
04:35:34 <jmorgan1> sounds good
04:35:47 <uli-k> #topic vPOD assignment requests
04:36:55 <uli-k> #info Netready, Opera, Domino requested vPOD
04:37:08 <DanSmithEricsson> hey Uli.. the Gluon one i spoke with Georg
04:37:10 <DanSmithEricsson> and can provide
04:37:18 <DanSmithEricsson> sorry.. Netready
04:37:37 <jmorgan1> ok, how about Joid for full POD
04:40:00 <uli-k> #info Dan explains he provides vPODs usually for three weeks and then releases.
04:40:05 <uli-k> #chair jmorgan1
04:40:05 <collabot`> Current chairs: jmorgan1 uli-k
04:42:11 <DanSmithEricsson> sounds good!
04:42:13 <DanSmithEricsson> agree
04:42:43 <uli-k> #info we offer Ericsson vPOD to Netready and Huawei vPODs to domino and to Opera.
04:42:56 <uli-k> #topic static tests
04:43:57 <May-meimei> https://wiki.opnfv.org/display/security/Security+Scanning
04:46:19 <uli-k> #info May-meimei  and Haojingbo explain we have some tools already in community
04:47:03 <uli-k> #info proposal to have a list of scanning tools on wiki
04:47:20 <Kingpoo> now we have flake8 in 5 projects
04:48:19 <uli-k> #info question: is security-scanning the right place?
04:49:35 <uli-k> #info question: should we also scan the test infrastructure and CI environment?
04:50:33 <uli-k> #agree to start a discussion with security-scanning team
04:50:34 <bryan_att> #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 <bryan_att> #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 <uli-k> #info suggestion to add basic info on the tools to the wiki, e.g. which errors can be found.
04:51:40 <May-meimei> https://build.opnfv.org/ci/job/opnfv-lint-verify-master/
04:52:08 <May-meimei> https://gerrit.opnfv.org/gerrit/#/c/24615/
04:52:14 <bryan_att> #info the question is whether we have security scanning as a job in the jenkins process
04:55:21 <uli-k> #info we collect more information and then go forward here.
04:55:36 <bryan_att> #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 <uli-k> #topic Requirements by Dovetail on infrastructure
05:02:52 <bryan_att> #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 <bryan_att> #info Jack recommends that Dovetail work with the Infra team to define the questions more clearly
05:07:14 <uli-k> #info OPNFV compliancy will probably not require to run on a Pharos-compliant lab.
05:09:32 <uli-k> #info Dovetail currently doesn't need to be integrated in some way to CI
05:11:09 <uli-k> #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 <jmorgan1> please schedule some time to discuss at Plugfest
05:11:46 <jmorgan1> uli-k: give wenjing the action to schedule ;)
05:12:12 <uli-k> #action wenjing to schedule dovetail discussion on hackfest
05:12:25 <uli-k> #topic common config filest
05:13:26 <bryan_att> 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 <bryan_att> #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 <bryan_att> #info the goal is for tests to avoid having to guess this info from the environment
05:17:01 <bryan_att> #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 <bryan_att> #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 <uli-k> #info we need to distinguish which information should go into POD descriptor versus scenario descriptor or be dynamically created info
05:23:30 <uli-k> #info POD descriptor should describe the reality - what is there in the POD
05:23:59 <uli-k> #info scenario descriptor should describe what the installer has to do (deploy and configure during deployment)
05:24:51 <uli-k> #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 <uli-k> #topic aob: feedback on meeting time
05:28:21 <uli-k> #info participants appreciate some way of rotating
05:28:54 <bryan_att> #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 <uli-k> #info we don't have any participation from eastcoast today
05:30:06 <bryan_att> #info I'm good with rotating the schedule
05:31:45 <uli-k> #agree fdegir, jmorgan1 and uli-k will observe this for some time to develop the best way
05:33:14 <uli-k> #info bryan_att recommends again to put as much as possible into the IRC
05:33:16 <jmorgan1> soudns good
05:34:12 <uli-k> #endmeeting