#opnfv-meeting: INFRA working group

Meeting started by uli-k at 04:31:47 UTC (full logs).

Meeting summary

    1. Bryan Sullivan (bryan_att, 04:31:54)

  2. roll call (uli-k, 04:31:56)
    1. thaj (thaj, 04:32:01)
    2. Jack Morgan (jmorgan1, 04:32:03)
    3. meimei (May-meimei, 04:32:11)
    4. add two things to agenda: (uli-k, 04:34:20)
    5. Daniel Smith (migrating but listening :) ) (DanSmithEricsson, 04:34:20)
    6. vPOD assignments (uli-k, 04:34:40)
    7. Jingbo Hao (Kingpoo, 04:34:42)
    8. update on common config files (uli-k, 04:34:53)
    9. Helen Yao (HelenYao, 04:35:06)

  3. vPOD assignment requests (uli-k, 04:35:47)
    1. Netready, Opera, Domino requested vPOD (uli-k, 04:36:55)
    2. Dan explains he provides vPODs usually for three weeks and then releases. (uli-k, 04:40:00)
    3. we offer Ericsson vPOD to Netready and Huawei vPODs to domino and to Opera. (uli-k, 04:42:43)

  4. static tests (uli-k, 04:42:56)
    1. https://wiki.opnfv.org/display/security/Security+Scanning (May-meimei, 04:43:57)
    2. May-meimei and Haojingbo explain we have some tools already in community (uli-k, 04:46:19)
    3. proposal to have a list of scanning tools on wiki (uli-k, 04:47:03)
    4. question: is security-scanning the right place? (uli-k, 04:48:19)
    5. question: should we also scan the test infrastructure and CI environment? (uli-k, 04:49:35)
    6. AGREED: to start a discussion with security-scanning team (uli-k, 04:50:33)
    7. 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 (bryan_att, 04:50:34)
    8. 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 (bryan_att, 04:51:36)
    9. suggestion to add basic info on the tools to the wiki, e.g. which errors can be found. (uli-k, 04:51:39)
    10. https://build.opnfv.org/ci/job/opnfv-lint-verify-master/ (May-meimei, 04:51:40)
    11. https://gerrit.opnfv.org/gerrit/#/c/24615/ (May-meimei, 04:52:08)
    12. the question is whether we have security scanning as a job in the jenkins process (bryan_att, 04:52:14)
    13. we collect more information and then go forward here. (uli-k, 04:55:21)
    14. 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) (bryan_att, 04:55:36)

  5. Requirements by Dovetail on infrastructure (uli-k, 04:55:56)
    1. re Pharos spec, the question is whether a SUT should mimic the Pharos spec or more generally follow the "spirit" of the pharos spec (bryan_att, 05:02:52)
    2. Jack recommends that Dovetail work with the Infra team to define the questions more clearly (bryan_att, 05:04:52)
    3. OPNFV compliancy will probably not require to run on a Pharos-compliant lab. (uli-k, 05:07:14)
    4. Dovetail currently doesn't need to be integrated in some way to CI (uli-k, 05:09:32)
    5. 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. (uli-k, 05:11:09)
    6. ACTION: wenjing to schedule dovetail discussion on hackfest (uli-k, 05:12:12)

  6. common config filest (uli-k, 05:12:25)
    1. 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...) (bryan_att, 05:15:24)
    2. the goal is for tests to avoid having to guess this info from the environment (bryan_att, 05:16:07)
    3. 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) (bryan_att, 05:17:01)
    4. 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) (bryan_att, 05:18:40)
    5. we need to distinguish which information should go into POD descriptor versus scenario descriptor or be dynamically created info (uli-k, 05:23:10)
    6. POD descriptor should describe the reality - what is there in the POD (uli-k, 05:23:30)
    7. scenario descriptor should describe what the installer has to do (deploy and configure during deployment) (uli-k, 05:23:59)
    8. additionally the installer needs to provide some information of the deployment to the user. This information will change for every deployment (uli-k, 05:24:51)

  7. aob: feedback on meeting time (uli-k, 05:27:14)
    1. participants appreciate some way of rotating (uli-k, 05:28:21)
    2. 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) (bryan_att, 05:28:54)
    3. we don't have any participation from eastcoast today (uli-k, 05:29:40)
    4. I'm good with rotating the schedule (bryan_att, 05:30:06)
    5. AGREED: fdegir, jmorgan1 and uli-k will observe this for some time to develop the best way (uli-k, 05:31:45)
    6. bryan_att recommends again to put as much as possible into the IRC (uli-k, 05:33:14)


Meeting ended at 05:34:12 UTC (full logs).

Action items

  1. wenjing to schedule dovetail discussion on hackfest


People present (lines said)

  1. uli-k (35)
  2. bryan_att (15)
  3. DanSmithEricsson (6)
  4. jmorgan1 (6)
  5. May-meimei (5)
  6. collabot` (4)
  7. Kingpoo (2)
  8. HelenYao (1)
  9. thaj (1)


Generated by MeetBot 0.1.4.