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