08:00:24 <huzhj> #startmeeting daisycloud
08:00:25 <openstack> Meeting started Fri Apr 28 08:00:24 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:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
08:00:30 <openstack> The meeting name has been set to 'daisycloud'
08:00:40 <huzhj> #topic Roll Call
08:00:45 <yangyape_> hi guys
08:00:46 <huzhj> #info Zhijiang
08:00:57 <zhouya> #info zhouya
08:01:34 <huzhj> hi zhouya
08:01:49 <huzhj> hi yangyape_
08:02:03 <huzhj> Todays's topic
08:02:19 <huzhj> 1) Roll Call
08:02:20 <huzhj> 2) OPNFV VM/BM Deployment & Functest Integration
08:02:20 <huzhj> 3) OpenStack Uninstall
08:02:20 <huzhj> 4) Multicast Image Distribution
08:02:20 <huzhj> 5) AoB
08:03:05 <huzhj> #topic OPNFV VM/BM Deployment & Functest Integration
08:03:45 <huzhj> #info B/M deploy failed once inside Kolla
08:03:50 <huzhj> #link https://build.opnfv.org/ci/job/daisy-deploy-daily-master/141/console
08:04:26 <huzhj> seems need to get more info using docker log next time we reproduce it
08:05:32 <huzhj> #info need to get more info using docker log next time we reproduce it
08:05:54 <zhouya> the difficulty is how we can preserve the env
08:06:13 <huzhj> can we ask alex for help?
08:06:17 <zhouya> Most time the CI env is tiggered by time.
08:06:53 <zhouya> And we can't trace the env real-time.
08:07:21 <huzhj> when it will be triggered during each day?
08:08:32 <huzhj> we can see the time slot it used in this page : https://build.opnfv.org/ci/job/daisy-deploy-daily-master/
08:09:34 <huzhj> anything else of this topic?
08:09:43 <zhouya> no
08:09:52 <huzhj> add one
08:10:30 <huzhj> #info according to the E release schedule, we need to support OpenStack Ocata before May 30
08:10:52 <huzhj> OK, let's move on
08:11:27 <zhouya> So we still use the ansible to deploy the openstack?
08:11:42 <huzhj> yes
08:12:35 <zhouya> OK,So the urgentest thing is that we need to have a useable images of Ocata openstack.
08:12:58 <huzhj> The image has already been built
08:13:22 <huzhj> #link http://120.24.17.215/
08:13:46 <huzhj> #link http://120.24.17.215/kolla-image-ocata-170420124331.tgz
08:14:24 <huzhj> but not sure if it is usable :)
08:14:45 <zhouya> We should use the ocata images to have a test.
08:15:01 <huzhj> Yes.
08:16:00 <zhouya> Maybe we do not have to move our daisy to Ocata?
08:16:01 <huzhj> #action I will try to do the Ocata deployment test by using current daisy version
08:16:43 <zhouya> And the coincidence of daisy and kolla will be sperated.
08:17:00 <zhouya> Right?
08:17:14 <huzhj> Yes I will try to keep Dasiy stable, becasue just as what I said last meeting, Kolla seems can still work on libs from newton
08:17:39 <huzhj> for this release may be yes
08:17:51 <huzhj> for next release, may be no
08:18:38 <zhouya> fantastic.
08:19:08 <huzhj> zhouya, can you preserve a vm on travel for me to do this test?
08:19:32 <zhouya> All right.
08:20:09 <huzhj> Thanks
08:20:14 <huzhj> OK, next topic
08:20:21 <zhouya> travel is now doing the 20 nodes deployment.
08:20:21 <huzhj> #topic OpenStack Uninstall
08:20:47 <huzhj> waht about the uninstall function progress?
08:21:34 <zhouya> We can successfully uninstall openstack with the command:daisy uninstall cluster-id
08:21:47 <huzhj> Great
08:21:54 <huzhj> #info We can successfully uninstall openstack with the command:daisy uninstall cluster-id
08:22:10 <huzhj> So no GUI support currently?
08:22:45 <zhouya> The influence of lvm backend of /dev/loopx has been repaired.
08:23:09 <huzhj> Good
08:23:09 <zhouya> GUI is also supported to uninstall openstack.
08:23:19 <huzhj> Good
08:23:35 <huzhj> #info user now can uninstall OpenStack over GUI
08:25:22 <huzhj> I believe the uninstall process should not remove our docker registry server as well as kolla image data, right?
08:26:37 <zhouya> uninstall will not remove our docker registry
08:27:06 <huzhj> OK, but when we reinstall , the  docker registry server  will re build again?
08:27:23 <zhouya> But the kolla images data in target node is optional
08:27:47 <zhouya> yes,the docker registry server will be rebuild.
08:28:21 <huzhj> So I think the docker registry server should also be removed by the unisntall process, what do you think?
08:29:11 <zhouya> For clean the env totally,I can't agree more to do this.
08:29:45 <huzhj> But is that will be a waste of time if we reinstall the same version?
08:30:06 <zhouya> Absolute.
08:30:43 <zhouya> For we have to unzip the kolla images each times we deploy the openstack.
08:30:45 <huzhj> what about we just keep it when uninstall, and have some checking code to make sure that it can reuse when issuing next install
08:31:00 <zhouya> I think it will not cost much time.
08:31:16 <zhouya> #agree
08:31:49 <zhouya> I think the version management will help us to do this.
08:32:18 <huzhj> Then, when do next installation , we rebuild it only if it can not be reused
08:32:43 <zhouya> But,the essencial thing for us to do is to add version file from the begining of the deployment.
08:33:06 <zhouya> Yes.
08:33:55 <huzhj> if  it can not be reused , then there is no need to add version file at the begining of the deployment.
08:34:03 <huzhj> if  it CAN be reused , then there is no need to add version file at the begining of the deployment.
08:34:16 <zhouya> YES
08:35:16 <huzhj> I think we can get the current in-regirtry version from daisy DB
08:35:31 <huzhj> do not need to query it from docker
08:35:59 <zhouya> Good idea.
08:36:02 <huzhj> Becasue during each installation we always keep a record of the version info into daisy DB
08:37:13 <huzhj> So I hope the version manager code should have a logic like: if the current version is the version that user want to add, then simply return DONE
08:37:20 <zhouya> It will be much more convient for us to query the version of openstack by using daisy DB.
08:38:08 <huzhj> but there is another thing
08:38:41 <huzhj> when we do uninstall, we will wipe the current version info from Daisy DB.
08:39:31 <huzhj> So even if the kolla image still exist in docker registry, the version info is lost.
08:40:18 <zhouya> YES
08:40:27 <huzhj> seems become more complicated
08:40:51 <huzhj> Let's disscuss offline, we need some sort of spec
08:41:08 <zhouya> yes ,spec will be needed.
08:41:56 <huzhj> #info we need some sort of spec to describe the version management
08:42:30 <huzhj> #info especially for the version info sync between Daisy DB and docker registry server.
08:42:54 <huzhj> OK., next topic
08:42:58 <huzhj> #topic Multicast Image Distribution
08:43:19 <huzhj> any status update ?
08:44:00 <zhouya> Multicast is ok for our deployment.
08:44:27 <huzhj> Good
08:44:49 <zhouya> But the performance seems a little poor for we use the vm.
08:45:12 <huzhj> Have you measured the performance difference between multicast and unicast in a 20 VM node env?
08:45:40 <zhouya> I have just test the unitcast in 20 vms.
08:46:38 <zhouya> The most difficult thing is that we sometimes can't install os properly on one or two vm.
08:46:42 <huzhj> when it comes to performance, could you please provide  more detailed info ,such as time used in both ***cast scenario
08:47:42 <huzhj> Have you found out the  reason?
08:48:13 <zhouya> The unitcast we use on the daisy is about 1 hour and a quarter.
08:48:24 <huzhj> 20 nodes?
08:48:31 <zhouya> 20 nodes.
08:48:34 <zhouya> It isn
08:48:41 <huzhj> includes OS intallation or not?
08:48:53 <zhouya> without os installation
08:48:56 <huzhj> zhouya, may be you can provide a table
08:49:03 <huzhj> using etherpad
08:49:06 <zhouya> ok
08:49:07 <huzhj> offlne
08:49:26 <huzhj> Thans, that would be more intuitive
08:49:57 <zhouya> A table will be more clearerly for us to compare the proformance.
08:50:53 <huzhj> #action, zhouya to provide a table to compare the initial performance difference between unicast and multicast
08:54:26 <huzhj> anything else for this topic?
08:55:32 <huzhj> #topic AoB
08:58:47 <huzhj> Let's wrap this up
08:59:12 <huzhj> #endmeeting