03:00:05 #startmeeting zun 03:00:06 Meeting started Tue Jan 10 03:00:05 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:07 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:09 The meeting name has been set to 'zun' 03:00:12 #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-01-10_0300_UTC Today's agenda 03:00:14 o/ 03:00:16 #topic Roll Call 03:00:19 Namrata 03:00:24 pksingh 03:00:43 kevinz 03:00:48 lakerzhou 03:00:54 wenzhi 03:01:11 Thanks for joining hte meeting sudipto_ Namrata pksingh kevinz lakerzhou Wenzhi 03:01:15 Let's start 03:01:20 #topic Announcements 03:01:32 i have no announcement, anyone else has? 03:01:49 #topic Review Action Items 03:01:50 none 03:01:56 #topic Support multi-host deployment (hongbin) 03:02:02 #link https://blueprints.launchpad.net/zun/+spec/support-multiple-hosts The BP 03:02:07 #link https://review.openstack.org/#/c/415554/ The patch 03:02:21 i have been working on this bp last week. 03:02:32 right now, all the patches were submitted 03:02:43 and they are under review 03:02:51 that is all from me 03:03:13 any comment? 03:03:38 ok, then next topic 03:03:46 #topic Cinder integration (diga) 03:03:47 hongbin: will look into it today 03:03:57 pksingh: ack. thx 03:04:02 #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration The BP 03:04:07 #link https://review.openstack.org/#/c/417747/ The design spec 03:04:17 it looks diga is not here 03:04:21 let's table this one 03:04:34 btw, i saw he submitted a spec for that 03:04:59 oh, it is the link above 03:05:18 anyone is welcomed to review his patch 03:05:22 ok, next one 03:05:28 #topic Support interactive mode (kevinz) 03:05:33 #link https://blueprints.launchpad.net/zun/+spec/support-interactive-mode The BP 03:05:39 #link https://review.openstack.org/#/c/396841/ The design spec 03:05:43 kevinz: ^^ 03:05:52 Hi Hongbin 03:06:03 hey 03:06:16 I have a question about zun-api talk to docker daemon 03:06:37 go ahead 03:07:08 Need to use "resize" command to Docker, will it implement by zun-api--> docker daemon or zun-api -->zun-compute -->docker daemon 03:07:38 i don't have a good answer for that 03:07:56 need to do some investigation, will work with you after the meeting 03:08:13 If use "zun-api --> docker daemon", in zun-api side need to add a httpclient for it 03:08:14 OK 03:08:39 is re-size relevant to the interactive mode discussion? 03:08:49 sudioto_: yeah 03:09:17 resize the tty session size so that it can change according to users' local terminal 03:10:05 https://docs.docker.com/engine/reference/api/docker_remote_api_v1.24/#/resize-a-container-tty 03:10:26 imho, the zun-api never should talk to the docker daemon directly because the driver abstraction is done at the compute layer...not at the API layer. So compute is the gateway to the runtime. 03:11:37 i guess interactive mode doesn't have to use the driver abstraction? 03:12:08 not sure right now, need to look into it 03:12:25 right I use zun-api talk to docker daemon directly to get the websocket link, 03:12:55 typically the API would run on the controller node, so are you suggesting contacting a docker daemon on a remote machine via http in that case? Also - does the API become aware of various drivers eventually? 03:13:04 like today it's docker, tomorrow it could be something else. 03:13:55 good point 03:14:38 perhaps, make a call to zun-compute to get the connection information first, then use hte connection info to connect interactively 03:15:22 Yeah that may be a good solutions for this 03:15:50 there might be other options 03:16:06 So CLIS--> Zun-api --> zun-compute to get he websocket link? 03:16:26 yes 03:16:40 And CLIS--> Zun-api --> zun-compute to resize tty 03:17:16 That will be easy for tty to resize:-) 03:17:33 ok, let's discuss it later 03:17:39 OK 03:17:43 move on 03:17:50 #topic Make Zunclient an OpenStackClient plugin (Namrata) 03:17:56 #link https://blueprints.launchpad.net/zun/+spec/zun-osc-plugin The BP 03:18:00 Namrata: ^^ 03:18:11 hi all.. 03:18:56 i have added the patches for container API endpoints :Commands support 03:19:01 and they are up for review 03:19:16 yes, i saw a serious of patches 03:19:25 all are great work! 03:19:41 Furthermore I will be working on Image Api endpoint commands 03:19:45 thanks hongbin 03:20:27 Namrata: ack 03:20:49 thanks hongbin.Nothing to add more from my side 03:21:00 Namrata: i think the image api hasn't been fully implemented yet... 03:21:07 okay 03:21:18 so what do you suggest 03:22:11 Namrata: perhaps skip the image api for now, and consider this bp as implemented 03:22:23 okay sounds good 03:22:27 Namrata: i think all the container api are implemented, right? 03:22:28 thanks 03:22:35 great 03:23:00 Namrata: if you are looking for next task, you can ping me after 03:23:10 yes the etherpad which I created 03:23:12 https://etherpad.openstack.org/p/zunclient_openstack-client-cli 03:23:26 the listed commands are implemented 03:23:35 awesome!! 03:23:36 yeah sure hongbin 03:23:46 ok 03:23:57 all, any comment about the osc bp? 03:24:11 its good work :) 03:24:35 indeed 03:24:38 thanks pksingh 03:24:48 #topic Open Discussion 03:25:05 anyone has topics to discuss? 03:25:36 hongbin: i just wanted to discuss about fuxi work by diga 03:25:59 cant be introduce an api for volume create and then attacha that volume to conatiner 03:26:04 pksingh: it looks diga is not here, but we can have a pre-discussion now 03:26:42 pksingh: i think docker has api to create/attach volumes 03:27:19 yes, just using that API and fuxi driver, can we expose our own rest API for volume create 03:27:26 pksingh: fuxi doesn't have any api, it is just a docker plugin, so that when you call api in docker, it translate it to api calls to cinder 03:28:02 fuxi intends to be a docker only broker? 03:28:14 hongbin: yes, i understand that 03:28:15 sudipto_: right now, it is docker only, 03:28:29 pksingh, the api should be in cinder though isn't it? 03:28:34 sudipto_: in the future, i am not sure yet, the roadmap is under discuss 03:29:07 adding another API layer in fuxi, would mean we have two different APIs... 03:29:29 hongbin: i think this is the same way other drivers like flocker work, 03:29:38 isn't zun going to be interacting with cinder eventually? which would talk to docker? 03:29:45 via fuji. 03:29:54 * sudipto_ did not read the spec yet 03:29:57 sudipto_: both options are under consideration 03:30:17 what diga proposed is to using fuxi, which is the second option 03:31:20 cinder already has a lot of storage vendor support, so i thought the flow could be something like : 1. Ask cinder for volumes from zun. Cinder creates the volume in the backend 2. Cinder gives the volumes to fuxi . 3. Fuxi does the attachment. 03:31:50 sudipto_: yes, that is totally possible 03:32:02 sudipto_: but we need to maintain the multitenancy too 03:32:25 multi-tenancy is maintained at cinder for the volumes... 03:32:26 yes, one thing to note is that fuxi doesn't have multi-tenancy (too bad) 03:32:52 no? 03:33:01 how fuxi works is writing down the admin credential to a config file, then all the volumes were created in the admin tenant 03:33:05 thats why i asked too maintain the volume records with tenants in our db 03:33:46 hongbin: ohh, then i think this will not work 03:33:48 yes, that means we need to skip fuxi if we wanted multi-tenancy 03:34:05 I am not sure why fuxi is aware of multi-tenancy, or has to be aware of it. 03:34:27 to me it appears to be low level in comparison to zun or cinder (sorry i have to read more maybe) 03:34:34 sudipto_: well, if you create a volume, you have to specify the tenant of the volume? 03:34:48 hongbin, that happens at the cinder layer... 03:35:28 sudipto_: but zun need to use a tenant credential to interact with cinder? 03:36:29 sudipto_: but zun can pass down the user's context to cinder, that is fine 03:36:43 hongbin, yeah something like that. 03:36:48 sudipto_: but docker doesn't pass down the user's contex to its plugin (fuxi), that is hte problem 03:37:23 ok need to understand this better...will talk to you about this. 03:37:43 the problem is fuxi doesn't get any context passed from docker, so it has to use the admin credential in config file 03:37:50 ok 03:37:57 thanks hongbin for clarifying :) 03:38:26 sudipto_: pksingh : frankly, we can just skip fuxi if we wanted multi-tenancy 03:39:02 that is the same problem with kuryr right now (kuryr doesn't support multi-tenancy as well) 03:39:10 we can discuss that further later 03:39:15 hongbin: right now it seems so 03:39:27 pksingh: ? 03:39:36 hongbin: yes sure 03:39:43 we can discuss later 03:39:53 thanks for explaining 03:39:56 np 03:40:06 any other topic to be discuss? 03:40:35 ok, all. thanks for joining the meeting 03:40:38 #endmeeting