03:00:17 #startmeeting zun 03:00:18 Meeting started Tue Jan 3 03:00:17 2017 UTC and is due to finish in 60 minutes. The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot. 03:00:19 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:21 The meeting name has been set to 'zun' 03:00:26 pksingh 03:00:29 #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-01-03_0300_UTC Today's agenda 03:00:34 #topic Roll Call 03:00:35 Namrata 03:00:40 Wenzhi 03:00:45 Happy New Year to all 03:00:45 Madhuri Kumari 03:00:49 kevinz 03:01:31 Thanks for joining the meeting pksingh Namrata Wenzhi mkrai kevinz 03:01:38 all, happy new year 03:01:40 Happy New Year all :) 03:01:45 happy new year! 03:01:51 #topic Announcements 03:01:59 i have no announcement 03:02:06 anyone else has announcement? 03:02:22 #topic Review Action Items 03:02:27 1. hongbin start a ML to osc team to discus the name collision issue (DONE) 03:02:33 #link http://lists.openstack.org/pipermail/openstack-dev/2016-December/109259.html 03:03:03 after discussing with the osc team, we agreed to use the keyword 'appcontainer' to represent a zun container resource 03:03:19 e.g. openestack appcontainer create/delete/.... 03:03:37 any comment on this renaming? 03:03:46 thanks hongbin 03:03:54 not beautiful, but acceptable :) 03:03:55 p.s. it is renamed on osc only 03:04:09 LGTM 03:04:13 Namrata: np at all 03:04:31 ok, sounds good 03:04:41 #topic Set etcd as the default DB backend (Wenzhi) 03:04:47 #link https://review.openstack.org/#/c/412756/ 03:04:55 Wenzhi: you want to drive this one? 03:05:04 sure 03:05:41 the code for etcd data model (zun_service, container, image) and etcd db api has already been landed 03:05:51 thanks all for help on code review 03:06:14 and I already submitted a patch to add a new pipeline to test etcd db backend 03:06:20 https://review.openstack.org/#/c/415391/ 03:07:15 I did some manual tests, and found some bugs in etcd api, I have a WIP patch in hand to fix the bugs 03:07:28 will upload for review after the pipeline patch been merged 03:07:32 Wenzhi: What are the rationale to make etcd to default DB? 03:08:16 It will be better to write this in commit message so that reviewers understands the need for it 03:08:17 mkrai: we've discussed that in project plan at the very beginning of Zun project 03:08:33 the main benefit is that etcd is more fast and flexible 03:08:49 mkrai: will do that 03:09:05 I know few of them but it is worth writing in commit message to let others know 03:09:05 Wenzhi: do you have a pointer about the project plan discussion? 03:09:11 Wenzhi: Thanks 03:09:24 containers are different from VMs, the states of them changes a lot 03:10:03 https://etherpad.openstack.org/p/zun-container-state-management 03:10:13 hongbin: the link ^^ 03:10:19 #link https://etherpad.openstack.org/p/zun-container-state-management 03:11:39 Wenzhi: thx 03:11:53 np 03:11:57 I can try to test this feature when Hongbin's multihost patch is landed 03:12:49 that would be great Namrata 03:13:12 Wenzhi: ok, it looks the rational of setting etcd as default is: the container state are changing faster than vm 03:13:23 honbin: yes 03:13:47 Wenzhi: this rational seems valid, but not written down in the etherpad though 03:14:12 will update the etherpad 03:14:18 then, i wanted to get opinions from others 03:14:29 IMO we can take decision on making it default only when we have tested it well 03:14:38 hongbin: Wenzhi What do you think? 03:14:40 all, what do you think about changing the default db to etcd? good idea? bad idea? 03:14:52 mkrai: +1, i need to think about it 03:14:54 mkrai: agreed 03:15:10 Rational seems valid but difficult to say yes now 03:15:18 ok, then we can defer the decision until the etcd backend is well tested 03:15:30 Yes 03:15:35 agree 03:15:38 +1 03:15:44 ok, sound good 03:16:03 next topic 03:16:12 #topic Support multi-host deployment (hongbin) 03:16:18 #link https://blueprints.launchpad.net/zun/+spec/support-multiple-hosts The BP 03:16:23 #link https://review.openstack.org/#/c/415554/ The patch 03:16:38 i have submitted several patches for this bp 03:17:10 the idea is to implement a simple scheduler, and specify the server in rpc 03:17:33 #link https://review.openstack.org/#/c/415554/ the wip patch 03:18:11 in before, the zun-api call zun-compute without picking a server 03:18:37 then, the rpc request was sent to the first zun-compute that picked up the message 03:18:59 after the patch, the zun-api will pick a server to send the request 03:19:24 the goal is to make sure the rpc request will send the right host that runs the container 03:19:27 hongbin: What's the filter we are using with this patch? 03:19:28 that is the general idea 03:19:47 mkrai: for scheduling? we didn't use any filter right now 03:19:53 Yes 03:20:04 mkrai: we used a random scheduler, that basically randomly picking a host 03:20:06 So on what basis the compute is choosen? 03:20:23 mkrai: randomly chosen :) 03:20:27 Ok for initial implementation it is fine 03:20:38 yes 03:20:39 we need to extend the scheduler when scheduler bp is implemented , i guess 03:20:48 sure thing ^^ 03:21:05 yes, that could be a future work 03:21:19 agreed 03:21:30 +1 03:21:33 another possibility is to switch to the placement service once it is splitted out from nova 03:22:00 i need to look about placement service 03:22:03 p.s. nova is splitting their scheduler out as a independent placement api 03:22:23 ok 03:22:26 just fyi 03:22:34 that will be best for us 03:22:48 yes, if the placement service is there, we could leverage it 03:22:56 hongbin: is there any link for the discussion? 03:23:32 mkrai: there are several session in hte nova design summit in barcelona 03:23:52 Ok I will look at them 03:23:55 mkrai: i attent some sessions, possibly, there are some etherpads there 03:24:13 hongbin: can we use nova docker driver and our scheduler together, i think no , right? 03:24:57 pksingh: my initial thought is to use force-host option when nova driver is enabled 03:25:34 pksingh: e.g. zun picked a host -> call nova with force-host -> nova creates sandbox in the specified host 03:25:34 hongbin: will it disbale nova scheduler? 03:25:43 pksingh: yes 03:25:52 hongbin: ok seems ok 03:26:06 pksingh: there might be other options to enable nova scheduler, which could be discuss further 03:26:28 ok 03:26:49 any other comment about the multi-host support? 03:27:13 #topic Introduce pod (hongbin) 03:27:19 #link https://blueprints.launchpad.net/zun/+spec/introduce-pod The BP 03:27:33 i will work on this bp after the multi-host bp is done 03:27:50 however, i am happy to offload the work if you interest to implement this feature 03:27:55 just let me know if you do 03:28:04 comments? 03:28:08 hongbin: i can help 03:28:18 pksingh: ack 03:29:03 pksingh: thx, will work with you later on this one 03:29:12 #topic Support interactive mode (kevinz) 03:29:12 hongbin: sure 03:29:18 #link https://blueprints.launchpad.net/zun/+spec/support-interactive-mode The BP 03:29:23 #link https://review.openstack.org/#/c/396841/ The design spec 03:29:28 kevinz: ^^ 03:29:42 I'v finished the tty resize function and escape code decode 03:29:43 https://github.com/kevin-zhaoshuai/container-interactive-client 03:30:14 Now working on integration with zun , 03:30:15 patch will ready this week 03:30:24 awesome! 03:30:46 kevinz: great :) 03:30:50 looking forward to the patch 03:31:19 hongbin: pksingh: OK thanks~ :-) 03:31:32 kevinz: just 2 cents, the first patch doesn't need to be perfect, it could be just a prototype. 03:31:44 agree with hongbin 03:32:06 Yeah, I think so 03:32:11 kevinz: it could help because reviewers could give you earlier feedback based on that 03:32:17 kevinz: ok 03:32:43 kevinz: thanks for your hard work on this one 03:32:57 Good ~ I will firsh implement "zun attach" and then "run" and exec 03:33:14 sound like a good plan 03:33:17 hongbin: My pleasure~ Thanks for your help 03:33:28 np 03:33:40 any other remark on this one? 03:34:01 No more comments now :-) 03:34:23 thanks kevinz 03:34:25 #topic Make Zunclient an OpenStackClient plugin (Namrata) 03:34:30 #link https://blueprints.launchpad.net/zun/+spec/zun-osc-plugin 03:34:34 Namrata: ^^ 03:34:54 I have submitted 4 osc command plugins 03:35:19 and simultaneously working on spec as suggested by stevemar 03:36:08 i see 03:36:17 I will submit the spec this week 03:36:52 Namrata: i think just a simple spec would be enough 03:37:34 okay great. 03:37:48 Namrata: i mean the design of the osc plugin is already clear, no need to spend too much time on the spec 03:37:59 okay 03:38:14 btw, the 4 patches look good 03:38:27 Thanks hongbin 03:38:33 Namrata: thanks for working on this feature 03:38:47 comments from others? 03:39:00 My pleasure.thanks for reviewing 03:39:41 #topic Open Discussion 03:40:07 anyone has additional topic to bring up? 03:40:34 i agree with sudipta view on https://review.openstack.org/#/c/415704/ 03:40:44 can we abandon this patch 03:41:10 I think we all have the same thought on this 03:41:17 pksingh: we can ask the contributor to abandon the patch 03:41:29 yes, i agree 03:41:34 +1 03:42:33 any other topic 03:43:02 ok, all, thanks for joining the meeting 03:43:09 #endmeeting