14:00:09 #startmeeting Octopus weekly meeting 14:00:09 Meeting started Mon Aug 3 14:00:09 2015 UTC. The chair is uli-k. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:00:09 Useful Commands: #action #agreed #help #info #idea #link #topic. 14:00:09 The meeting name has been set to 'octopus_weekly_meeting' 14:00:43 Hi everybody! 14:00:52 #topic Rollcall 14:01:25 Please type #info 14:02:18 #info chigang 14:02:34 #info zhifeng 14:03:05 Welcome again everybody! 14:03:08 #meimei 14:03:14 #info meimei 14:03:48 Let's have a look at the agenda. I got proposal for two more topics which I added to wiki. 14:03:56 #topic Agenda bashing 14:05:05 #info Agenda has: Action Item review, Starting clean-up of committer list, Lab Compliancy, Define what is E2E for CI, Jira and B-Release 14:05:22 Anything else you would like to see (or not see)? 14:06:05 #info Dan Radez 14:06:33 #info Tim Rozet 14:06:48 OK then let's start with first topic. 14:06:52 #info Peter Bandzi 14:06:58 #topic Action Item review 14:07:01 #info Jun Li 14:07:35 #info first action on the list after last meeting: meimei1 to contact Pharos and find some help to drive conformance spec. 14:08:01 #info meimei requested therefore to put lab compliance on agenda today. 14:08:39 meimei, is there anything else to report? 14:08:50 #info Meimei have put a list into etherpad 14:09:07 our etherpad R2? 14:09:32 Octopus requirements on labs compliance: 14:09:32 1. Dedicated to E2E CI 14:09:32 1. We require your lab or specified POD in your lab be CI dedicated, that is it will be available for CI usage all time. If it will be used for development these activities can be interrupted by CI anytime, and E2E CI will be implemented on your lab on timer/daily, or maybe merge-triggered. 14:09:32 2. Automatic Reconfiguration 14:09:32 We require your lab have specific scripts for automatic reconfiguration that will be executed by CI before a E2E CI job is executed on your lab. 14:09:33 3. Keep online 14:09:33 We require your lab connected to jenkins and online 24x7. CI team shall be notified when some maintenance is scheduled. 14:09:34 4. Maintainable 14:09:34 We require the admin access to your lab to troubleshooting CI issues. 14:09:34 5. Standard name 14:09:35 We require your lab connected to jenkins master by a standard name, just like: [provider]-[CI/DEV]-[Virtual/Metal], for example, a node named huawei-ci-virtual is provided by huawei, and is CI-dedicated, and we can implement a virtual deployment on it. 14:09:36 Based on this specification, we can easily put these nodes with the same purpose into a pool, e.g. for E2E CI , and implement E2E CI using a round-robin mechanism. 14:10:07 we can have a further discuss about this 14:10:55 #info have a further discuss about labs compliancy 14:11:01 trozet, radez, would this match your experience from Arno? 14:11:58 uli-k: so the round robing idea 14:12:03 robin* 14:12:23 uli-k: would that be round robin with all the labs (including LF) or would it be round robin on the community labs only? 14:12:51 It should be round robin on all participating labs. 14:13:13 I'm not sure what you are round robining? the ci jobs? 14:13:14 i think only LF is not enough 14:13:29 That would include LF. 14:13:35 CI pipeline jobs 14:13:53 uli-k: But we will still have the option to only choose LF lab for our jenkins run, right? 14:14:07 uli-k: I still see a need to run something on the "official" POD 14:14:22 Yes. 14:14:39 ok then that all sounds good to me 14:14:45 But if all ci jobs have to run there, we will have a problem. 14:14:50 I believe this is consitent with our experience 14:15:09 #info yes, I believe this is consitent with our experience 14:15:49 if labs is pharos compliant, other labs will be the same as LF lab 14:16:31 if labs is pharos compliant , it means "official" 14:16:53 meimei: the same hardware? the same server? 14:17:00 Yes. I guess when we release Brahmaputra, we will have to run a set of tests on multiple labs. 14:17:35 meimei: when i used the term official - In Arno there were requirements for things to pass on the LF lab specifically before release. 14:17:53 meimei: so if that remains the same for B release...want to make sure I can choose to execute there for verification 14:18:08 I expect, this will change for Brahmaputra. 14:18:31 I expect we should require multiple different hardwares/configs. 14:18:39 we hope that there are more official labs during release-B 14:18:46 But that Pharos should decide. 14:19:26 we donot have to choose a special lab 14:20:34 Should we put the question to TSC to think about whether B. will be released on LF or on multiple labs? 14:21:01 yes, I think so 14:22:20 OK. I need a second name for the action, since I will go to vacation on Thursday and cannot follow-up in TSC. Who can volunteer? 14:23:01 I can ask 14:23:19 OK. I put the action on the two of us. 14:23:58 #action uli-k and trozet to bring to the TSC whether Brahmaputra should be released using LF lab or differently. 14:24:18 Can we close the action for meimei? 14:24:31 ok 14:24:41 Then next action. 14:24:56 #info chigang to try on a POD to apply new naming scheme to a slave. 14:25:13 Did you have a chance to do it? 14:25:32 I think we can put this scheme into lab compliant 14:26:21 chigang,ok? 14:26:27 uli-k: sorry, I do not. meimie said it is not high prio 14:27:05 meimei: agreed, i think we can try it for new labs 14:27:16 OK. I think we should carry it on, since applying it needs lab owners online. 14:27:29 I'll repeat it for the minutes. 14:27:53 #action chigang to try on a POD to apply new naming scheme to a slave. 14:28:02 That was all AIs. 14:28:18 #topic Starting clean-up of committer list 14:28:19 ok, we can have a try on huawei's lab 14:29:08 #info we have 13 committers for Octopus but many of them didn't contribute in the last 6 months. 14:29:44 #info I would like to do some clean-up to make room for people who do a lot of contributions 14:29:58 How do others feel? 14:30:05 sounds good 14:30:36 clear up the ghost committer? 14:32:24 I would send personal mail to each silent committer and ask them to start working on jira or gerrit. Committers who haven't done anything then (I will also check BGS for Arno), I would put for a vote in a weekly meeting. 14:33:18 If people don't step down, but don't act as committers, we might need to bring that before the TSC. (according to by-laws) 14:33:42 How would others feel we should proceed? 14:34:24 I am fine with this 14:34:42 fine with me 14:35:02 fine for me 14:35:18 OK. I put an action for myself (but I don't know I can really do it before my vacation...) 14:35:48 enjoy your vocation! 14:35:51 #action uli-k to contact silent committers and encourage them to start working. 14:36:33 #agree that uli-k issues a vote in weekly meeting about bringing this before the TSC after some time. 14:36:46 #info Thanks! 14:37:02 #topic Lab Compliancy 14:37:05 uli-k: fine 14:37:26 meimei, did you want to discuss more than we did during the action review? 14:38:03 we can discuss after TSC 14:38:18 OK. Then let's move to the next topic. 14:38:20 waiting for your massage 14:38:32 message :) 14:39:10 and anyone have some ideas , you can put into etherpadR2 14:39:18 :P 14:39:55 #topic Define what is E2E for CI 14:40:15 last week , we have a discussion about this 14:40:35 Fatih is here? 14:41:17 I guess not. I am not sure he could stay silent so long :D 14:41:28 hehe 14:42:45 I think we should align the concept of E2E CI 14:43:22 When I think about end to end, the "first" end for me is "git review" by a developer - code change or test case change. 14:43:53 gerrit triggers jenkins, so we start at that "end". 14:43:55 start of a patch 14:44:45 yes,I think so, we also need a timely trigger 14:45:25 for code patch we can do verify (buildable), and also verify (deployable), and even verify (testable). 14:45:49 build is what we do today. 14:47:17 I would say, we do E2E, if we can do also verify by running some basic test (provided by functest) 14:47:36 But there are a few questions to be solved on the way. 14:47:56 Deploy might take too long time. 14:48:14 yes 14:48:25 For Test we might need to select appropriate testcase for that patch. 14:49:31 trozet, radez, what do you say from BGS experience. How can we go for E2E-CI? 14:50:17 uli-k: I think we at least need the tempest smoke tests and the ODL integration tests 14:50:40 uli-k: deploy will take about 1.5 hrs. I cannot recall how long the tests take, but I don't think its very long 14:51:23 Can we move to deploy to a "virtual POD" so we don't block everybody else? 14:51:34 uli-k: we could have different tests for patches vs. full CI run 14:51:42 uli-k: yeah working on creating virtual pods in LF 14:52:36 Does it make sense to run every patch through build-deploy-minitest? 14:53:46 uli-k: I thought about that a little bit. We could do a couple things 14:54:10 uli-k: we could use a tag in the commit to trigger a level of CI verification 14:54:52 ulik: so a submitter could control the level of verification he thinks is appropriate for his patch 14:55:39 trozet: unit-test such as pep8 is needed(this takes may very short times), I think, also the integration test,such as robot for ODL and smoke in tempest(relative longer) 14:55:44 uli-k: another option is we tag certain files in the genesis or installer repos, when we see changes to those in the patches we trigger jenkins (rather than triggering on every commit) 14:56:36 Would it also be an option a submitter provides sort of profile he usually wants to run for his verification? 14:57:31 or project provide this profile 14:57:32 uli-k: yeah thats what I was thinking for the keyword trigger in the commit "smoke-test-full" or "full-ci" something like that 14:57:43 Oh, we need to close the meeting, so BGS can start in time. 14:57:56 trozet, could you write some ideas in the etherpad? 14:58:16 uli-k: sure can you link me the ether pad please? 14:58:35 #link https://etherpad.opnfv.org/p/octopusR2 14:58:38 another "end" remain to next meeting? 14:58:46 Yeah! 14:58:55 Thanks everybody for good meeting! 14:59:05 the same to you 14:59:06 #info Thanks everybody for good meeting! 14:59:12 #endmeeting