03:00:09 <hongbin_> #startmeeting zun
03:00:10 <openstack> Meeting started Tue Sep  6 03:00:09 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:13 <openstack> The meeting name has been set to 'zun'
03:00:14 <hongbin_> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-09-06_0300_UTC Today's agenda
03:00:19 <hongbin_> #topic Roll Call
03:00:43 <yanyanhu> hello
03:00:46 <Namrata> Namrata
03:00:47 <haiwei_> hi
03:00:56 <sudipto> o/
03:01:04 <Wenzhi> hi
03:01:23 <yuanying> hi
03:01:32 <hongbin_> Thanks for joining the meeting yanyanhu Namrata haiwei_ sudipto Wenzhi yuanying
03:01:48 <shu-mutou> hi
03:01:52 <shubhams> hi
03:02:07 <hongbin_> shu-mutou: shubhams Thanks for joining
03:02:16 <hongbin_> #topic Announcements
03:02:22 <hongbin_> 1. Project rename finished: our project has been renamed in Gerrit and Github last Friday.
03:02:29 <hongbin_> #link https://review.openstack.org/#/c/329247/
03:02:48 <hongbin_> So, everything is renamed to Zun now
03:03:00 <yanyanhu> cool
03:03:06 <hongbin_> #topic Review Action Items
03:03:11 <hongbin_> 1. hongbin raise a ML to discuss container image (DONE)
03:03:17 <hongbin_> #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/102777.html
03:03:43 <hongbin_> It looks nobody replied to the ML, but we can discuss it later in the agenda
03:03:52 <hongbin_> #topic Nova integration (Namrata)
03:03:58 <hongbin_> #link https://blueprints.launchpad.net/zun/+spec/nova-integration The BP
03:04:02 <hongbin_> #link https://etherpad.openstack.org/p/zun-containers-nova-integration The etherpad
03:04:06 <hongbin_> Namrata: ^^
03:04:13 <Namrata> hi..
03:04:23 <Namrata> i worked on my bp last night(here)
03:04:34 <Namrata> but i guess there is some error(-1 jenkins)
03:04:43 <Namrata> so i will see it today
03:04:59 <Namrata> i have some doubts to clear
03:05:18 <hongbin_> Namrata: btw, the -1 on jenkins has nothing to do with your patch
03:05:37 <Namrata> i am new.Then what it refers to?
03:05:57 <hongbin_> Namrata: it is something incorrect in project-config, and it will be fixed https://review.openstack.org/#/c/365803/
03:06:14 <Namrata> okay cool
03:06:54 <sudipto> hongbin_, wondering why that job is added as a part of the build?
03:07:07 <sudipto> we don't need the devstack jobs for specs - do we?
03:07:24 <hongbin_> sudipto: the job will run on every patches
03:07:37 <hongbin_> sudipto: however, we can disable it if the patch is a spec
03:07:42 <sudipto> hongbin_, agreed,
03:07:53 <sudipto> that was my point too.
03:07:54 <hongbin_> will create a bug for that
03:08:19 <hongbin_> #action create a bug to disable devstack job if a patch is a spec or doc change
03:08:43 <sudipto> hongbin_, apologies for not replying to the ML - I had customer meet ups till Friday and yesterday was a site holiday.
03:09:03 <hongbin_> sudipto: NP at all
03:09:13 <sudipto> I will catch up with you today! in your day time. Anyway - let's continue.
03:09:30 <hongbin_> Namrata: anything else from you about nova integration?
03:09:40 <Namrata> no
03:09:45 <hongbin_> Thanks Namrata
03:09:46 <Namrata> i will update the patch
03:09:51 <Namrata> thanks
03:09:54 <hongbin_> #topic Container image store
03:10:00 <hongbin_> #link https://blueprints.launchpad.net/zun/+spec/glance-integration
03:10:05 <hongbin_> #link https://etherpad.openstack.org/p/zun-container-image
03:10:18 <hongbin_> OK, let's discuss the container image
03:10:49 <hongbin_> let's continue from the ML
03:10:51 <hongbin_> #link http://lists.openstack.org/pipermail/openstack-dev/2016-September/102777.html
03:11:15 <hongbin_> what we agreed is to support a special prefix 'glance/'
03:11:38 <hongbin_> if a container image name has that prefix (i.e. glance/busybox), then pull it from Glance
03:11:55 <hongbin_> if not, pull it from the Docker Hub
03:12:37 <hongbin_> so far, any comment?
03:12:55 <yanyanhu> yes, this makes sense. Another option is we always try to pull image from local registry(glance)
03:13:15 <yanyanhu> if not found, try to pull from docker hub, e.g.
03:13:31 <hongbin_> yanyanhu: yes, that could be an alternative
03:13:41 <hongbin_> what are the pros and cons
03:14:14 <Wenzhi> glance can provide multi-tenancy support
03:14:34 <sudipto> The reason why yanyanhu 's proposal is better is probably because - if you have a compose file that has been worked on a different COE (say kubernetes) - when you run it in zun - it should run as is, without any edits.
03:15:06 <hongbin_> sudipto: i see
03:15:29 <yanyanhu> yes, this is one important reason
03:15:40 <hongbin_> sudipto: I agree with that the advantage is the portability
03:15:52 <yanyanhu> to keep compatible
03:16:11 <haiwei_> agree, make glance as the first priority seems reasonable
03:16:13 <hongbin_> ok, any oppositing point of view?
03:16:42 <hongbin_> if no, i mark it as a agreed
03:16:59 <sudipto> another conflicting point
03:17:04 <shubhams> hongbin : should we provide a command to set up and config a local repo . something line : zun --repo-create  and zun --repo-config (thats inside glance) and in zun --create provide option "use-repo" for which value can be "local repo" or "other"
03:17:10 <sudipto> are we on the same page w.r.t having this in glance or glare?
03:17:16 <sudipto> I can't seem to understand the way forward...
03:17:38 <sudipto> nikhil, hi - are you here?
03:18:20 <sudipto> looks like he isn't.
03:18:30 <hongbin_> shubhams: your suggestion is to introduce a new API to manage image repo?
03:18:49 <shubhams> hongbin : yes and that way we can allow user/admin to manage their repo
03:19:26 <haiwei_> why not use glance directly? shubhams
03:19:42 <Wenzhi> agreed ^^
03:19:46 <shubhams> there might be cases when they want to use their repo in private and do not want to share and their might be cases when they first want to pull images and then make changes and push them directly in their local  repo only
03:20:24 <sudipto> glance should be able to handle that no?
03:21:06 <haiwei_> I think so
03:21:10 <shubhams> sudipto: I think glance should be able to handle that but need confirmation and api should be added just for better management
03:22:00 <sudipto> agreed some evaluation is needed. I am broadly confused about the way forward for image management vs artefact management as well.
03:22:12 <shubhams> user/admin knows better from where they want an image (based on their usecase)
03:22:40 <sudipto> yeah that's the functionality that glance provides - multi-tenancy
03:23:21 <nikhil> O/
03:23:38 <hongbin_> I think shubhams point is valid. There might be use cases that users want to always pull from docker hub
03:23:49 <sudipto> agreed.
03:23:49 <hongbin_> because all the images are versioned there
03:24:19 <hongbin_> in this case, a config is needed for operators to define a list of repo
03:24:33 <hongbin_> and the order of each repo
03:24:45 <shubhams> If we try to decide it by ourself in zun code( like first check in local repo and then checks online) then it might add unnecessary time for pulling because you are first waiting for local repo and then asking for docker hun
03:25:45 <nikhil> I don't know your use case for artifacts , image management is currently only glance
03:26:15 <sudipto> yeah the  only thing is - you are going to still have the same problem with the ordering of config option. That is the lower order repo has the image - you would reach there only after evaluating the higher order ones.
03:27:36 <sudipto> nikhil, ok
03:28:04 <hongbin_> yes, it is up to the operators to define a good list of repos and their orders to minimize the misses
03:28:34 <hongbin_> if they don't want multiple repos, define a list with single repo
03:28:46 <hongbin_> then images will be always pulled from that repo
03:29:03 <shubhams> one more use case:  If we manage repo and addition of images is the job of admin then they can pull images in background without affecting others and users of those images can seemlessly use local repo only.
03:29:39 <shubhams> That will be a kind of abstraction which users of images will have . probably good from security perspective as well
03:30:03 <nikhil> It almost looks like you guys are talking about different backends
03:30:19 <sudipto> shubhams, how would the admin know - what image to pull?
03:30:19 <nikhil> Rather than different repositories
03:30:44 <nikhil> Key difference is abstraction fir
03:30:59 <sudipto> nikhil, we are basically talking about everything atm, we will definitely use glance at some point in time after we settle the dust :)
03:31:08 <hongbin_> nikhil: the initial proposal is to pull from glance first, if there is a miss, pull it from DOcker hub
03:31:40 <hongbin_> nikhil: then the discussion evolve to let admins define a list of repos and define their orders
03:31:41 <nikhil> From users perspective is way simple for diff backends rather than repo
03:31:56 <nikhil> hongbin_: so...
03:32:17 <hongbin_> nikhil: nothing, just explain
03:32:21 <nikhil> Glance has this image locations feature for admins
03:32:45 <nikhil> Sryy ipad==typo and less speed
03:33:32 <nikhil> Using locations you can define strategy to pull images from in a specific order /algorithm
03:33:48 <hongbin_> nikhil: thx. good to knnow
03:34:10 <sudipto> nikhil, wasn't that something you wanted to deprecate? since it was a security hole or something? (Sorry if i am wrong)
03:34:17 <nikhil> I think if we can think of docker hub as anothrt backend for glance
03:34:37 <nikhil> Darn... We need better at communicating
03:34:49 <nikhil> Not deprecate for admins
03:35:51 <hongbin_> ok, maybe we need to investigate the glance feature further
03:35:55 <nikhil> Anyway, from my perspective a good opportunity to create a docker hub driver in glance store just like one exists for ceph, swift , http etc
03:36:26 <nikhil> My$0.02, thx!
03:36:39 <hongbin_> nikhil: thanks for your advice
03:37:06 <hongbin_> ok, folks, let's think of this topic further, and re-discuss it at the next meeting
03:37:07 <sudipto> nikhil, thank you!
03:37:23 <hongbin_> #topic Container network
03:37:29 <hongbin_> #link https://blueprints.launchpad.net/zun/+spec/neutron-integration
03:37:35 <hongbin_> #link https://review.openstack.org/#/c/365754/
03:37:55 <hongbin_> for this topic, i proposed a spec
03:38:07 <hongbin_> i can briefly explain the spec a little
03:38:33 <hongbin_> requirement, bind neutron ports to container so that containers have networking
03:39:05 <hongbin_> like a vm, it should have private ip address, ability to attach floating ip, has security group, etc.
03:39:13 <sudipto> hongbin_, sure...
03:39:18 <hongbin_> the proposed method:
03:39:47 <hongbin_> 1. use nova-docker to provision an empty container
03:40:29 <hongbin_> 2. nova-docker will attach neutron ports to the empty container, so it has networking
03:40:56 <hongbin_> 3. has zun provision a container (called zun container), has the zun container attach to the empty container
03:41:15 <hongbin_> by using "docker run --net=container:<container>"
03:41:52 <hongbin_> then, the zun container will have the same network with the empty container
03:42:26 <hongbin_> because the "--net" option allow to create a container to join the network namespace of existing container
03:42:37 <sudipto> hongbin_, why nova-docker?
03:42:57 <hongbin_> sudipto: it doesn't need to be nova-docker, but it needs to be a nova virt driver that provision container
03:43:08 <hongbin_> sudipto: the point is to leverage nova to do everything for us
03:43:22 <hongbin_> sudipto: rather than re-inventing everything by ourselves
03:43:56 <sudipto> ok,
03:44:10 <sudipto> Ingress in kubernetes does a similar thing...
03:44:18 <sudipto> however, that's for a POD.
03:44:27 <hongbin_> yes, consider it as a pod here
03:44:58 <sudipto> and why would you use a POD kinda thing for a single container?
03:44:58 <hongbin_> has nova-docker (or a new virt driver) to provision a pod
03:45:06 <hongbin_> has zun to provision container inside a pod
03:45:19 <sudipto> ok - my confusion is -is this talking about the COE implementation of ZUN?
03:45:33 <hongbin_> sudipto: no, it is runtime implementation
03:45:36 <sudipto> or you just in general want the containers to be accessible for  users?
03:45:39 <sudipto> ok
03:46:03 <hongbin_> i mean from implementation point of view, this is similar to k8s pod
03:46:22 <sudipto> ok got it.
03:46:38 <sudipto> POD == 1 container in this case.
03:46:46 <hongbin_> yes
03:46:53 <sudipto> Also is this an config option? or is it mandatory?
03:47:01 <sudipto> s/an/a
03:47:15 <hongbin_> this is mandatory, otherwise, container will have no networking
03:47:45 <sudipto> but that makes us heavily dependent on nova to accept the nova docker or whatever virt driver we write...
03:48:19 <hongbin_> sudipto: yes, there is a hard dependency on nova
03:48:34 <hongbin_> sudipto: however, we should control the virt driver
03:49:29 <sudipto> Talking about a situation where consumers of zun - will have to get the nova driver from out of tree or something.
03:49:57 <hongbin_> sudipto: we can develop a custom virt driver in zun tree
03:50:19 <sudipto> hongbin_, hmm ok...
03:51:00 <hongbin_> sudipto: i know it might be complicated for consume, but other methods needs to copy almost the entire nova to zun
03:51:23 <hongbin_> sudipto: at least, all the networking bits, which is undesirable
03:51:23 <sudipto> hongbin_, hmm, yeah that's definitely not good. if unless we have any other alternative.
03:52:38 <hongbin_> comment?
03:53:18 <yanyanhu> hongbin_, actually, agree with sudipto, maybe we should also consider other alternate if there is one
03:53:29 <hongbin_> yanyanhu: sure
03:53:36 <yanyanhu> since this is really a hard dependency on nova-docker
03:53:50 <hongbin_> that is true
03:54:06 <hongbin_> let's leave it one week, and revisit it at the next meeting
03:54:11 <yanyanhu> sure
03:54:21 <Wenzhi> I think it's Ok to depend on nova-docker or other virt driver for now, otherwise we need to copy code from nova
03:54:26 <hongbin_> at the same time, we could discuss it further on the review
03:54:29 <yanyanhu> lets wait for more comments
03:54:40 <sudipto> agreed, let's wait a bit and revisit
03:54:48 <Wenzhi> agreed
03:55:00 <hongbin_> #topic Open Discussion
03:55:33 <shu-mutou> since renaming to zun is finished, it's time to create zun-ui subproject, I think.
03:55:34 <sudipto> Just one update, I have got my dev environment up - and i will push that code into my github
03:55:55 <sudipto> mysql + keystone/rabbit + zun
03:55:57 <shu-mutou> if you guys are interested in zun-ui, please write up your name at last of following etherpad. https://etherpad.openstack.org/p/plan-for-zun-ui
03:55:58 <yanyanhu> shu-mutou, +1
03:55:59 <hongbin_> shu-mutou: yes, i am ok with that
03:56:15 <yanyanhu> that will be very helpful for enduer
03:56:31 <Wenzhi> +1
03:56:37 <haiwei_> shu-mutou , great
03:56:45 <hongbin_> shu-mutou: i will submit a request to create a ui repo
03:56:56 <hongbin_> shu-mutou: then we can start working on that
03:57:10 <shu-mutou> thanks guys!!
03:57:24 <shu-mutou> also, I will invite someone from horizon.
03:57:32 <shu-mutou> OK?
03:57:35 <hongbin_> sure
03:58:08 <hongbin_> #action hongbin help shu-mutou to create a new repo for ui
03:59:08 <hongbin_> ok, nothing else?
03:59:23 <hongbin_> then let's end the meeting. time is up
03:59:42 <hongbin_> all, thanks for your attending this meeting
03:59:53 <hongbin_> hope to see you all next week
03:59:57 <hongbin_> #endmeeting