03:00:25 <hongbin> #startmeeting zun
03:00:26 <openstack> Meeting started Tue Mar 28 03:00:25 2017 UTC and is due to finish in 60 minutes.  The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot.
03:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:29 <openstack> The meeting name has been set to 'zun'
03:00:31 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-03-28_0300_UTC Today's agenda
03:00:35 <hongbin> #topic Roll Call
03:00:44 <lakerzhou> lakerzhou
03:00:46 <Namrata> Namrata
03:00:47 <kevinz> kevinz
03:00:48 <yuanying> yuanying
03:00:59 <mkrai> Madhuri Kumari
03:01:18 <hongbin> thanks for joining lakerzhou Namrata kevinz yuanying mkrai
03:01:24 <hongbin> let's get started
03:01:35 <hongbin> #topic Cinder integration (diga)
03:01:43 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration The BP
03:01:46 <diga> o/
03:01:54 <hongbin> diga: hi diga
03:01:54 <diga> hi
03:02:13 <hongbin> diga: want to give a update about he cinder integration bp?
03:02:14 <diga> I think Core implementation part is completed
03:02:20 <diga> yeah
03:02:45 <hongbin> #link https://review.openstack.org/#/c/429943/
03:02:50 <diga> hongbin: Tested with client also, thanks hongbin on help fixing the issue
03:03:12 <diga> hongbin: I haven't added test cases yet for my patch as patch is huge
03:03:29 <diga> hongbin: will start adding it now as code is working
03:03:38 <diga> state
03:03:46 <hongbin> diga: feel free to add test cases in follow-up patches in this case
03:03:57 <diga> hongbin: sure
03:04:34 <diga> hongbin: that's it from my side
03:04:42 <hongbin> diga: i have a request for you
03:04:55 <diga> hongbin: yes
03:05:01 <hongbin> diga: could you briefly explain how your patch works in high level?
03:05:53 <diga> hongbin: currently we have dependency on fuxi, we need fuxi for now, there are some testing pending fuxi side also but will test it today
03:06:10 <diga> hongbin: we have to make sure cinder, fuxi &
03:06:16 <diga> should exist
03:06:26 <pksingh> Hello, sorry for being late
03:06:45 <hongbin> pksingh: hey, np, thanks for joining
03:07:01 <hongbin> diga: ok
03:07:06 <diga> hongbin: then we can run create volume call from zunclient will go to cinder first, create volume & then pass that volume to fuxi to attach it to docker volume
03:07:26 <diga> hongbin: I will update step by step doc in wiki
03:08:16 <diga> hongbin: zun volume-create -n testvol -d fuxi (cli call)
03:08:40 <hongbin> diga: ok, then the request will go to zun-api
03:08:43 <diga> hongbin: will try to cover all the testing today & push latest changes
03:08:49 <diga> hongbin: yes
03:08:54 <hongbin> diga: zun-api will pass the request to ?
03:09:14 <diga> zun-api will pass to volume driver
03:09:37 <hongbin> ok, i saw there are two volume drivers?
03:09:44 <mkrai_> volume driver here is cinder or fuxi?
03:10:08 <diga> volume driver will call cinder driver to create volume & then request comes back to volume driver & then volume driver will initiate docker volume
03:10:56 <diga> Currently I am creating volume first in Cinder, actually docker level we are using fuxi as volume driver
03:11:32 <hongbin> i see
03:12:20 <diga> hongbin: just one question on Fuxi
03:12:32 <hongbin> diga: go ahead
03:12:46 <diga> hongbin: does fuxi support manila also ?
03:12:51 <hongbin> diga: yes
03:13:13 <diga> hongbin: will go through it
03:13:17 <mkrai_> diga: Yes
03:13:32 <mkrai_> I see it in their github page
03:13:37 <diga> okay
03:13:56 <hongbin> diga: i think doc and tests can be added later
03:14:03 <diga> hongbin: okay
03:14:12 <hongbin> diga: right now, our priority is to get the gate passed
03:14:23 <diga> hongbin: give me today, I will do one final testing & update the patch
03:14:29 <hongbin> dims: sure
03:14:34 <hongbin> diga: sure
03:14:45 <hongbin> dims: sorry, wrong person :)
03:14:46 <diga> hongbin: but without test, how we can pass the gate
03:15:01 <diga> hongbin: is it possible ?
03:15:10 <hongbin> diga: we should pass
03:15:17 <diga> hongbin: okay
03:15:21 <hongbin> diga: i will help you with that offline
03:15:29 <diga> hongbin: okay, gr8
03:15:42 <diga> hongbin: will ping you after meeting
03:15:58 <hongbin> diga: sure, thanks for your huge contribution on this feature
03:16:19 <hongbin> all, any other question for diga ?
03:16:25 <diga> hongbin: welcome!
03:16:46 <diga> hongbin: i m done!
03:17:12 <hongbin> thanks diga
03:17:14 <hongbin> #topic Kuryr integration (hongbin)
03:17:20 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/kuryr-integration The BP
03:17:37 <hongbin> i wanted to bring up this patch
03:17:38 <hongbin> #link https://review.openstack.org/#/c/447732/
03:17:53 <hongbin> do everyone have a chance to review it?
03:18:14 <pksingh> will try to review by today
03:18:15 <hongbin> if no, that is fine, i can give a brief introduction of it
03:18:28 <hongbin> pksingh: ack, thx
03:18:31 <diga> hongbin: will take a look at it today
03:18:37 <mkrai_> I also take a look today
03:18:45 <hongbin> ok
03:18:49 <hongbin> thanks everyone
03:19:11 <hongbin> the general idea is to have a network abstraction in zun, that maps the "docker network" command
03:20:15 <hongbin> then, container will join/leave a network, and two containers can share a network
03:20:44 <hongbin> containers within the same network should enjoy all the features provided by libnetwork
03:20:55 <hongbin> i.e. they can resolve each other by hostname
03:21:18 <hongbin> that is the idea
03:21:37 <hongbin> for details, we can discuss in the review
03:21:49 <hongbin> any question for this one?
03:22:01 <mkrai_> I am interested in looking the flow, but I suppose that it will be in the spec
03:22:03 <FengShengqin> will remove scanbox-container if using kuryr ?
03:22:21 <hongbin> mkrai_: yes, the flow is on hte spec
03:22:37 <mkrai_> Thanks hongbin I will take a look
03:22:59 <hongbin> FengShengqin: yes, if kuryr is introduced, sandbox might be removed, but we can discuss it later
03:23:22 <FengShengqin> i see
03:23:22 <diga> yeah
03:23:54 <hongbin> ok, one more thing, i am going to implement the spec after it is approved, but feel free to ping me if anyone interest to take over the work
03:24:14 <diga> hongbin: I think sandbox feature is also a good addition to zun
03:24:52 <hongbin> diga: yes, i am thinking we should make it optional , and let each driver to decide to support sandbox or not
03:25:17 <hongbin> diga: but that could be decided later
03:25:32 <diga> hongbin: okay
03:26:12 <hongbin> ok, advance topic
03:26:20 <hongbin> #topic Introduce host capabilities and cpusets (sudipto)
03:26:25 <hongbin> #link https://review.openstack.org/#/c/427007/ The spec
03:26:36 <hongbin> it looks sudipta is not here
03:26:42 <hongbin> i saw he updated a patch
03:26:59 <hongbin> #link https://review.openstack.org/#/c/449699/
03:27:40 <hongbin> this is good, i guess the next step is the scheduler part
03:28:06 <hongbin> any comment about this topic?
03:28:52 <hongbin> ok, move on
03:28:54 <hongbin> #topic Make "command" as positional parameter for run/create
03:29:02 <hongbin> #link https://bugs.launchpad.net/zun/+bug/1675082
03:29:02 <openstack> Launchpad bug 1675082 in Zun "Make "command" parameter as positional" [Medium,Opinion] - Assigned to <email address hidden> (feng-shengqin)
03:29:22 <hongbin> i can briefly explain the idea
03:29:48 <hongbin> right now, the style of the cli is: zun run --command xxx cirros
03:30:03 <hongbin> i proposed to change it to: zun run cirros sh
03:30:41 <kevinz> make it like docker cli?
03:30:48 <FengShengqin> yes
03:30:48 <hongbin> that is : zun run cirros [command [args...]]
03:31:15 <mkrai_> command is not a mandatory param
03:31:32 <mkrai_> So is it good idea to make it positional
03:31:53 <hongbin> mkrai_: i don't think command is mandatory, since image can specify the default command
03:32:40 <mkrai_> yes so is it good to make it positional? Then it becomes mandatory
03:32:47 <mkrai_> to pass commands
03:33:10 <hongbin> i think it is still optional even we changed it to positional (just like docker)
03:33:31 <hongbin> e.g. it can be: zun run nginx
03:33:46 <hongbin> or it can be: zun run cirros sleep 100000
03:34:08 <mkrai_> If so then I am ok with it
03:34:19 <hongbin> mkrai_: ack
03:34:35 <hongbin> others, any remark for this one?
03:35:03 <hongbin> feel free to bring up opposing point of view if any
03:35:46 <hongbin> pksingh: what is your opinion on that?
03:36:13 <pksingh> hongbin: i am also OK with that
03:36:26 <hongbin> pksingh: ack
03:36:43 <hongbin> kevinz: you?
03:36:57 <kevinz> hongbin: I'm OK also :-)
03:37:22 <hongbin> FengShengqin: ok, i think you are ready to go
03:37:47 <FengShengqin> OK.i will update the patch
03:37:57 <hongbin> FengShengqin: thanks
03:38:20 <hongbin> ok, next topic
03:38:26 <hongbin> #topic Discuss image name at glance
03:38:31 <hongbin> #link https://review.openstack.org/#/c/446710/
03:38:38 <hongbin> lakerzhou: want to drive this one?
03:38:57 <lakerzhou> ok
03:39:48 <lakerzhou> now, docker commit can take repository and tag as inputs, but both optional
03:41:02 <lakerzhou> I propose a mandatory input, e.g. image-name for zun commit command,
03:41:23 <lakerzhou> the image-name will be used for the glance image
03:42:08 <lakerzhou> User can pull the status of the glance image using the input name.
03:42:55 <lakerzhou> I am extending zun glance driver to create new image
03:44:00 <lakerzhou> is there any comments from the team about the proposal?
03:44:04 <pksingh> how does this image name fits to docker registry?
03:45:11 <lakerzhou> if we want to correlate them, we must define some new rules explicitly.
03:45:47 <pksingh> how about this 'zun commit container repo [tag]' and convert repo to image-name internally for glance
03:46:05 <lakerzhou> for example, glance image name can be used for repository
03:46:50 <mkrai_> pksingh: to add to it and the tag in glance would be same as in docker
03:47:24 <mkrai_> +1 to use the repo name as image name as is for glance
03:48:16 <hongbin> i think we all agreed on using image name as repo?
03:48:57 <mkrai_> yes
03:49:13 <pksingh> hongbin: user provide image-name and internally we treat it as repo?
03:49:17 <lakerzhou> then when user make multiple snapshots, images will created in same name
03:49:49 <mkrai_> lakerzhou: We can differentiate based on tags
03:50:02 <mkrai_> glance create api has tags field
03:50:24 <hongbin> pksingh: yes, i think the discussion about i) user provide image-name ii) user provide repo
03:50:42 <hongbin> pksingh: either i) or ii) the image-name is a repo internally
03:50:47 <lakerzhou> yes, but it seems tag in glance has different meaning
03:51:31 <hongbin> lakerzhou: what is the meaning of tag in glance?
03:51:41 <mkrai_> Copied from glance api doc :"List of tags for this image. Each tag is a string of at most 255 chars. The maximum number of tags allowed on an image is set by the operator."
03:51:44 <pksingh> hongbin: but image-name word does only fit to glance
03:52:04 <hongbin> pksingh: yes, i agree on that
03:52:44 <lakerzhou> Image tags make it easy to group images into functional units. You can retrieve a particular group of images by using the tag=<tag_value> filter on an image-list call.
03:52:52 <lakerzhou> from rackspace doc
03:53:06 <hongbin> i see
03:53:23 <hongbin> lakerzhou: then, how about mapping docker tag as glance image properity?
03:53:34 <hongbin> property
03:54:10 <lakerzhou> I haven't thought that, need to think about it.
03:54:24 <pksingh> for now i think we can go ahead with image-name, but i think in future we need to change that
03:54:31 <mkrai_> Yes that's was also my suggestion
03:55:00 <hongbin> sure
03:55:03 <mkrai_> lakerzhou: I can help you with the glance tag/property work if you're ok with it
03:55:16 <lakerzhou> But I don't have strong opinion on either options. We have to explicitly define a rule if we want to correlate repo/tag to image name
03:55:49 <lakerzhou> sure, mkrai, please let me know you comments
03:56:06 <mkrai_> lakerzhou: Thanks I will ping you later
03:56:21 <hongbin> ok, then i tried to summary the discussion on this
03:56:23 <lakerzhou> great, thanks mkrai
03:56:54 <hongbin> 1. use image-name (with a future revisit to change it to repo)
03:57:07 <hongbin> 2. map docker tag to glance tag/property
03:57:37 <hongbin> then, zun commit <container> cirros:latest
03:58:00 <hongbin> this will convert to a glance image with name "cirros" and with tag/property "latest"
03:58:31 <hongbin> is it the agreement of everyone?
03:58:38 <hongbin> (just to confirm)
03:58:38 <pksingh> +1
03:58:44 <kevinz> +1
03:58:54 <lakerzhou> +1
03:59:01 <hongbin> ok
03:59:17 <hongbin> lakerzhou: then, i think you are good to go
03:59:31 <lakerzhou> thanks all for the comments
03:59:53 <hongbin> lakerzhou: thanks for leading the work on this feature
04:00:17 <hongbin> sorry, we run out of time, we cannot cover all topics today
04:00:29 <hongbin> overflow is on #openstack-zun channel
04:00:36 <hongbin> all, thanks for joining hte meeting
04:00:41 <hongbin> #endmeeting