07:59:47 <huzhj> #startmeeting daisycloud 07:59:48 <openstack> Meeting started Fri Dec 16 07:59:47 2016 UTC and is due to finish in 60 minutes. The chair is huzhj. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:59:49 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:59:51 <openstack> The meeting name has been set to 'daisycloud' 08:00:02 <huzhj> #topic Roll Call 08:01:33 <zeyu> #info zeyu 08:01:41 <huzhj> #info Zhijiang Hu 08:02:09 <zhouya> #info zhouya 08:02:28 <huzhj> Today's topics 08:02:31 <huzhj> 1) Roll Call 08:02:31 <huzhj> 2) OPNFV: Daisy CI Progress 08:02:31 <huzhj> 3) OpenStack Version management 08:02:31 <huzhj> 4) AoB 08:02:37 <kongwei> #info kongwei 08:03:03 <huzhj> #topic OPNFV: Daisy CI Progress 08:04:12 <huzhj> luyao1: about #link https://gerrit.opnfv.org/gerrit/#/c/26055/ 08:05:02 <huzhj> I saw build started but it hasn't ended for quite a long time. 08:05:18 <zhouya> #agree 08:06:10 <zhouya> so I see in the link #link https://gerrit.opnfv.org/gerrit/#/c/26055/1/code/install_interface_patch.sh,the branch is hard-coded with newton? 08:06:29 <huzhj> Oh, it ended finally 08:06:35 <zhouya> yes 08:06:49 <huzhj> It takes almost 6 hours to download kolla image... 08:07:15 <luyao1> oh so long. 08:07:35 <huzhj> way too long.... 08:08:03 <zeyu> Is there any way to reduce the time 08:08:20 <zhouya> so if we do not have the image ,each time we should cost such time to download kolla image? 08:08:42 <huzhj> Yes. 08:08:50 <huzhj> But it ended like this: 08:08:58 <huzhj> 73% [==========================> ] 2,113,530,887 137KB/s eta 1h 54m 08:08:59 <huzhj> -------------------------------------------------------- 08:08:59 <huzhj> Done! 08:08:59 <huzhj> Finished: SUCCESS 08:10:06 <huzhj> seems did a partial download 08:10:08 <luyao1> just one time 08:10:16 <huzhj> not 100% 08:10:16 <luyao1> next will sooner 08:10:31 <luyao1> because no need to wget tar 08:10:47 <huzhj> We need to get the artifact to see if it was fully downloaded. 08:12:16 <huzhj> zhouya: about #link https://gerrit.opnfv.org/gerrit/#/c/25153/, is it the finall version? 08:12:37 <zhouya> yes 08:13:04 <zhouya> But we should test this on shanghai pod aboud opnfv.bin 08:13:35 <huzhj> OK. 08:13:47 <zhouya> Now we just test it locally,not sure if the kvm env will be ok through. 08:15:13 <huzhj> I think you can wait until this PS merged to test: #link https://review.openstack.org/#/c/410584 08:15:19 <huzhj> about #link https://review.openstack.org/#/c/410584/4/tools/setup/install/install_func.sh@116 08:15:50 <huzhj> zhouya: I do not understand your meaning 08:16:07 <zhouya> It is my fault. 08:16:46 <zhouya> I didn't know the naming rule of registry-*.version 08:16:50 <huzhj> The git version in stored in the version file. the file name is something like registry-newton-201610101212.version 08:17:09 <huzhj> it is OK, that will match the version file 08:17:26 <zhouya> OK,I see. 08:17:28 <huzhj> since we only have on file, so it will not cause problem 08:17:52 <zhouya> Thank you for your explanation 08:17:56 <huzhj> If no problem, then I merge it? 08:18:16 <luyao1> yes 08:18:30 <huzhj> So you can rebuild a new OPNFV artifact which include that function 08:18:49 <zhouya> I didn't see any problem,what about@luyao1 08:19:21 <luyao1> yes 08:20:21 <huzhj> Good 08:20:33 <huzhj> Oh, zhouya, you should also wait #link https://gerrit.opnfv.org/gerrit/#/c/26055/ 08:20:54 <zhouya> got it 08:21:36 <huzhj> zhouya: and this one: #link https://review.openstack.org/#/c/410067/ 08:21:43 <huzhj> do we need to merge into mitaka? 08:22:07 <huzhj> Oh, I think so 08:22:16 <zhouya> I think so 08:22:25 <huzhj> because we have already merge the pxe rpm update into mitaka 08:22:43 <zhouya> For we maybe deploy openstack of mitaka version 08:24:47 <huzhj> zhouya: another one PS need to wait: #link https://review.openstack.org/#/c/410491/ 08:25:40 <zhouya> yes 08:26:11 <huzhj> you mentioned that https://review.openstack.org/#/c/410491/ should also be merged into mitaka? 08:26:39 <zhouya> exactly 08:26:53 <huzhj> OK, got it 08:27:05 <zhouya> we will read openstack version from globals.yml file of kolla. 08:27:21 <huzhj> OK, anything else about this topic? 08:27:27 <zhouya> Which is also needed by mitaka version. 08:27:28 <zhouya> no 08:28:01 <huzhj> #topic OpenStack Version management 08:28:58 <huzhj> I simply look through; 08:28:58 <huzhj> I simply looked through the version API 08:29:22 <huzhj> find that , it is not hard for us to resue it for Kolla 08:30:10 <huzhj> basically we need to add a version before add cluster, then add cluster which using that version file. 08:30:50 <huzhj> then we can even add another version , then call upgrade API to do openstack upgrading 08:31:44 <huzhj> daisyclient/daisyclient/v1/versions.py has the add() function for adding a version 08:31:58 <zhouya> great 08:32:13 <huzhj> #info it is not hard for us to resue it for Kolla , basically we need to add a version before add cluster, then add cluster which using that version file. 08:32:20 <huzhj> #info daisyclient/daisyclient/v1/versions.py has the add() function for adding a version 08:32:55 <huzhj> But be ware that we need put the version file to /var/lib/daisy/kolla/ before calling that API 08:33:17 <huzhj> just like tecs, it puts version file to /var/lib/daisy/tecs 08:33:47 <zhouya> yes 08:34:24 <huzhj> there is a trick, bad trick here in the daisyclient versions 08:34:34 <huzhj> only file name save in DB, not the full absolute path!!! 08:35:12 <zhouya> we could modify this in opensource code 08:35:52 <huzhj> So, later, when we trying to use a version file which metadata saved in db , we should add the /var/lib/daisy/kolla/ as the prefix 08:36:01 <luyao2> ues 08:36:41 <huzhj> Since the code is located in the kolla backend dir, not a core code, it is OK to hard code the /var/lib/daisy/kolla/ dir in that code. 08:37:54 <huzhj> But the version function here we discussed may not meet the requirement of escalator @kongwei 08:38:10 <kongwei> :( 08:38:40 <huzhj> escalator, as a general layer, should not rely on the version metadata defined per installer 08:39:12 <huzhj> for example , daisy may describe version like newton-201610101234 08:39:27 <huzhj> but other installers may have their own way 08:40:18 <huzhj> I think escalator needs the exact version of a component such as nova... 08:41:10 <huzhj> Or, escalator can make a verrsioning method that force all installer to follow, @kongwei 08:42:17 <zhouya> It will be a little hard to make a versioning method that force all installer to follow 08:44:02 <huzhj> Let's discuss this offline, or gather more info in OPNFV community 08:44:39 <luyao2> yes 08:45:00 <kongwei> yes 08:46:38 <huzhj> #info OK, so for the next steps to adapt the version management function we can probably do the following things 08:46:54 <huzhj> 1) do not activate(extract the kolla image tgz tarball) during daisy installation phase 08:46:54 <huzhj> 2) add/list/delete version file 08:46:54 <huzhj> 3) pass version file id when creating cluster 08:46:54 <huzhj> 4) activate a specific version file(extract the kolla image tgz tarball) when creating cluster 08:46:54 <huzhj> 5) kolla deploy... 08:47:46 <luyao2> good 08:49:18 <huzhj> we can even do upgrade like this: 08:49:20 <huzhj> 1) add another version file (new version) 08:49:20 <huzhj> 2) call upgrade cluster API, passing the new file id. 08:49:20 <huzhj> 3) deactivate the old version file (docker rmi) 08:49:20 <huzhj> 4) activate the new version file(extract the kolla image tgz tarball) 08:49:20 <huzhj> 5) kolla upgrade 08:50:07 <huzhj> all the rough & tough work about upgrading will be done by Kolla :) 08:50:39 <huzhj> #info 1) do not activate(extract the kolla image tgz tarball) during daisy installation phase 08:50:40 <huzhj> #info 2) add/list/delete version file 08:50:40 <huzhj> #info 3) pass version file id when creating cluster 08:50:40 <huzhj> #info 4) activate a specific version file(extract the kolla image tgz tarball) when creating cluster 08:50:40 <huzhj> #info 5) kolla deploy... 08:50:44 <huzhj> #info we can even do upgrade like this: 08:50:45 <huzhj> #info 1) add another version file (new version) 08:50:45 <huzhj> #info 2) call upgrade cluster API, passing the new file id. 08:50:45 <huzhj> #info 3) deactivate the old version file (docker rmi) 08:50:45 <huzhj> #info 4) activate the new version file(extract the kolla image tgz tarball) 08:50:45 <huzhj> #info 5) kolla upgrade 08:51:08 <huzhj> any opinion? 08:51:29 <zhouya> maybe first method is better. 08:52:30 <zhouya> for if we do like second method,the openstack service will stop,and the user will affect. 08:52:47 <huzhj> may be you misread, zhouya, there are not two methods to be choose, there are two different functions 08:52:58 <huzhj> one is installing ,other is upgrading 08:53:01 <luyao2> we can add version first 08:53:44 <huzhj> forgot to add modifying openstack_release parameter in global.yml 08:54:02 <luyao2> dashboard also need change 08:54:14 <luyao2> accord to inner 08:54:25 <huzhj> #info upgrading sequence , ver2 08:54:25 <huzhj> #info 1) add another version file (new version) 08:54:25 <huzhj> #info 2) call upgrade cluster API, passing the new file id. 08:54:25 <huzhj> #info 3) deactivate the old version file (docker rmi) 08:54:25 <huzhj> #info 4) activate the new version file(extract the kolla image tgz tarball) 08:54:25 <huzhj> #info 5) modify openstack_release parameter in global.yml 08:54:25 <huzhj> #info 6) kolla upgrade 08:54:40 <huzhj> luyao2: yes, dashboard 08:55:51 <zhouya> OK,I see 08:56:17 <huzhj> So any idea? 08:56:48 <huzhj> may be new idea will come up during the impl. 08:57:08 <luyao2> I think it is ok 08:57:56 <huzhj> OK. that is all for this topic 08:58:33 <huzhj> we are running out of time 08:58:40 <huzhj> move to next topic 08:58:44 <huzhj> #topic AoB 09:00:21 <huzhj> if nothing else , let's warp up 09:00:29 <huzhj> have a good weekend 09:00:38 <zeyu> bye 09:00:40 <kongwei> bye 09:00:42 <huzhj> bye 09:00:42 <luyao2> thanks,bye~ 09:00:43 <zhouya> bye 09:00:50 <huzhj> #endmeeting