03:00:10 <hongbin> #startmeeting zun
03:00:11 <openstack> Meeting started Tue Aug 30 03:00:10 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:16 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-08-30_0300_UTC Today's agenda
03:00:16 <openstack> The meeting name has been set to 'zun'
03:00:21 <hongbin> #topic Roll Call
03:00:36 <Wenzhi> Wenzhi Yu
03:00:57 <hongbin> hi Wenzhi
03:01:03 <Wenzhi> hi hongbin
03:01:19 <hongbin> Wenzhi: I know Madhuri cannot make this meeting
03:01:37 <hongbin> Other folks are busy with the release possibly
03:02:00 <Wenzhi> yes probably
03:02:09 <hongbin> Le't wait a few more seconds to see if anyone else is joining
03:02:10 <Wenzhi> so just you and me today? :)
03:02:15 <Wenzhi> ok
03:02:21 <hongbin> hopefully not :)
03:02:58 <eliqiao> hi
03:03:31 <hongbin> eliqiao: hey
03:04:04 <yanyanhu> hi, sorry, I'm late
03:04:12 <hongbin> yanyanhu: hi
03:04:49 <hongbin> OK. Let's start. It looks folks are busy today. Maybe have a short meeting
03:04:58 <hongbin> #topic Announcements
03:05:04 <hongbin> 1. We have an accepted talk at Barcelona summit
03:05:10 <hongbin> #link https://www.openstack.org/summit/barcelona-2016/summit-schedule/global-search?t=zun
03:05:41 <hongbin> please come to the talk if you are available
03:05:53 <hongbin> #topic Review Action Items
03:06:00 <hongbin> 1. hongbin create a bug for enhancing the quickstart guide (DONE)
03:06:06 <hongbin> #link https://review.openstack.org/#/c/359574/ Submit a patch instead
03:06:14 <yanyanhu> hongbin, sure will definitely join it if have the chance to travel to barcelona
03:06:46 <hongbin> yanyanhu: ok
03:06:53 <hongbin> yanyanhu: hope to see you there
03:06:56 <Wenzhi> yes ^^
03:07:01 <yanyanhu> yes :)
03:07:17 <hongbin> #topic Nova integration (Namrata)
03:07:34 <hongbin> narmrata is not here today
03:07:40 <hongbin> let's skip this one
03:07:47 <hongbin> #topic Container image store
03:07:53 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/glance-integration
03:07:58 <hongbin> #link https://etherpad.openstack.org/p/zun-container-image
03:08:36 <hongbin> there is an initial decision about the image store at previous meeting
03:09:03 <hongbin> basically, we will support both Glance and Docker Hub. If Glance is used, export docker image as a tar file before uploading to glance
03:09:13 <hongbin> 1. Glance:
03:09:21 <hongbin> $ zun pull glance/busybox
03:09:29 <hongbin> 2. Public Docker Hub:
03:09:34 <hongbin> $ zun pull busybox
03:09:41 <hongbin> 3. Private Docker registry:
03:09:47 <hongbin> $ zun pull $REGISTRY_IP/busybox
03:10:17 <hongbin> Later, if there is more storage backend (i.e. glare) we can do this
03:10:27 <hongbin> $ zun pull XXX/busybox
03:10:51 <hongbin> basically, it leverages the prefix to locate the image store
03:11:18 <yanyanhu> hongbin, zun pull will pull specific image from e.g. glare to local host?
03:11:36 <hongbin> yanyanhu: yes
03:11:37 <yanyanhu> local host where zun cmd is executed
03:11:39 <yanyanhu> I see
03:11:52 <yanyanhu> looks like kind of image management operations
03:11:54 <eliqiao> it seems we need to do a abstract layer to cover all image back-end.
03:12:09 <eliqiao> If so, this may be out of zun's scope?
03:12:13 <hongbin> yanyanhu: yes like docker pull/push
03:12:41 <hongbin> eliqiao: yes there needs to be a abstracted layer
03:12:43 <eliqiao> or, we are working out a unify image API for all containers images?
03:12:57 <hongbin> eliqiao: maybe like nova, it has a layer to talk to glance
03:13:20 <hongbin> eliqiao: yes, but hopefully it is no more than push and pull
03:13:22 <eliqiao> hongbin: it's glace client.
03:13:44 <hongbin> eliqiao: yes, consider zun implements a glance client as well
03:14:34 <hongbin> yanyanhu: what do you think?
03:14:43 <Wenzhi> how if user what to modify the images, like docker commit?
03:14:48 <yanyanhu> hong, I agree with eliqiao
03:14:57 <eliqiao> who will really keep the iamge actually?
03:15:06 <yanyanhu> that maybe it is helpful feature
03:15:07 <eliqiao> glance or docker registry/
03:15:22 <hongbin> eliqiao: both
03:15:32 <Wenzhi> If we use glance as image back-end, how do we modify the image?
03:15:47 <hongbin> docker push to overwrite the image
03:15:55 <hongbin> sorry zun push
03:16:18 <hongbin> basically, we implement a docker pull/push equivalent
03:16:20 <yanyanhu> hongbin, if it is purely about image management, maybe it is not in zun's scope
03:16:41 <eliqiao> who will do the pusing? zun-??
03:16:43 <hongbin> yanyanhu: agree, zun should not manage the iamge by itself
03:16:51 <yanyanhu> since IMHO, the images may be prepared before they are consumed by Zun
03:16:54 <hongbin> eliqiao: users
03:17:14 <eliqiao> if we do a zun push, that is to say we have a image locally, zun will help to push the image to glance?
03:17:17 <hongbin> yanyanhu: I see
03:17:27 <eliqiao> but we don't have zun-conductor for now.
03:17:46 <hongbin> eliqiao: the workflow is like docker CLI
03:17:55 <hongbin> 1. zun pull busybox
03:18:00 <hongbin> 2. modify the image locally
03:18:08 <hongbin> 3. zun push glance/busybox
03:18:18 <hongbin> 4. zun run -it glance/busybox
03:18:49 <hongbin> this is similiar to a typical docker behaviour
03:19:02 <hongbin> and glance is served as a private registry
03:19:28 <Wenzhi> sounds reasonable
03:20:19 <hongbin> yanyanhu: however, I am open to discuss if it fits into the scope
03:21:04 <yanyanhu> hongbin, yes. Actually I think Zun push which push image to glance/glare sounds more reasonable for me. But Zun pull doesn't look that necessary I feel
03:21:24 <hongbin> yanyanhu: I see
03:21:27 <eliqiao> yanyanhu: +1
03:21:34 <eliqiao> zun-driver will do the pull
03:21:38 <hongbin> yanyanhu: let's me record your comment at the etherpad
03:21:38 <yanyanhu> since users do have the requirement to generate a glance/glare image based on running container
03:21:48 <yanyanhu> hongbin, thanks :)
03:22:58 <yanyanhu> but for pulling image from docker hub to local glance/glare storage, user can rely on glance/glare client to do it (if this operation is supported by glance/glare of course :))
03:23:34 <hongbin> yes, the the flow is like
03:23:53 <hongbin> docker pull xxx / glance download xxx
03:24:05 <hongbin> then, zun push xxxx
03:24:43 <hongbin> which is also fine
03:24:55 <yanyanhu> yes, so zun is kind of bridge between docker hub and glance
03:25:02 <yanyanhu> for image operations
03:25:08 <hongbin> agree
03:25:45 <hongbin> then, another question is how to do a commit
03:25:55 <hongbin> and upload it to glance/docker hub
03:26:28 <hongbin> maybe need to implement another operation? like $ zun commit CONTAINER
03:26:44 <yanyanhu> hongbin, it is possible I think
03:26:51 <hongbin> ok
03:27:20 <yanyanhu> may also depends on how glance/glare support it I feel
03:27:32 <hongbin> then zun commit will download the container to local file system?
03:27:34 <eliqiao> zun-compute will do the push right?
03:27:45 <hongbin> eliqiao: users do the push
03:27:46 <eliqiao> also does zun commit
03:27:53 <hongbin> eliqiao: zun-compute do the pull
03:28:13 <eliqiao> I don't get that, if you want to do a commit, then you first need to run that contianer on zun-compute
03:28:33 <hongbin> eliqiao: for zun commit, I am not sure it should commit to glance or to somewhere else
03:28:50 <hongbin> eliqiao: yes
03:28:52 <eliqiao> then user do a commit, zun-compute will commit it, then user do zun push, zun-compute will do the push
03:29:44 <hongbin> eliqiao: but push is user's local -> glance
03:30:11 <hongbin> eliqiao: not zun-compute -> glance
03:30:46 <hongbin> eliqiao: maybe zun commit can do it like zun-compute -> glance
03:31:07 <hongbin> eliqiao: or do it like zun-compute -> user's local
03:31:39 <eliqiao> hongbin: think about that a user only have install zun-client ..
03:32:05 <hongbin> yes
03:32:10 <eliqiao> zun-client will in charge of pushing image?
03:32:18 <hongbin> yes
03:32:39 <eliqiao> k
03:32:48 <hongbin> have zun-client depends on dockerpy
03:32:56 <hongbin> then it should be able to push
03:33:04 <yanyanhu> eliqiao, I think hongbin means 'zun push' is a functionality that zun provides for user to 'convert' a 'remote' docker image to 'local' 'glance/glare' image
03:33:17 <yanyanhu> hongbin, plz correct me if I misunderstand it
03:33:29 <yanyanhu> this operation can be provided by zunclient
03:33:38 <hongbin> yes
03:33:59 <hongbin> because the convertion is not trival
03:34:19 <hongbin> so do it for users is good
03:34:42 <yanyanhu> hongbin, agree this is very helpful for user. Just ideally, glance/glare can provide it :)
03:35:24 <hongbin> yanyanhu: agree
03:36:03 <hongbin> ok, will raise this discussion in the ML
03:36:16 <hongbin> especially for the pull and commit
03:36:19 <eliqiao> +1
03:36:47 <hongbin> #action hongbin raise a ML to discuss container image
03:36:54 <yanyanhu> hongbin, of course, that strongly depends on glance/glare's support
03:37:23 <hongbin> yanyanhu: but I don't think they will support it in a near future
03:37:48 <yanyanhu> hongbin, if so, it's good zun can provide this functionality
03:38:07 <hongbin> yanyanhu: k
03:38:11 <yanyanhu> we should provide user at least one option :)
03:38:44 <hongbin> ok, next topic
03:38:47 <hongbin> #topic Multi-tenancy (Wenzhi Yu)
03:38:59 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/support-multi-tenancy
03:39:06 <hongbin> #link https://etherpad.openstack.org/p/zun-multi-tenancy
03:39:09 <hongbin> Wenzhi: ^^
03:39:13 <Wenzhi> yes
03:39:17 <Wenzhi> https://review.openstack.org/#/c/357615/
03:39:28 <Wenzhi> with this patch now we can scope the containers by tenants
03:39:45 <Wenzhi> IMO that's the whole work we need so far?
03:41:04 <hongbin> Wenzhi: I saw the patch
03:41:29 <hongbin> Wenzhi: it seems to enable the paste.ini
03:41:49 <hongbin> Wenzhi: but not sure how it relates to multi-tenancy
03:41:58 <Wenzhi> the container related code in Zun is basically copied from Magnum I think
03:42:18 <Wenzhi> that means the code has already implemented multi-tenancy
03:42:56 <hongbin> Wenzhi: ok, let's me double check that
03:43:30 <Wenzhi> the reason containers are not scoped by tenants in Zun is because we did not capture the 'porject_id' or 'user_id' from user requests
03:43:44 <hongbin> oh, I see
03:44:14 <hongbin> then I guess it is fine now after your patch
03:44:21 <Wenzhi> yes, I already tested manually, now the containers are scoped by tenants in Zun
03:44:29 <hongbin> awesome
03:44:48 <hongbin> Wenzhi: then let's close the bp
03:44:51 <yanyanhu> maye also need multi-tanant support in db layer? not sure whether it has been there in existing db interfaces
03:45:27 <Wenzhi> yanyanhu: what do you mean by 'multi-tanant support in db layer'?
03:45:40 <hongbin> yanyanhu: Wenzhi : I think it is already there: https://github.com/openstack/higgins/blob/master/zun/db/sqlalchemy/api.py#L112
03:45:53 <yanyanhu> hongbin, great
03:45:57 <hongbin> since the code are copied from Magnum, so Magnum alreadys implements in in db layer
03:46:06 <Wenzhi> yes
03:46:13 <yanyanhu> Wenzhi, if it has been there, we don't need further work here :)
03:46:19 <hongbin> Wenzhi: great job
03:46:19 <yanyanhu> cool
03:46:26 <Wenzhi> thanks :)
03:47:02 <hongbin> ok, then this one finish, let's move to the next topic
03:47:07 <hongbin> #topic Container network
03:47:13 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/neutron-integration
03:47:54 <hongbin> I took this one because I have looked into Kuryr and nova-docker in before
03:48:27 <hongbin> Here is what I think, we don't need kury-libnetwork
03:48:48 <hongbin> maybe we needs kuryr-lib
03:49:25 <hongbin> however, I suggest to decouple from kuryr for now, and re-visit the dependency after kuryr is mature
03:49:55 <hongbin> I plan to port nova-docker implementation to zun as a start
03:50:10 <Wenzhi> sounds like a plan
03:50:17 <hongbin> then, switch to kuryr-lib later
03:50:35 <hongbin> any comment?
03:50:48 <hongbin> or anything needs to clarify?
03:51:26 <hongbin> yanyanhu: eliqiao ^^
03:52:50 <yanyanhu> hi, sorry, just trapped by some other stuff
03:52:55 <yanyanhu> sounds good for me
03:53:02 <hongbin> ok
03:53:28 <hongbin> #topic Open Discussion
03:54:21 <hongbin> any other topic to discuss?
03:54:45 <hongbin> sounds not, then let's wrap up a little earlier
03:54:59 <hongbin> #endmeeting