03:00:08 #startmeeting zun 03:00:09 Meeting started Tue Aug 16 03:00:08 2016 UTC and is due to finish in 60 minutes. The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot. 03:00:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:12 The meeting name has been set to 'zun' 03:00:13 #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-08-16_0300_UTC Today's agenda 03:00:16 o/ 03:00:18 #topic Roll Call 03:00:30 OTSUKA, Motohiro 03:00:31 Wenzhi 03:01:16 Thanks for joining the meeting sudipto yuanying Wenzhi 03:01:27 Pause a few more seconds for potential attendees 03:02:20 I know Madhuri is not able to join today 03:03:17 OK. Let's start 03:03:22 #topic Announcements 03:03:28 1. I am proposing Sudipta Biswas and Wenzhi Yu to join the core team. Your feedback on the ML are welcome :). 03:03:34 #link http://lists.openstack.org/pipermail/openstack-dev/2016-August/101344.html 03:03:46 #topic Review Action Items 03:03:50 hi 03:03:52 1. hongbin created a BP for multi-tenancy support (DONE) 03:03:55 eliqiao: hey 03:04:01 #link https://blueprints.launchpad.net/zun/+spec/support-multi-tenancy 03:04:15 Thanks Wenzhi for volunteering to take this BP 03:04:19 I'll work on that 03:04:21 hi, sorry just finished another meeting 03:04:30 np :) 03:04:48 yanyanhu: NP. Glad that you are here :) 03:05:28 does multi-tenancy support mean that we can allow mulitple container running on same host? 03:05:37 Wenzhi: For the multi-tenancy BP, what I normally do is to ask the owner to report status every week at the meeting 03:05:44 Wenzhi: Do you mind to do that? 03:05:48 sure thing 03:05:54 Wenzhi: thx :) 03:05:56 np 03:06:09 eliqiao: NO, that is different thing 03:06:25 eliqiao: multi-tenancy support simply means hide containers from other tenants 03:06:37 eliqiao: For example, in Nova, you cannot list VMs from other tenants 03:06:44 okay, seems same as magnum/nova implementation. 03:06:51 yes 03:07:05 we need to consider more since we are containers not VMs 03:07:20 That is correct 03:07:21 for the containers' isolation issue etc. 03:07:35 Yes, isolation is another thing we need to solve 03:07:35 from multi-tenancy per say - we would probably want to define quotas too? 03:07:54 sudipto: Yes, possibly 03:08:14 sudipto: Like how many containers a tenant can create ? 03:08:21 hongbin, yeah 03:08:24 sudipto: that would be a cool feature 03:08:42 definitely, it can be implemented 03:08:48 and then i was thinking, if we want to do a COE implementation - we probably have to have that same quota imposed in a different way for a cluster. 03:09:27 same quota imposed across different COEs? 03:09:46 cluster = sum(containers) . so that could mean two impositions, one on the level of clusters - how many clusters can a user provision + how many containers can be within in. 03:10:07 but both can be independent of each other. 03:10:25 interesting idea 03:11:18 how about different quota for clusters and containers 03:11:29 and then depends on what level of exposure we have - w.r.t IPs - if we want to have quota imposed at the level of services (like k8s) - then it's a different thing vs having it on crude containers. 03:11:52 so yeah - i guess it deserves a ether pad discussion too IMHO. 03:12:10 I'll create that etherpad 03:12:31 Cool. Anything else regarding to the multi-tenancy topic? 03:12:55 are we aiming at segregate the COE implementation completely from the native docker APIs? 03:13:06 -1 to inventing a zun-specific quota management ifra 03:13:20 as in it's an either and or? 03:13:29 https://etherpad.openstack.org/p/zun-multi-tenancy 03:14:00 sudipto: My understanding is we are doing the container api now 03:14:04 Qiming, ideally the quota management should be at the level of keystone, however all the projects seems to have implemented their own ways of doing it right? 03:14:24 sudipto, check this: https://review.openstack.org/#/c/284454/ 03:15:01 Qiming, sigh. I was involved in this effort :) 03:15:11 sadly i don't think it's going to fly. 03:15:37 it is not specific to any individual project ... if openstack doesn't provide quota management, fine, it is a cross-project thing, if there is one, it should be a cross-project solution 03:16:04 agreed. 03:16:09 however, there's none at the m moment. 03:16:13 right, cross-project thing is never easy ... sigh 03:16:20 and delimiter is not going anywhere either. 03:16:35 delimiter ideally should have been done as a keystone API. 03:16:46 However, if you want the latest status, i can get back in the next meeting with the same. 03:17:05 great, don't want to hijack the meeting, :) 03:17:15 Qiming, :) sure. 03:17:18 Seems we can have a new service to deal with quota for all OpenStack service :) 03:17:25 hha 03:17:31 eliqiao, +100 03:17:53 OK. Let's advance topic 03:18:01 #topic Runtimes API design (mkrai) 03:18:12 Madhuri is not able to attend today 03:18:22 However, her patches were landed 03:18:35 The basic runtime API was implemented 03:18:56 For everyone, you could try the runtime API now and feedback are welcome 03:19:21 Just pull the lastest server and client project 03:19:34 yeah, i have been trying to use it - however i was busy doing customer travels the last entire week. I am trying to build this thing in a docker container and see how it behaves. 03:20:02 sudipto: great 03:20:13 Ideally, there is a devstack support to set everyone up 03:20:15 I tried yesterday, work well to create a new container 03:20:18 That might come later 03:20:29 filed a bug for container naming stuff. 03:20:34 s/everything/everyone/ 03:20:38 eliqiao, great. 03:20:47 and seems need to improve exception handling later, but we can do it evently. 03:21:27 OK. any other comments for this topic? 03:21:45 #topic Nova integration (Namrata) 03:21:48 sudipto: FYI, need to run zun-compute as root or docker user because zun-compute uses unix socket to talk with docker daemon 03:21:53 #link https://blueprints.launchpad.net/zun/+spec/nova-integration The BP 03:21:57 #link https://etherpad.openstack.org/p/zun-containers-nova-integration The etherpad 03:22:27 eliqiao, alright, thanks! 03:22:47 It looks Mamrata is not here 03:23:01 However, I saw a spec was uploaded 03:23:19 #link https://review.openstack.org/#/c/354553/ 03:24:29 I looked thought the spec. It looks more details need to be filled at the implementation session 03:25:00 Let's work with Namrata offline in this regards 03:25:14 #topic Container image store 03:25:20 #link https://blueprints.launchpad.net/zun/+spec/glance-integration 03:25:55 This is the BP about a docker image store solution 03:26:34 So far, there is not too much information there 03:26:50 The general idea is to use Glance as contaienr image store 03:27:13 can flwang provide some advanced information from glance? 03:27:20 The difficulty is that Glance don't support layer of images so far 03:27:51 I and flwang talked to the Glance PTL before 03:28:10 It seems it will take a while to land the image layer support in Glance 03:28:34 do we need to hard depend on glance? 03:28:51 eliqiao: there are alternatives though 03:29:09 eliqiao: which is using docker registry 03:29:29 eliqiao: The dackback is the multi-tenancy support is week at docker registry 03:30:15 A third soluation is to implement a private docker registry API as a service 03:30:47 Maybe we could brainstorm all the ideas in an etherpad 03:31:16 +1 03:31:16 #action hongbin creates an etherpad to brainstorm ideas for container image store solution 03:31:29 +1 03:31:45 Any other comments / remarks ? 03:32:20 OK. Then, let's start the open discussion 03:32:25 #topic Open Discussion 03:33:17 sudipto: what do you think about the image store solution? 03:34:13 hongbin, i would think that - we should not invest too much time in dependency resolution for other projects - which in this case is glance. It's easier to go with a private docker registry for starts and build the support around it. 03:34:45 sudipto: I see 03:35:06 because, building this support in glance is a different beast all together. It would also depend on that project's maintainership headache - how comfortable they are with this etc. 03:35:23 and that would slow down our goals. 03:35:31 That is true 03:35:56 If it is not done in Glance, it seems we need to implement one? 03:36:13 and skip Glance? 03:36:24 we can build our own first 03:36:51 i believe you had a talk with Nikhil? 03:36:58 Yes, I had 03:37:06 * nikhil lurks 03:37:13 nikhil: hey 03:37:18 o/ 03:37:18 nikhil, glad to see you? 03:37:24 s/?/! 03:37:28 ha :) 03:37:35 right back at'ya 03:37:46 nikhil, your valuable inputs would help us here :) 03:38:08 you guys planning this for newton? 03:38:11 or ocata? 03:38:23 nikhil: there is no specific deadline 03:38:46 hongbin: I would definitely love to see the requirements list for you guys 03:39:22 hongbin: I am not sure atm to advice either way. The depenency mgmt is something that can be handled by glare 03:39:24 nikhil: you want we list hte requirements here or send it in the ML? 03:39:34 hongbin: a spec would be nice 03:39:45 nikhil: ack 03:39:53 (or a BP if you use that) 03:40:06 sure 03:40:38 nikhil: Thanks for the guidance :) 03:40:42 so nikhil, you basically want us to list down - what we need from the image management project right? 03:40:51 (just to be sure) 03:41:11 hongbin: tbh, I wouldn't recommend a separate solution currently .. because there are many cases where it will become difficult. But best to discuss the details of "whys" and "whats" 03:41:16 sudipto: yeah 03:41:41 ok i should re-visit the task - i was supposed to do with you - around 2 months back :) 03:41:49 ++ 03:41:54 nikhil: get that 03:42:04 we can start with an etherpad and then go to spec if that's what you guys prefer 03:42:35 sure 03:43:49 OK. Looks like nobody else has other topics to discuss? 03:44:09 Then, we can end the meeting earlier 03:44:29 All, thanks for joining the meeting today 03:44:32 #endmeeting