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