03:00:05 <hongbin> #startmeeting zun
03:00:06 <openstack> Meeting started Tue Sep 20 03:00:05 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:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:09 <openstack> The meeting name has been set to 'zun'
03:00:14 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-09-20_0300_UTC Today's agenda
03:00:20 <hongbin> #topic Roll Call
03:00:24 <Namrata> Namrata
03:00:30 <shubhams> Shubham Kumar Sharma
03:00:31 <eliqiao> eliqiao
03:00:32 <Wenzhi> Wenzhi
03:00:32 <mkrai> o/
03:00:44 <kevinz> o/
03:00:45 <adisky> aditi
03:00:45 <yanyanhu> hello
03:00:46 <Vivek_Jain> Vivek Jain
03:01:05 <yuanying> Otsuka, Motohiro
03:01:25 <hongbin> Thanks for joining hte meeting Namrata shubhams eliqiao Wenzhi mkrai kevinz adisky yanyanhu Vivek_Jain yuanying
03:01:34 <hongbin> #topic Announcements
03:01:42 <hongbin> I have no announcement
03:01:49 <hongbin> anyone else has?
03:02:04 <hongbin> #topic Review Action Items
03:02:07 <hongbin> none
03:02:11 <hongbin> #topic Nova integration (Namrata)
03:02:17 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/nova-integration The BP
03:02:21 <hongbin> #link https://review.openstack.org/#/c/354553/ The proposed spec
03:02:25 <hongbin> Namrata: ^^
03:02:50 <Namrata> hi
03:03:02 <Namrata> was reading the comments about the fate of nova docker
03:03:31 <Namrata> not sure what should i do next
03:03:48 <hongbin> Namrata: maybe give the team a summary of the status
03:04:20 <hongbin> and brief what comments you got from the reviewers
03:04:29 <Namrata> okay
03:05:38 <Namrata> i havent read the comments yest
03:05:40 <Namrata> yest
03:05:47 <Namrata> can we discuss this in open meeting
03:05:53 <hongbin> ok
03:06:14 <hongbin> then, talk this topic
03:06:18 <hongbin> next one
03:06:21 <hongbin> #topic Support interactive mode
03:06:28 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/support-interactive-mode
03:06:53 <hongbin> the proposal is about whether to support interactive mode for container
03:07:20 <hongbin> for example, in docker, users can enter a container with : docker run -it ubuntu /bin/bash
03:07:34 <hongbin> i am thinking whether it makes sense for zun
03:07:47 <hongbin> to support the same
03:07:52 <hongbin> thoughts?
03:08:05 <yanyanhu> hongbin, one question is how it is done for container created in remote host?
03:08:24 <hongbin> yanyanhu: sudipta asked the same question at the last meeting
03:08:38 <yanyanhu> ^
03:08:39 <hongbin> yanyanhu: i don't know how right now, this needs investigation
03:08:44 <yanyanhu> I see
03:08:57 <hongbin> i know swarm / k8s did it
03:09:19 <hongbin> just need to investigate how these COE did it
03:09:56 <yanyanhu> so the problem become what kind of interface this interaction is done through
03:10:04 <yanyanhu> yes
03:10:18 <hongbin> i see
03:10:40 <hongbin> ok, this bp needs a volunteer to investigate
03:10:56 <hongbin> let me know if anyone interest to take the bp
03:11:07 <adisky> i will investigate
03:11:13 <hongbin> adisky: thx
03:11:38 <hongbin> #action adisky investigate how to support interactive mode to enter container
03:11:41 <adisky> :)
03:11:52 <hongbin> adisky: thanks for your volunteer
03:12:03 <hongbin> ok, next one
03:12:06 <hongbin> #topic Container image store
03:12:11 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/glance-integration
03:12:16 <hongbin> #link https://etherpad.openstack.org/p/zun-container-image
03:12:25 <hongbin> mkrai: flwang ^^
03:12:35 <flwang> o/
03:12:41 <mkrai> I and shubhams did discussion last week
03:13:09 <mkrai> And we feel option 3 is best solution for it that is supporting both glance, docker hub and registry
03:13:25 <mkrai> As glare and glance both doesn't fit in our requirements
03:13:45 <hongbin> mkrai: maybe a brief recap of what is option 3?
03:13:58 <mkrai> Additionally we feel that we can have a new resource in Zun that is repo which can be used to manage resources
03:14:08 <mkrai> Yes sure hongbin
03:14:29 <flwang> yep, what's the option 3?
03:14:48 <shubhams> Option#3 is to use glance
03:14:53 <mkrai> Option #3 explains that we support all 3 possible options to store images that is glance, docker hub and docker registry
03:15:25 <mkrai> And repo will be selected based on namespaces
03:15:41 <flwang> shubhams: mkrai: seems what you're talking are different
03:16:13 <shubhams> flwang : no no , I was talking the same but didnt write my second statement as mkrai finished it :)
03:17:03 <shubhams> Basically in last meeting we discussed that we should have repositories for different use cases
03:17:06 <flwang> for docker hub and docker registry, seems clear and straightforward
03:17:16 <flwang> could you pls explain the glance part?
03:17:36 <shubhams> OK.
03:17:53 <mkrai> flwang, We haven't looked on how we gonna support layering in glance
03:18:19 <hongbin> the layering can be a future work (i think)
03:18:20 <mkrai> But yes for first use case that is just storage of image, we do it same way as nova-docker does
03:18:31 <mkrai> That is storing tar file of images
03:19:39 <flwang> does that mean we don't need any change of glance?
03:19:47 <mkrai> What I feel is that it depends on operator and their use case
03:19:53 <flwang> because seems like it's just a normal simple glance user case
03:20:02 <mkrai> If they need layering they should go for later two options
03:20:08 <mkrai> Yes flwang
03:20:27 <mkrai> Do you feel is it feasible to support such features in glance?
03:20:59 <flwang> mkrai: it's very hard to do in glance, because it's like implement a git/version control system in glance
03:21:04 <flwang> you know what i mean
03:21:05 <mkrai> Glance is just for managing VM images so they will not support features like layering
03:21:24 <mkrai> Yes flwang that's what I am saying
03:21:30 <flwang> mkrai: you got it :)
03:21:43 <mkrai> And glare aims to do it but nothing has been done yet
03:22:02 <mkrai> So of course we can support glare when it has the support
03:22:14 <mkrai> Thoughts?
03:22:32 <adisky> agreed with you mkrai
03:22:33 <flwang> IIUC, even glare supports the layering, it does still need to work with glance to provide the whole image serivce flow
03:23:31 <mkrai> Glare don't have the layering support yet
03:23:51 <mkrai> Glare also aims to support multiple backend like docker hub and registry
03:25:07 <hongbin> i think we need to get the tar file working first, don't think we need to worry the layering for now
03:25:27 <mkrai> Yes hongbin I totally agree
03:25:42 <mkrai> That I and shubhams will do it this week
03:26:06 <mkrai> Do a PoC to check tar support in glance for container images
03:26:16 <hongbin> mkrai: i think the key we discussed at the previous meeting is how to support both glance and docker hub at the same time
03:26:32 <mkrai> Namespaces, isn't it?
03:26:42 <hongbin> mkrai: ok
03:26:53 <mkrai> Namespace is a prefix to the images like glance/busybox
03:27:29 <mkrai> hongbin, Also what do you feel about new repo resource?
03:27:31 <hongbin> mkrai: i think both sudipta and yanyanhu challenged this approach
03:27:53 <mkrai> I see
03:28:10 <mkrai> sudipto, Hi
03:28:26 <sudipto> mkrai, hello, extremely sorry for being late.
03:28:30 <mkrai> We are discussing about the namespaces feature with container image
03:28:38 <sudipto> Sure.
03:28:50 <mkrai> Do you have any concern on it?
03:28:59 <mkrai> yanyanhu, ^^
03:29:57 <yanyanhu> hi, mkrai, for new repo resources?
03:30:19 <mkrai> No yanyanhu
03:30:31 <mkrai> i think both sudipta and yanyanhu challenged the approach of namespaces
03:30:47 <mkrai> Namespace is a prefix to the images like glance/busybox
03:30:56 <yanyanhu> ah, I recalled.
03:31:18 <mkrai> Will be needed to support both glance and docker hub at the same time
03:31:20 <yanyanhu> I thought we should try different repos with sequence
03:31:27 <yanyanhu> e.g. glance first, than docker hub, etc.
03:31:54 <mkrai> yanyanhu, I feel user should have power to pick any repo
03:32:02 <yanyanhu> yes, mkrai, agree with this
03:32:14 <mkrai> Also your implementation will incur extra time
03:32:16 <shubhams> yanyanhu : I agree with you but what about giving this  choice to admin like : I want to pull from docker hub or I want to pull from glance or local repo
03:32:27 <mkrai> Look into glance, then look into docker hub etc
03:32:30 <yanyanhu> so should not be completely automatic choosing
03:32:40 <mkrai> shubhams, +1
03:32:50 <yanyanhu> if user provides namespace, we should follow it
03:33:14 <yanyanhu> makes sense to me
03:33:31 <hongbin> flwang: you get the idea of namespace?
03:33:47 <sudipto> It all depends on what we eventually want to achieve too. Do we want to support an orchestration engine based out of docker (let's say something like k8s or swarm) - and we eventually want to use their templates. In such cases you would have to change it to work with zun. That's all was my concern.
03:33:50 <yanyanhu> but we should not enforce user to provide namespace prefix, right?
03:34:20 <shubhams> yanyanhu : so you want to say that : if user has not asked an imnage  for any specific repo then zun be able to judge and fetch it (based on our priorities/order) ?
03:34:34 <yanyanhu> yes, shubhams
03:34:51 <yanyanhu> priorities can be configured in zun.conf maybe
03:34:57 <sudipto> well i think them middle ground could be - you ask the user to explicitly specify it - if they want a specific repo - else it can go to the default repo order and pick up stuff.
03:35:31 <sudipto> if i as a user specify glance/busy-box - it picks it up explicitly from glance.
03:35:45 <yanyanhu> sudipto, exactly
03:35:50 <sudipto> However if i just say busy-box - and zun.conf has docker hub as the default registry - it goes and picks it up from docker hub.
03:36:28 <mkrai> I think everyone has same opinion
03:36:30 <yanyanhu> sudipto, yes, that priorities/order should be configurable
03:36:56 <hongbin> ok, sounds good to me
03:36:58 <sudipto> yanyanhu, agreed.
03:36:59 <shubhams> sudipto: yanyanhu : I agree with your point
03:37:08 <mkrai> Cool :)
03:37:08 <Wenzhi> +1
03:37:38 <hongbin> any other comment ?
03:37:54 <shubhams> Now the question is : what we want to implement first : the scenario where user gives repo name explicitly or the one where zun decides about from where to pick the image from
03:38:38 <eliqiao> pick the repo user specified first then use default.
03:38:49 <sudipto> eliqiao, +1
03:38:51 <eliqiao> maybe configured on zun.conf.
03:39:22 <hongbin> #agree support multiple repo with namespaces, make default repo configurable
03:39:28 <mkrai> I guess let's support glance first, then docker hub with namespaces support
03:39:55 <yanyanhu> agree with mkrai since that means we start from the simplest one
03:40:02 <sudipto> Just to also let you know - right now docker hub itself does not support a universal image format. So for example - if i specify something like busy-box/ppc64le - it will go and map it to the ppc64le namespace on docker hub - otherwise get a x86 based image.
03:40:17 <yanyanhu> namespaces is meaningful only after multiple image backends are supported
03:40:27 <sudipto> so there's already some bit of namespacing in docker hub - with respect to CPU arch.
03:40:27 <shubhams> suipto : good to know about that
03:41:19 <sudipto> But I think, we can take care of that under the hood. as in if the user requests a glance image from a compute node based on CPU arch X - we only go and fetch that image.
03:41:25 <sudipto> which applies to arch X.
03:41:59 <sudipto> instead of asking the user to specify something ugly like glance/busy-box/ppc64le or glance/busy-box/arm
03:42:09 <sudipto> do you guys agree?
03:42:50 <hongbin> yes, could be done later
03:43:04 <sudipto> same goes for the normal case too - if the user specifies busy-box (and it expects zun to take care of everything) - then we should be able to determine the arch of the compute node and request the image as per from docker hub
03:43:26 <mkrai> Yeah that makes sense sudipto
03:43:55 <hongbin> ok, let's advance topic now
03:43:56 <sudipto> I am just looking at a few value adds we can give on top of the docker-registry...anyway yes - it would be an implementation detail we can sort out later.
03:44:12 <hongbin> there is one more topic to discuss
03:44:20 <hongbin> #topic Container network
03:44:26 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/neutron-integration The BP
03:44:31 <hongbin> #link https://review.openstack.org/#/c/365754/ The proposed spec
03:44:53 <hongbin> does anyone has a chance to look at the spec?
03:45:13 <hongbin> or maybe i can summary it here
03:45:23 <mkrai> I had a look
03:45:36 <hongbin> the proposal is about to introduce another concept called "sandbox"
03:45:49 <eliqiao> so sandbox is just a logic name?
03:45:58 <hongbin> a sandbox is actually a docker container
03:46:18 <hongbin> the zun container will sort of run inside a sandbox
03:46:41 <hongbin> so there are two containers
03:46:49 <hongbin> a sandbox container and a zun container
03:47:06 <hongbin> the zun container is requested by end-user to create
03:47:10 <mkrai> Is it zun container inside sandbox container?
03:47:18 <hongbin> mkrai: yes and no
03:47:40 <hongbin> the zun container will join the Linux namespaces of the sandbox container
03:48:03 <hongbin> in particular, using these options on docker run
03:48:05 <hongbin> ``--net=container:<sandbox>``, ``--ipc=container:<sandbox>``
03:48:13 <hongbin> ``--pid=container:<sandbox>`` and/or ``--volumes-from=<sandbox>``
03:48:15 <eliqiao> what about the performance?
03:48:49 <hongbin> eliqiao: let me explain the performance a little
03:49:28 <hongbin> since i am going to propose to use nova to provision sandbox, the performance is the nova
03:49:43 <hongbin> so, sandbox is provisioned by nova
03:49:50 <hongbin> zun container is provisioned by zun
03:50:42 <hongbin> the point is to reuse nova to do whatever nova provided (neutron ports, scheduling, etc.)
03:51:15 <mkrai> And that can be reused by Nova's sandbox?
03:51:21 <hongbin> sandbox is like a vm, it has networking, volumes, resource constraints, etc.
03:51:34 <hongbin> mkrai: i guess yes
03:51:48 <eliqiao> hongbin: I get
03:52:21 <hongbin> thoughts?
03:52:22 <eliqiao> but kinds of waste for create an sandbox
03:52:24 <mkrai> hongbin, I think this will have resource overhead of having 2x containers
03:52:27 <sudipto> I do feel that the sandbox is the step in the right direction because that's how most of the container orchestration engines too are working.
03:52:31 <Wenzhi> I think this approach is reasonable, just like 'join' network mode in docker, and we can avoid copy networking code from Nova
03:52:32 <eliqiao> so they are only sharing one port?
03:52:58 <hongbin> eliqiao: yes, the ports are shared
03:53:24 <hongbin> defnitlely, i agree there is performance overhead
03:53:29 <mkrai> This sandbox container will not be public
03:53:35 <eliqiao> what's the sandbox looks like, what's image it using?
03:53:45 <hongbin> mkrai: no, it is internal
03:54:01 <hongbin> eliqiao: like a 'pause' image used by k8s
03:54:11 <hongbin> eliqiao: an empty docker image that is keep running
03:54:41 <hongbin> eliqiao: and doesn't do anything real
03:54:49 <mkrai> hongbin, I like the idea but we have to write a driver for Zun to create this containers?
03:54:51 <eliqiao> get, thx.
03:55:10 <eliqiao> mkrai: Nova will creat that, hongbin?
03:55:19 <hongbin> mkrai: yes, the sandbox needs to be implemented in zun by a driver
03:55:36 <hongbin> eliqiao: yes, nova is responsible to create the sandbox
03:55:39 <mkrai> Will nova-integration bp help there?
03:56:02 <hongbin> maybe
03:56:29 <hongbin> however, the nova-integation bp is about using nova api to manage container
03:56:45 <hongbin> my proposal is about using nova api to mange sandboxes
03:57:02 <hongbin> which is two independent ideas
03:57:27 <mkrai> Yeah we can revisit the nova-integration bp keeoing this use case in mind
03:57:38 <hongbin> sure
03:58:07 <hongbin> any other comment ?
03:58:30 <mkrai> I will provide my comments on spec
03:58:39 <hongbin> mkrai: thx
03:59:12 <hongbin> #topic Open Discussion
03:59:22 <hongbin> last meeting comment ?
03:59:27 <hongbin> last minutes
03:59:27 <mkrai> Time is up :)
03:59:38 <hongbin> ok
03:59:44 <hongbin> all, thanks for joining the meeting
03:59:48 <hongbin> #endmeeting