13:00:12 #startmeeting Cross Community CI 13:00:12 Meeting started Wed Apr 11 13:00:12 2018 UTC. The chair is fdegir. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:00:12 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:00:12 The meeting name has been set to 'cross_community_ci' 13:00:17 hi everyone 13:00:24 Hi 13:00:27 hi 13:00:31 #info David Blaisonneau 13:00:32 #topic Rollcall 13:00:51 please type in your name if you are joining the meeting 13:01:09 #info David McBride 13:01:19 #info Markos Chandras 13:01:22 #info Tianwei Wu 13:01:31 #info Manuel Buil 13:01:33 #info Joe Kidder 13:01:36 let's start and others can join on the way 13:01:43 #topic OpenCI 13:02:06 #info As highlighted in meeting invitation, OpenCI will be standing agenda item from now on 13:02:31 #info Anyone from OPNFV Community who is interested in OpenCI can join XCI Meeting and get the latest updates 13:03:09 #info OpenCI Infra has been setup and we have a homepage, wiki, gitlab stuff, mailing list and irc channel 13:03:28 #link https://openci.io/ 13:03:40 #link https://gitlab.openci.io/openci/community/wikis/home 13:04:18 pretty fancy 13:04:22 #info A prototype to demonstrate CI/CD Federation is in progress - this will use events to establish communication between OPNFV and OpenDaylight CIs 13:04:33 #info Periyasamy Palanisamy 13:04:35 anyone has questions/comments? 13:05:15 btw, the meeting agenda is on its usual place: https://etherpad.opnfv.org/p/xci-meetings 13:05:17 what is "communication" ? 13:05:33 David_Orange: great question 13:05:37 let me info in 13:05:51 sure 13:05:55 #info Our CIs currently rely on timers/polling and so on instead of doing things when things happen 13:06:17 #info By making CIs event driven, we can simply enable our CIs to talk to each other via events 13:06:37 #info For example, OpenDaylight has autorelease jobs and we currently ask if there is a new artifact there 13:07:38 #info With event driven CI, OpenDaylight CI/Autorelease job can simple announce availability of a new artifact which passed certain level of testing and promoted for the use of others (ie. reached to a certain Confidence Level) and anyone who is interested in those artifacts can consume the event and fetch the artifact 13:08:09 #info The events will carry certain metadata such as what level of testing that artifact passed, what the confidence level is, where it is stored and so on 13:08:26 #info Currently we do magic and parse Jenkins comments passed to Gerrit to find artifacts 13:08:27 so it is a system of triggers to get feedback from partners 13:08:41 David_Orange: you can say that but it is more than that 13:09:02 #info Another example is CNCF parses ONAP Jenkins job logs to extract info about artifacts 13:09:05 these are all messy... 13:09:27 #info For federation to happen, a messaging protocol which all CIs adhere to is needed 13:09:46 #info The demo between OPNFV and OpenDaylight aims to highlight this fact and start the conversation around the protocol 13:10:38 #info Another and perhaps pretty crucial benefit of this is to establosh E2E Traceability since the events can refer to each other; I've been published because this event caused triggering of the job which published me 13:10:57 a publish subscribe 'like' methods ? 13:11:02 David_Orange: yes 13:11:16 publishers and consumers 13:11:56 ok, great, thanks for this clarification 13:12:03 David_Orange: np 13:12:18 if anyone has ideas/experience/interest, please contribute to this so we move it forward 13:12:39 if there is no other question about OpenCI, moving to the XCI part of the agenda 13:12:53 which is high prio items 13:12:58 #topic Baremetal Status 13:13:13 David_Orange: are you still looking into this or moved to Kolla? 13:13:30 i am in the middle 13:13:33 #info Jack Morgan 13:13:43 David_Orange: ok 13:13:57 trying to propose a base for moving all installer to pdf/idf 13:14:06 I want to let everyone know that the highest prio for us is to get Baremetal working 13:14:12 (cf patch about inventory) 13:14:41 maybe you should explain what you aim under 'baremetal' 13:14:46 scenarios etc are important but we have been promoting scenarios from post-merge but not continuing with the rest of the CI loops 13:15:12 #info We need to ensure we have working baremetal deployment in place - starting with os-nosdn-nofeature and with PDF/IDF 13:15:17 #info Rest has lower prio 13:15:22 all baremeals ? just one ? 13:15:37 David_Orange: do you mean all PODs? 13:15:40 yes 13:15:49 David_Orange: if we have one, that is a good start 13:16:35 from my point of view there is 2 parts, the baremetal deploy of an OS, and the BM deploy of installers 13:16:51 OS=operating system or OS=openstack? 13:17:12 fdegir: Operating system, sorry 13:17:39 and we don't talk about installers 13:17:46 we talk about getting scenarios on baremetal 13:17:57 and in the middle a set of common roles that shall configure Op.S. with network and an inventory to simplify the work of the installer 13:18:09 and we currently have 2 installers which are eligible to go to baremetal; osa and kubespray 13:18:30 that is the roles of patches around inventory and the one for network 13:18:48 David_Orange: are you talking about patches in prototypes folder or there are other patches? 13:19:20 other patches, I will not touch the patch inside proto until review, maybe tomorrow or never 13:19:59 fdegir: the scenarios are based on what the installer deploys, no ? 13:20:15 David_Orange: yes 13:20:36 David_Orange: but this is a more general comment - it is past time we stop talking about installers and focus on the scenarios 13:20:36 so it shall impacts also the installers 13:21:16 just to clarify; my comment about baremetal eligibility of installers is based on the promoted scenarios 13:21:57 David_Orange: please paste the links to the patches you are talking about 13:22:11 ok, you mean we focus on one simple scenario + installer, not all scenarios + installer 13:22:33 David_Orange: yes 13:22:33 https://gerrit.opnfv.org/gerrit/#/c/55319/ 13:22:47 David_Orange: once we have one working, the others need to be adapted which we have owners for 13:22:58 sure 13:23:20 fdegir: for release purposes, does this mean that all scenarios will have the option of osa or kubespray? 13:23:50 dmcbride: currently all openstack scenarios that are promoted use osa 13:23:55 the other about network is https://gerrit.opnfv.org/gerrit/#/c/52841/ even if i dont think the actual version is good (cf tech talk AoB) 13:24:01 dmcbride: and all k8s scenarios that are promoted use kubespray 13:24:15 fdegir: ok - got it 13:24:35 David_Orange: the 2nd change will probably have to wait unfortunately 13:24:56 David_Orange: the other change for kolla is disruptive - meaning that it will impact whole CI chain 13:24:59 in the actual way i will put a -1 13:25:15 to everyone: please review https://gerrit.opnfv.org/gerrit/#/c/55319/ 13:25:17 #link https://gerrit.opnfv.org/gerrit/#/c/55319/ 13:25:42 it says WIP 13:25:48 this one will also impact the whole chain 13:26:05 David_Orange: do you plan to continue working on https://gerrit.opnfv.org/gerrit/#/c/55319/ or is it ready for review? 13:26:09 yes, because it can be enhanced and i wish feedback 13:26:17 mbuil: ^ 13:26:34 David_Orange: you can tell ci which scenario you want your change to be tested 13:26:36 David_Orange: I understand that it is ready for review then 13:26:56 David_Orange: in order to do that, you need to add below lines to commit message 13:27:01 deploy-scenario:os-nosdn-nofeature 13:27:05 installer-type:osa 13:27:18 David_Orange: CI will then use osa and deploy os-nosdn-nofeature 13:27:29 as i have the bad habit to create big patch, i probably dont have the good way to propose patches :) this one can work, as it is common and impact everyone i set WIP 13:27:59 fdegir: ok, how can i do that ? 13:28:10 (offline talk if you prefer) 13:28:13 few lines above 13:28:25 you need to add below lines to commit message 13:28:30 deploy-scenario:os-nosdn-nofeature 13:28:30 ok, missed it, sorry 13:28:36 installer-type:osa 13:28:38 no spaces etc 13:29:06 btw, ci skips commit message updates so you need to touch a file in change to ensure the jobs get run 13:29:29 we can continue talking about baremetal after the meeting 13:29:35 thanks for the updates David_Orange 13:30:03 about this patch, i added a test folder, to show reviewers that want to test it on local, that templates are creating exactly the actual templates :) 13:30:11 I take this as we will continue have you as our baremetal expert which is good 13:30:32 #topic CI Status 13:30:52 #info We have patchset verification and post merge jobs running for OpenStack scenarios, promoting stuff 13:31:01 an will be in favour of a tech talk someday dedicated to avolution to BM 13:31:01 #link https://build.opnfv.org/ci/job/xci-merge-virtual-master/ 13:31:32 #info The current criteria for patchset verification and post-merge is noha virtual deployment + healthcheck which will be revisited once we have baremetal is working 13:32:17 #info For Kubernetes scenarios, the criteria for patchset verification and post merge is only the deployment 13:32:27 is xci-merge-ubuntu-virtual-master != xci-verify-ubuntu-virtual-master? 13:32:33 sorry 13:32:36 #info Work to integrate functest healthcheck is still in progress and should be complete this week 13:32:44 mbuil: they do same thing at the moment 13:33:01 mbuil: that will change once we have baremetal working 13:33:03 fdegir: 100% sure they are the same? 13:33:15 one works and the other does not :( 13:33:18 mbuil: I 100% hope they are the same 13:33:39 mbuil: I'll check them and ping you 13:33:45 fdegir: does HC apply to k8s scenarios, or only OS scenarios? 13:33:54 dmcbride: only OS at the moment 13:34:04 ok 13:34:12 dmcbride: patches to enable it were under review and should be ready soon - this week 13:34:21 +1 13:34:36 dmcbride: https://gerrit.opnfv.org/gerrit/#/q/project:releng-xci+branch:master+topic:xci-functest-integration 13:35:01 dmcbride: some of them were abandoned due to me messing up things - conflicts etc 13:35:09 dmcbride: new ones will be sent 13:35:32 btw; anyone who might work with k8s scenarios will be blocked until the healthcheck is integrated 13:35:55 I jsut submitted a patch to enable the testing on jenkins job side but the actual test parts are in progress 13:36:51 #info XCI Dashboard is available to see the scenario status: http://129.192.69.214/xci.php 13:37:35 anyone has any questions about all the things I've mentioned above? 13:38:04 I want to reiterate that we are in pretty good shape from CI point of view 13:38:22 yup, great job 13:38:23 we need to get baremetal working so we can continue our journey towards establishing CI Evolution truly 13:38:45 and k8s healthcheck is important as well but it is pretty trivial comparing to baremetal 13:38:55 thx jmorgan1 :) 13:38:57 David Blaisonneau proposed releng-xci: [WIP] Generate inventory file https://gerrit.opnfv.org/gerrit/55319 13:39:06 #topic Long Duration Testing Support 13:39:25 #info We had some conversations with Test WG and they need a timeline for baremetal availability 13:39:30 David_Orange: ^ 13:39:37 David_Orange: I promised them to ask this to you 13:39:50 David_Orange: you don't need to answer now so I am merely keeping my promise 13:40:11 #info We need to ensure they have something totally automated before the hackfest 13:41:23 #topic CI Support for Test Projects 13:41:50 #info We are working on enabling snapshotting of a known/good deployment for test projects so they can use it for gating their patches 13:41:56 epalper: anything you want to add? 13:42:27 fdegir: I'm trying with export/import of XCI VM snapshots. 13:42:48 https://gerrit.opnfv.org/gerrit/#/c/48391/ 13:42:59 epalper: please focus on mini flavor if you have been trying it for others instead 13:43:25 looks like we need to migrate qcow2 images with its xml 13:43:42 instead of actual vm snapshots with its state 13:43:57 this creates lots of problems 13:44:15 fdegir: sorry someone in my office, i rewind the irc logs 13:44:19 epalper: ok - again, we can go into details offline 13:44:26 sure 13:44:26 epalper: thanks for the update 13:44:47 #topic Quick Status Check for the Scenarios 13:44:57 anyone has any update for the scenarios they are working on? 13:45:05 mbuil: hw_wutianwei_: epalper: ^ 13:45:50 fdgedir: we need to run the tests against ODL oxygen for bgpvpn scenario. its not done yet 13:46:00 fdegir: I am working on k8-nosdn-nofeature and k8-canal-nofeature 13:46:29 #link https://gerrit.opnfv.org/gerrit/#/c/54309/ 13:46:34 #info os-odl-bgpvpn needs to switch to ODL Oxygen 13:46:48 #info https://gerrit.opnfv.org/gerrit/#/c/55317/ 13:46:50 #info Work is in progress with k8-nosdn-nofeature and k8-canal-nofeature 13:46:56 please review 13:47:05 #info k8-nosdn-nofeature switches network plugin from calico to kubenet 13:47:17 #info A new scenario k8-calico-nofeature will be created later on 13:47:25 fdegir: yep 13:47:57 #info Kubernetes scenarios hw_wutianwei_ and Taseer working on are important for Scenario Consolidation and SDF which will use the 4 k8s scenarios for prototyping 13:48:02 fdegir: moving sfc to Oxygen fixed our healthcheck issues for verification and merge in opensuse and for verification in ubuntu. However xci-merge-ubuntu-virtual-master still shows those issues 13:48:25 I can't reproduce them in laas :( 13:48:44 mbuil: there should be no difference at that part since they both use same script to run functest 13:49:05 mbuil: I've seen you did remerge which is good - if it fails again, we can take a closer look as I suggested above 13:49:45 I think that's all for the scenario updates 13:49:55 thx mbuil epalper hw_wutianwei_ and Taseer for taking care of the scenarios 13:50:11 #topic AoB 13:50:27 who added the topic "evolution of the shared role for configuring nodes"? 13:50:30 is there a OPNFV project that is using Calico? 13:50:41 fdegir: myself 13:50:44 dmcbride: i don't hthink so 13:50:49 do we have pdf support for xci? 13:50:58 jmorgan1: David_Orange is working on it 13:51:05 fdegir: thanks 13:51:36 David_Orange: would you like to share your thinking here so we can perhaps continue after the meeting or during next meeting or book a separate meeting? 13:51:43 jmorgan1: pdf+idf in /prototypes to deploy Op.Sys, your are welcome to review it 13:52:05 fdegir: we will need it for CI evolution completeness 13:52:14 David_Orange: ok, i will thanks 13:52:51 what is the status of idf? 13:53:04 same as pdf? 13:53:08 dmcbride: its a work in progress 13:53:11 the idea behind that talk is to have your feelings about common roles (configure network, inventory, configure...) 13:53:27 dmcbride: pdf is done, just needs opnfv labs to create them for all opnfv POD 13:53:36 David_Orange: i personally think we should try to keep things as common as possible until we have no possibility to have that 13:54:00 jmorgan1: and the updates to support xci 13:54:03 as we have more installers, and with the introduction of PDF/IDF, my opinion is that we have to share the maximum of roles to prepare the steps before the installers parts 13:54:03 dmcbride: IDF is a pre-SDF effort, they might be the same file or two files / efforts 13:54:07 David_Orange: the roles could be same but templates/vars could be different 13:54:31 jmorgan1: ok - thanks 13:54:58 fdegir: it is a possibility but it push more complexity to installer part 13:55:06 dmcbride: pdf support should be easier since the format of the file is done 13:55:11 quick question - does osa use pdf/idf? I'm guessing it's outside of OPNFV scope...but not sure. 13:55:31 David_Orange: let us think about the impacts of multiple installers once we have one of them working 13:55:54 as PDF/IDF is not always easy to read and get info from it, having a common basis for all installer masking a bit of the complexity of xDFs shall be a good option 13:55:57 dmcbride: idf or sdf or both are WIP.. 1st need to standarize on format of the file, need idf + sdf or idf will become sdf, etc 13:56:12 joekidder: osa doesn't really deal with that part 13:56:23 joekidder: it just gets openstack on nodes you prepare in advance 13:56:24 dmcbride: then once its working, then get support opnfv installers + xci support 13:56:44 joekidder: and then have the config files reflect the configuraiton you want to have depending on your nodes/networking 13:56:48 fdegir: to have coded one (nearly 2) with PDF/IDF, managing networks with PDFs is not easy 13:57:12 joekidder: the pdf/idf is mainly used for provisioning with bifrost, host-bootstrap 13:57:25 joekidder: and then the config is also reflected to osa config files 13:57:37 and pushing complexity to one installers is not a option in my view 13:58:05 David_Orange: sorry - lost track 13:58:06 dmcbride: David_Orange is the one really working on it, just sharing my observation ;) 13:58:41 fdegir ok. thanks. been focused on typical opnfv installers and need to start playing with xci to get more educated:) 13:59:09 i mean , in the xDF, you dont have the info about interface name to use for example 13:59:10 we need baremetel support issue resolved 1st (sounds like) before pdf/idf support 13:59:41 David_Orange: how does fuel or daisy do that then? 13:59:45 if we let installer parse all that stuff it will be a hard job done more than one time 14:00:06 i dont know, but they probably have a pivot file to do that 14:00:22 and they only have to do it once 14:00:22 let's end the meeting and we continue this conversation afterwards 14:00:28 fdegir: sure 14:00:38 thanks all for joining! 14:00:40 #endmeeting