08:30:46 #startmeeting yardstick work meeting 08:30:46 Meeting started Mon Jul 10 08:30:46 2017 UTC. The chair is rbbratta. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:30:46 Useful Commands: #action #agreed #help #info #idea #link #topic. 08:30:46 The meeting name has been set to 'yardstick_work_meeting' 08:30:54 #topic roll call 08:31:10 info Abhijit 08:31:10 #info Ross 08:31:12 #info Rex 08:31:12 #info deepak 08:31:13 #info Jing Lu 08:31:19 #info kubi 08:31:34 #info Jack 08:31:47 #info Kanglin 08:31:53 #topic action item follow up 08:31:55 #info Abhijit 08:32:47 #info AP1 Danube 3.0 tag can't be delete, have to move to Danube 3.1 08:33:31 #info AP2 https://gerrit.opnfv.org/gerrit/#/c/36507/ was merged, don't think we root causes Jenkins coverage problems 08:34:08 any other action item follow ups? 08:34:45 rbbratta: I wonder how we will named our docker image for Danube 3.0 08:35:03 danube3.1 I assume 08:35:31 was there an email about that 08:35:34 rbbratta: that would be aligned with repo 08:36:18 okay, found the email thread 08:36:47 Jing_ already tagged yardstick docker 3.0 08:36:51 two solution for that 08:36:51 1. repo 3.1 docker image 3.1 08:36:51 2. repo 3.1 docker image 3.0 08:37:36 do other projects expect danube 3.0, dovetal, bottlenecks, etc? 08:37:56 or do they just pull latest stable 08:39:04 dovetail pull danbue 3.0 for CVP.0.2.0 08:39:35 Bottlenecks pull the latest 08:40:39 okay, so dovetail would have to be updated to pull danube 3.1, so we should just use danube 3.0 08:41:43 both would be Ok, they can easily to move to Danube 3.1 , It depends on what we like 08:42:17 it would be more consistent and accurate to use danube 3.1 08:43:03 Dovetail team will tag new version for each weeks for beta version, eg.CVP.0.3.0 and CVP.0.4.0 08:43:51 that would not a big deal for them. we can just focus on the best way for us 08:44:00 3.1 is fine as long as we make it clear in the release note 08:44:30 okay, so we are agreed. use danube 3.1 and notify dovetail team 08:45:17 OK 08:45:32 and we have to fix the release notes 08:45:38 yep 08:45:50 #agreed use danube3.1 for docker tag to make danube3.1 git tag 08:46:08 danube.3.1 08:46:47 for docker, yes danube.3.1 08:47:11 for git as well. 08:47:35 #agree use danube.3.1 for git and docker tag 08:48:57 there we some older action items about VES and moving the APAC timeslot 08:49:52 rbbratta: do you mean VES agent? 08:49:57 collectd 08:50:08 kubi001: yes, VES agent for collectd 08:50:17 got it 08:50:27 if we should adopt VES output format 08:50:56 I'll add it again, and try to have something for next meeting 08:51:04 #action Ross find out more details about VES agent and ask Bryan for slides 08:51:23 thanks 08:51:43 I'm fine with the current APAC timeslot, I assume everyone else is okay with the current time. 08:52:39 deepaks: sure for me, how about deepaks? 08:54:25 ok for me 08:54:31 the time slot is good. 08:54:37 ok for me. 08:54:39 well if we moved it earlier it would effect Europe more, so I think the current time is okay. 08:55:03 yes this time slot is ok 08:55:31 okay, next topic 08:56:01 #topic release branches and offline support 08:56:32 I saw we are now cloning storperf in the Dockerfile 08:56:46 yes 08:56:46 so we have to manage yardstick, releng, and storperf branches when cloning 08:57:29 but releng hasn't implemented a stable branch yet, so we could run into the problem of releng master breaking again when Euphrates comes around 08:58:00 we need to support a separate branch for each repo, so we can adjust in case other project breaks, or tags at a different time. 08:58:23 releng repo can be removed in E release 08:59:00 okay, so they are moving fetch_os_creds? 08:59:23 as the fetch_os_creds.sh is preferred to run on Jump host 08:59:42 #link https://gerrit.opnfv.org/gerrit/#/c/37119/ 09:00:13 okay, so we just need a STORPERF_BRANCH variable 09:01:19 ok, it is also called in api, so I also need to remove it. 09:02:35 we have https://jira.opnfv.org/browse/YARDSTICK-691 for Dockerfile changes 09:03:49 but maybe we don't need YARDSTICK-691 is we always have good branches to clone. 09:04:27 I'll add a comment to close once fetch_os_creds is removed 09:04:53 And we can create a new Jira to add STORPERF_BRANCH to Jenkins job 09:07:08 #info we will no longer run fetch_os_creds, it will run on jumphost, so we don't need to clone releng 09:07:23 agreed 09:09:02 Jing_: can you create the Jira for STORPERF_BRANCH and assign it to yourself? 09:09:15 sure 09:09:28 thanks 09:09:54 okay, next topic 09:10:05 #link https://gerrit.opnfv.org/gerrit/#/c/36537/ 09:10:27 k8s support? 09:10:28 Hi, it is patch for kubernetes. 09:10:33 rbbratta: yes 09:10:43 #topic kubernetes context 09:11:11 it is the first version. Please feel free to comment. 09:11:14 #info https://gerrit.opnfv.org/gerrit/#/c/36537/ patch for k8s support 09:11:34 it requires kubernetes==2.0.0 09:12:02 is that the official python kubernetes client? 09:12:23 rbbratta: yes 09:13:26 okay, and you are testing with OpenRetriever? 09:14:06 #info everyone please review kubernetes context patch 09:14:22 yes, I use OpenRetriever code to install k8s. Then test in the environment. 09:14:40 JackChan: great, good work 09:15:31 JackChan: Cool 09:15:40 :-) 09:16:18 I'll try to get people to review 09:16:32 okay, next topic, anteater 09:16:54 #topic CI Gate Security (Anteater) 09:17:13 the anteater want to start running it on all the projects 09:17:25 it will just report issues but won't vote. 09:17:40 is everyone familiar with what anteater checks? 09:18:03 anteater checks for security issues, ssh keys, passwords, etc. 09:18:05 It is a good start. we should have the security scan 09:18:24 we have to generate whitelist to ignore things 09:18:39 I haven't run it yet, but I assume we have a bunch of issues. 09:18:50 I have a patch run security verify 09:18:56 since we have example passwords hardcoded everywhere 09:19:00 #link https://build.opnfv.org/ci/job/opnfv-security-audit-verify-master/523/console 09:19:12 for C release, Luke gave a report of yardstick for the scurity scaning 09:19:27 seems check Licence header missing and other stuff 09:20:11 okay, so I don't know when they will start scanning, just is just notice that it will happen at some point 09:21:19 it already run with releng 09:21:46 Luke gave a report of yardstick for the scurity scaning, there were 100+ issues 09:22:06 ah okay I missed that 09:22:16 do we have the list of issues? 09:22:22 However, he said it is OK to keep it. no high risk. for C release 09:22:52 C release? or D release? 09:23:12 C release, they didn't do security scanning in Danube 09:23:51 okay I assume they will start scanning master branch via Jenkins 09:23:53 so that's why we really need to security scan with verify job 09:24:17 yes, that is a good idea. 09:24:48 okay, we'll follow up with Luke and see when it can be enabled. 09:25:29 #action Ross check when anteater will start checking master on Jenkins 09:25:39 okay, next topic 09:25:44 #topic AoB 09:26:59 going once 09:27:05 going twice 09:27:17 yes this time slot is ok 09:27:30 sorry wrong tab 09:27:43 abhijitsinha: :) 09:27:47 okay we are done 09:27:54 #endmeeting