03:00:02 #startmeeting zun 03:00:03 Meeting started Tue Sep 13 03:00:02 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:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:07 The meeting name has been set to 'zun' 03:00:08 #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-09-13_0300_UTC Today's agenda 03:00:12 #topic Roll Call 03:00:17 Namrata 03:00:19 Madhuri Kumari 03:00:24 shubham 03:00:32 Vivek Jain 03:00:33 haiwei, hi 03:01:10 Thanks for joining the meeting Namrata mkrai shubhams Vivek_ haiwei 03:01:32 Pause a few more seconds for potential participants 03:01:54 btw, yanyanhu cannot attend this meeting, he is travelling this week 03:02:21 ok, let's start 03:02:24 #topic Announcements 03:02:29 1. The zun-ui repo was created (thanks Shu) 03:02:35 #link https://github.com/openstack/zun-ui 03:02:47 2. sudipto shared an apporach to bootstrap Zun development environment 03:02:48 Yay!! Thanks Shu 03:02:52 #link https://github.com/sudswas/zun-docker 03:03:05 shu-mutou: thx 03:03:26 any comments regarding to the annoucement? 03:03:50 Thanks sudipto 03:03:59 sudipto: just mentioned your work :) 03:04:07 hongbin, mkrai thanks! Sorry joined late. 03:04:29 that work needs a lot of work still. But i think i will finish automating everything with docker-compose by end of this week 03:04:42 hongbin, Can we add this to guide? 03:04:53 mkrai: if you want 03:04:57 sudipto : are there any dependencies or prerequisite for this to work ? 03:05:10 shubhams, just to have docker installed. 03:05:19 wherever you are trying this. 03:05:24 sudipto : cool , great work! 03:05:41 I think its good to add it. 03:05:52 mkrai: sure 03:06:01 #topic Review Action Items 03:06:07 1. Create a bug to disable devstack job if a patch is a spec or doc change (DONE) 03:06:12 #link https://bugs.launchpad.net/zun/+bug/1622244 03:06:14 Launchpad bug 1622244 in Zun "Diable devstack job for a doc-only change" [Undecided,New] - Assigned to prameswar (prameswar) 03:06:19 2. hongbin help shu-mutou to create a new repo for ui (DONE by Shu) 03:06:26 #link https://review.openstack.org/#/c/366489/ 03:06:39 That is all for AIs 03:06:50 #topic Nova integration (Namrata) 03:06:55 #link https://blueprints.launchpad.net/zun/+spec/nova-integration The BP 03:06:59 #link https://etherpad.openstack.org/p/zun-containers-nova-integration The etherpad 03:07:20 Namrata: ^^ 03:07:27 yes 03:07:36 The updated patch is up for reviw 03:08:11 #link https://review.openstack.org/#/c/354553/ 03:08:43 hi 03:08:55 Namrata: i have another proposal which might touch a little about nova 03:09:20 adisky: hey, thanks for joining 03:09:28 :) 03:09:31 Namrata: https://review.openstack.org/#/c/365754/ 03:09:31 okay .whats the proposal 03:10:38 Namrata: i guess your proposal will depends on the decision of the other proposal 03:10:54 Namrata: we will discuss the network proposal later 03:10:59 okay sure 03:11:21 Any other comment regarding to the nova integration spec? 03:11:27 no 03:11:45 (^^)/ sorry, I'm late. 03:12:02 shu-mutou: hey, np. thanks for coming 03:12:07 #topic Support interactive mode 03:12:13 #link https://blueprints.launchpad.net/zun/+spec/support-interactive-mode 03:12:29 i will explain this bp a bit 03:12:48 in docker, there is an interacive mode: docker run -it ubuntu /bin/bash 03:13:09 the bp is about doing something similar in zun 03:13:42 for example, zun run --image ubuntu --interactive 03:13:42 hongbin, waiting for your assessment on how we will do it :) 03:14:05 sudipto: i haven 03:14:14 sudipto: i haven't investigate on it yet 03:14:15 given the zun run can happen from anywhere 03:14:41 Ok i feel at this time, that it's not possible to do. 03:14:47 just want to get feedback on whether this is a good idea 03:15:01 sudipto: why? 03:15:12 you can't launch an interactive session just like docker does by running this command from a remote machine 03:15:30 you could do so via VNC - but that won't probably replicate the exact same behavior/ 03:15:31 ? 03:15:47 sudipto: but swarm did that 03:15:51 docker does it by attaching a serial console to the process locally 03:16:10 ok - then i am least knowledged, i should find out how swarm did it. 03:16:40 yes, that is part of the job of the bp owner (if someone interest to take the bp) 03:16:54 I like the idea, but yes we have to look at the implementation details 03:17:37 I will do the investigation 03:17:50 sudipto: thx 03:18:13 sudipto: i just wanted to ask if there is a volunteer to take the work :) 03:18:30 hongbin, yeah i can take it and let you know if this is conclusive. 03:19:03 ok, then we can wait for sudipto to do an initial investigation, then re-discuss it at the next meeting 03:19:11 Sure thing. 03:19:26 #topic Container image store 03:19:32 #link https://blueprints.launchpad.net/zun/+spec/glance-integration 03:19:38 #link https://etherpad.openstack.org/p/zun-container-image 03:19:57 we discussed this at the last meeting 03:20:50 at the last meeting, we discuss a solution: 03:21:14 solution 1: pull image from glance first, if miss, pull from docker hub 03:21:33 then, somebody proposal an alternative solution 03:22:02 solution 2: define a list of repo to pull images, and support it as configurable values 03:22:34 for example, there is config like ['dockerhub', 'glance'], then image will be pulled form docker hub first 03:22:59 finally, the glance ptl suggested to leverage the location feature from glance 03:23:15 solution 3: leverage location feature from glance 03:23:35 What is that location feature? 03:23:38 hopefully, i summarize everything correctly 03:24:01 mkrai: i don't know it in details, here is the general idea 03:24:17 mkrai: glance image has an attribute called "locations" 03:24:37 mkrai: it defines a list of locations to pull the glance image 03:24:53 mkrai: for example [swift://...., http://...] 03:25:23 So it can pull from docker hub also? 03:25:25 mkrai: also, glance has a configure called location strategy 03:25:51 mkrai: the location strategy will decide how to pull the image based on a location list 03:26:19 mkrai: re. docker hub, we needs a backend for glance to support docker hub 03:27:26 so, if we choose solution #3, the first thing we needs to do is to contribute a patch to glance to support docker hub as a backend 03:27:44 Ok got it. If glance can support all possible solutions, then it better to go with #3 03:27:50 hongbin : we will provide the user of zun api to provide the link location or it will be internally managed by zun ? 03:28:27 Then we have only one solution which will be easy to maintain 03:28:35 shubhams: i think it will internally defined by operators 03:29:10 shubhams: users just needs to specify the name of hte image, then zun / glance will decide how to pull it 03:29:26 hongbin, is anyone working on this bp? 03:29:50 mkrai: as far as i know, nobody is working on that so far 03:29:58 Ok I will take it 03:30:26 hongbin : what if as an operator I want to access image from a specific repo (local or remote whatever) 03:30:30 Do we have all this information on etherpad or anywhere? 03:30:49 mkrai: assigned it to you 03:30:49 mkrai : I can work on this with you 03:31:01 Thanks hongbin shubhams 03:32:00 shubhams: good question (what if as an operator I want to access image from a specific repo) 03:32:27 shubhams: frankly, i don't have a perfect answer for that 03:32:46 sudipto: what is your opinions? 03:33:08 i tend to believe the operator should have the flexibility 03:33:20 That was the reason, I proposed a "configure repo" kind of solution in last meeting 03:33:23 let's gather our thoughts on the ether pad? 03:33:30 and decide it eventually? 03:33:45 +1 sudipto for etherpad 03:33:50 #link https://etherpad.openstack.org/p/zun-container-image 03:34:05 this one is the old discussion 03:34:06 No one from the china team joined today? 03:34:12 want to reuse that one or create a new one? 03:34:18 (sorry if you had announced this before) 03:34:28 sudipto: yanyanhu is in travel this week 03:35:02 ok 03:35:14 wenzhi, 03:35:29 he didn't seem to be here today 03:35:33 ok...np 03:36:11 ok, all let's forward your input to the etherpad: https://etherpad.openstack.org/p/zun-container-image 03:36:21 hongbin : sure 03:36:50 the discussion in that etherpad might be outdated, remove it if you want 03:37:36 ok, next topic 03:37:37 #topic Container network 03:37:43 #link https://blueprints.launchpad.net/zun/+spec/neutron-integration 03:37:48 #link https://review.openstack.org/#/c/365754/ 03:38:07 we discussed this one at the previous meeting as well 03:38:17 let me do a recap 03:38:46 the proposal is about using nova to create a sandbox container 03:39:16 the sandbox container is an empty container, but with neutron ports attached (with network, ip) 03:39:56 all containers created in zun will go into sandbox containers 03:40:07 that is 03:40:19 in zun, create a container will do two things 03:40:27 1. call nova to create a sandbox container 03:40:48 2. have zun-compute to create a zun container, by using the namespace of the sandbox container 03:41:12 the point is to reuse nova to do the networking, scheduing, etc. 03:41:35 basically, the idea is to re-use everything in nova 03:41:57 however, containers are created by zun API 03:42:13 that is all 03:42:14 hongbin, How is this sandbox container created in nova? 03:42:15 and i had an objection towards it - because that makes us dependent on nova...however i would like to also get a sense of how much nova code is applicable as is for this work... 03:42:36 that is via the nova-docker driver i thought? 03:42:42 to answer mkrai 03:43:02 I have an objection using nova-docker as it is not maintained anymore 03:43:07 mkrai: that is something similar as how a instance is created in nova 03:43:39 hongbin, have a question, both the sandbox container and zun container will be created on the same host(vm or baremetel)? 03:43:41 sudipto: the code to allocate IP address, securtiy group, firewall 03:44:17 haiwei: yes, they have to be in the same host 03:45:17 sudipto: want to listen to your opinions more, what are the disadvantages of depending on nova? 03:45:20 hongbin, so can zun takes over that sandbox container directly, not create a new one again 03:46:19 hongbin, depending on if we are using nova-docker - it has not future. IF we have problems with the nova code that we will use for containers - we are in trouble again. 03:46:30 Lest - if someone just wants to use zun - they will have to install nova as well 03:46:43 haiwei: i think no, zun will create another container in the namespace of the sandbox container 03:47:18 sudipto: i see 03:47:23 sudipto, I think it will be important to install nova anyhow, may be in future we would need it to run host for our containers 03:48:03 mkrai, run host means? 03:48:13 Personally I feel its ok to reuse nova code 03:48:36 sudipto, VMs where we run our containers 03:48:57 sudipto: to address your concern about dependency on nova, i revised the proposal as follow 03:49:17 sudipto: introduce a sandbox driver, where could have multiple implementation, and nova is hte default implementation 03:49:27 sudipto: would that address your concern? 03:49:50 hongbin, yeah that works :-) 03:50:03 cool 03:50:03 in the world of pluggable configurations - everything seems to fit in well :D 03:50:38 mkrai, running containers inside VMs doesn't mean our code has to dependent on the guy who creates the container IMHO. 03:50:49 but we are kinda settled on this now! Thanks! 03:51:28 any other question / concern about this proposal? 03:51:54 I will have a look at the spec 03:52:03 Thanks hongbin 03:52:21 mkrai: yes, i will revise the spec later 03:52:45 and discuss it again if there is any concern 03:52:59 ok, that's it for this topic 03:53:05 #topic Open Discussion 03:53:33 any other topic that needs to be discussed? 03:54:10 if nothing, let's end this meeting a little earlier 03:54:30 nope 03:54:30 thanks all for joining this meeting, the next meeting is next week the same time 03:54:37 #endmeeting