08:00:35 <huzhj> #startmeeting daisycloud 08:00:36 <openstack> Meeting started Fri Apr 14 08:00:35 2017 UTC and is due to finish in 60 minutes. The chair is huzhj. Information about MeetBot at http://wiki.debian.org/MeetBot. 08:00:37 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 08:00:40 <openstack> The meeting name has been set to 'daisycloud' 08:01:41 <huzhj> #topic Roll Call 08:02:08 <zhouya> #info zhouya 08:02:12 <kongwei> #info kongwei 08:07:44 <huzhj> #info Zhijiang 08:08:02 <huzhj> #topic OPNFV: VM/BM Deployment & Functest Integration 08:08:43 <huzhj> let 's follow up last meeting's actions 08:08:58 <huzhj> http://eavesdrop.openstack.org/meetings/daisycloud/2017/daisycloud.2017-04-07-07.59.html 08:09:18 <huzhj> So Ya, what about the mutinode deploy on virtual env? 08:10:02 <huzhj> kongwei , so you are on cell phone now?:) 08:10:25 <kongwei> yes 08:10:27 <zhouya> After the 'eth0' problem has been solved 08:10:45 <kongwei> i am home，now 08:10:57 <zhouya> I think the multinode deployment of openstack on virtual env is ok 08:11:40 <huzhj> Good, zhouya, do we have any url to show the status? 08:12:10 <huzhj> #info zhouya said, After the 'eth0' problem has been solved ,the multinode deployment of openstack on virtual env is ok 08:12:14 <zhouya> But it seems we still have some problem of env of the zte-virtual1 08:12:16 <zhouya> https://build.opnfv.org/ci/job/daisy-deploy-virtual-daily-master/ 08:13:17 <zhouya> The nearist result of env deployment is stock into a same problem:error: The name org.fedoraproject.FirewallD1 was not provided by any .service files 08:13:47 <huzhj> error: failed to get domain 'all_in_one' ? 08:14:00 <zhouya> And we can not start bridge daisy1. 08:14:01 <zhouya> error: Failed to start network daisy1 08:14:35 <huzhj> Was it an old problem or a new one? 08:14:47 <zhouya> It is a new problem 08:15:21 <zhouya> Also, another problem is puzzle me:hudson.remoting.ChannelClosedException: channel is already closed 08:16:02 <huzhj> can we try reproduce it manually on zte-virtual1? 08:16:07 <zhouya> Maybe the remote jenkinci is aborted by someone? 08:16:36 <zhouya> Mere speculation 08:18:08 <huzhj> I think you can ask Julien to see if the task is stopped by him, since he was working on rearrange the jobs to prevent interlock problem, may be he may need to stop some jobs manually 08:18:10 <zhouya> We can test the first problem of failed to start network daisy1 on zte-virtual1 to find out if it is the env problem. 08:19:18 <huzhj> Also, you can send a email to Serena to ask for help about what the hudson.remoting.ChannelClosedException problem is. 08:19:32 <huzhj> Good 08:19:37 <zhouya> The good news is the bm deployment is always successful. 08:19:52 <zhouya> https://build.opnfv.org/ci/job/daisy-deploy-daily-master/ 08:20:02 <huzhj> #info zhouya to reproduce "org.fedoraproject.FirewallD1 was not provided by any .service files" on zte-virtual1 manually 08:20:03 <huzhj> #undo 08:20:03 <openstack> Removing item from minutes: #info zhouya to reproduce "org.fedoraproject.FirewallD1 was not provided by any .service files" on zte-virtual1 manually 08:20:11 <huzhj> #action zhouya to reproduce "org.fedoraproject.FirewallD1 was not provided by any .service files" on zte-virtual1 manually 08:21:22 <huzhj> Good! then I think it is the time to integrate BM deployment with functest? 08:21:34 <zhouya> Absolutely agreed.And I will also send a email to serena to ask about the hudson problem. 08:22:30 <huzhj> Yes, currently jobs such as https://build.opnfv.org/ci/job/daisy-os-nosdn-nofeature-ha-baremetal-daily-master/ never got chance to run 08:22:31 <zhouya> Since the BM deployment is stable now,from my opinion it is right time for us to integrate BM deployment with functest. 08:22:53 <huzhj> #info Since the BM deployment is stable now,it is right time for us to integrate BM deployment with functest. 08:22:56 <zhouya> It is normal situation. 08:23:21 <zhouya> For we have to download the opnfv.bin. 08:24:03 <zhouya> And this bin is 3Gb size,so it will take some time to get from upstream. 08:24:43 <huzhj> zhouya, we have to download the opnfv.bin to do what? 08:25:45 <zhouya> To deploy the openstack. 08:25:53 <huzhj> to do https://build.opnfv.org/ci/job/daisy-os-nosdn-nofeature-ha-baremetal-daily-master/ ? 08:26:24 <zhouya> each time we have to download the bin. 08:26:51 <zhouya> -rw-r--r--. 1 opnfvjenkins2 opnfvjenkins2 3654081984 Apr 14 16:25 /home/opnfvjenkins2/opnfv_slave_root/workspace/daisy-deploy-daily-master/opnfv.bin 08:27:17 <huzhj> I do not think https://build.opnfv.org/ci/job/daisy-os-nosdn-nofeature-ha-baremetal-daily-master/ never got chance to run is caused by downloading the bin 08:27:27 <zhouya> Bin file have downloaded complete. 08:28:14 <huzhj> can you show us why you think "downloading the bin" is preventing https://build.opnfv.org/ci/job/daisy-os-nosdn-nofeature-ha-baremetal-daily-master/ got chance to run? 08:29:56 <huzhj> You can see the build history in https://build.opnfv.org/ci/job/daisy-os-nosdn-nofeature-noha-baremetal-daily-master/, it did not run event once 08:29:57 <zhouya> it is jjb code 08:30:05 <huzhj> even once 08:31:00 <huzhj> which piece of jjb code. can you put the gerrit link? 08:31:26 <huzhj> OK, time is limited, let's find out offline 08:31:32 <zhouya> echo "Downloading the $INSTALLER_TYPE artifact using URL http://$OPNFV_ARTIFACT_URL" 08:31:48 <zhouya> daisy4nfv-download-artifact.sh 08:32:33 <zhouya> Before we call the deploy.sh script 08:32:56 <zhouya> we call the download script 08:33:11 <zhouya> https://thepasteb.in/p/k5hY9DJ53G8hE 08:33:30 <huzhj> link is broken 08:33:57 <huzhj> zhouya, could you please open the link https://build.opnfv.org/ci/job/daisy-os-nosdn-nofeature-noha-baremetal-daily-master/ 08:34:07 <zhouya> !include-raw-escape: ./daisy4nfv-download-artifact.sh 08:34:08 <openstack> zhouya: Error: "include-raw-escape:" is not a valid command. 08:34:15 <huzhj> if you open it , you will find out ,it never got chance to run 08:34:20 <zhouya> yes 08:34:39 <zhouya> It is blocking 08:34:53 <huzhj> So it is not the ./daisy4nfv-download-artifact.sh which cause problem . 08:35:27 <huzhj> anything else for this topic? 08:35:47 <zhouya> No. 08:36:17 <huzhj> #topic Cinder/Ceph support 08:36:52 <huzhj> zhouya, have you contacted Serena to see if the current support of Cinder/Ceph can fulfill the requirement of functest ? 08:37:40 <zhouya> No,after last time I record the problem,havn't contact Serena yet. 08:38:00 <zhouya> I will send an email to her to get help. 08:38:06 <huzhj> OK, so let's continue keep it as an action 08:38:08 <zhouya> Thank you for remiding me. 08:38:19 <huzhj> #action zhouya will confirm with Serena to see if the current support of Cinder/Ceph can fulfill the requirement of functest 08:39:09 <huzhj> Let's move on to the next topic 08:39:29 <zhouya> ok. 08:39:34 <huzhj> #topic Daisy as Kolla Image Version Manager 08:39:54 <huzhj> hi luyao, are you there? 08:41:12 <huzhj> OK, I will contact Yao offline 08:41:48 <huzhj> Because we still neet to know if daisy need to have the old and new version co-exist in the registry to do rolling back operation 08:41:57 <huzhj> #info neet to know if daisy need to have the old and new version co-exist in the registry to do rolling back operation 08:42:24 <huzhj> #topic Multicast Image Distribution 08:42:53 <huzhj> #link https://review.openstack.org/#/c/455566/ 08:43:21 <huzhj> When this PS merged I think we will ready for the multicast deployment demo 08:43:34 <zhouya> Seems still have some flake8 errors and unittest errors to deal with. 08:43:39 <huzhj> #info When this PS merged I think we will ready for the multicast deployment demo 08:43:44 <huzhj> Yes 08:43:49 <huzhj> Hi luyao1 08:43:51 <zhouya> Great. 08:44:08 <luyao1> hi 08:44:22 <huzhj> Last meeting we leaved a question 08:44:27 <huzhj> Do we need to have the old and new version co-exist in the registry to do rolling back operation 08:44:51 <huzhj> Have you spent some time on studying this?:) 08:45:08 <luyao1> sorry,I doing ci related job 08:45:24 <luyao1> next week I will study it 08:45:39 <huzhj> Yes, we are meeting a lot of problems in CI 08:45:58 <huzhj> Thanks for the hard work 08:46:24 <luyao1> I will study it later 08:46:40 <huzhj> Ok, then, no other topics for this meeting. 08:46:47 <huzhj> #topic AoB 08:47:27 <zhouya> I've heard the config file format will be changed on E release? 08:47:55 <zhouya> Can you show some example of the yml file?huzhj 08:48:43 <huzhj> Yes, zhouya, the new format is still being discussed, please see https://gerrit.opnfv.org/gerrit/#/c/30677/ 08:49:06 <huzhj> this is the scenarion desc format. 08:49:32 <huzhj> located in Octopus project 08:49:57 <huzhj> There will be another yaml from Pharos project to describe the POD 08:50:26 <huzhj> But I haven't find that yaml example or disscusion 08:51:04 <huzhj> For https://gerrit.opnfv.org/gerrit/#/c/30677/ , we suggestion any one of us can do review 08:52:04 <zhouya> OK,will spend some time to review this format. 08:53:11 <huzhj> Thanks 08:57:14 <huzhj> The scenario descriptor format (sdf for short) format is quite function -oriented 08:58:14 <huzhj> Ithink it is better to ask upper layer guys to discuss, such people from VNF 08:59:16 <huzhj> because they are SDF producer , while installer is just consumer. 08:59:29 <huzhj> OK, let's wrap up 08:59:32 <zhouya> We have to modify a lot of our function of get_conf to stay same with the new format. 08:59:49 <zhouya> ok 09:00:37 <huzhj> YEs 09:00:52 <huzhj> have a good weekend. Bye 09:00:57 <huzhj> #endmeeting