03:00:04 <hongbin> #startmeeting zun
03:00:05 <openstack> Meeting started Tue May 23 03:00:04 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:06 <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:10 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-05-23_0300_UTC Today's agenda
03:00:14 <hongbin> #topic Roll Call
03:00:18 <pksingh> Hello
03:00:19 <Shunli> :)
03:00:22 <Namrata> Namrata
03:00:27 <shubhams> Shubham
03:00:29 <mkrai> Madhuri Kumari
03:00:44 <lakerzhou> lakerzhou
03:01:07 <hongbin> thanks for joining pksingh Shunli Namrata shubhams mkrai lakerzhou
03:01:26 <hongbin> btw, kevin told me that he cannot join today due to a team lunch
03:01:44 <hongbin> ok, let's get started
03:01:49 <hongbin> #topic Cinder integration
03:02:05 <hongbin> i am splitting this bp into two
03:02:10 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/direct-cinder-integration Direct Cinder integration
03:02:16 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration Cinder integration via Fuxi
03:02:29 <diga> Digambar Patil
03:02:41 <hongbin> my thinking is to have two options when integrating with cinder
03:02:48 <hongbin> hi diga
03:02:55 <diga> hongbin: hello
03:02:57 <hongbin> 1. direct integrate with cinder
03:03:05 <hongbin> 2. integrate with cinder via fuxi
03:03:24 <diga> +1
03:03:27 <hongbin> both options have advantage and disadvantage i think, so i propose to support both
03:03:45 <hongbin> for implementaiton, there will be two volume driver in parallel
03:04:00 <hongbin> i will update the spec to reflect this change
03:04:16 <Shunli> @hongbin, could you explain direct integration with cinder.
03:04:32 <hongbin> Shunli: basically, it means integrate with cinder without fuxi
03:04:51 <hongbin> Shunli: for implementation, i will try to por the nova code to zun as a driver
03:04:55 <diga> hongbin: direct integration with cinder, you mean, what fuxi does, we should implement in Zun
03:05:35 <Shunli> direct integration is for container in vm?
03:05:36 <hongbin> diga: direct integration means a light-weight alternative to fuxi
03:05:50 <diga> hongbin: okay
03:05:57 <hongbin> Shunli: for container in vm/baremetal
03:06:23 <Shunli> ok
03:06:33 <hongbin> i propose this mainly for decoupling the hard dependency on fuxi
03:06:51 <hongbin> these two efforts could be implemented in parallel
03:07:10 <hongbin> i will drive the cinder one, i assume diga will still drive the fuxi one?
03:07:14 <pksingh> hongbin: what do you mean by light weight alternative in detail?
03:07:46 <hongbin> pksingh: basically, i mean operations can install zun without installing fuxi
03:08:09 <pksingh> hongbin: so replicating fuxi code in zun?
03:08:12 <hongbin> pksingh: however, could leverage the built-in cinder driver to get data volume from cinder
03:08:29 <hongbin> pksingh: there will be some amount of dupication, yes
03:08:49 <pksingh> hongbin: you are going to run that driver as daemon?
03:08:53 <hongbin> pksingh: i will make the dupication as minimual as possible
03:09:01 <Shunli> I guess mainly duplicate on the docker volume driver part
03:09:03 <diga_> sorry got disconnected
03:09:48 <hongbin> yes, fuxi has a lot of code, the duplication is the cinder/os-bridge part
03:09:55 <hongbin> os-brick
03:10:10 <hongbin> pksingh: don't get your last question
03:10:30 <pksingh> hongbin: how will docker communicate to this driver?
03:11:26 <hongbin> pksingh: i didn't think of it in details, but i think docker won't talk to anything in that option
03:12:25 <pksingh> hongbin: ok
03:12:26 <hongbin> pksingh: not sure if it is possible, but what i think of is directly using os-brick library to mount volume to host, and point docker to use that volume
03:12:44 <pksingh> hongbin: ok
03:13:22 <hongbin> pksingh: do you think it is a good idea? or a bad idea?
03:13:38 <pksingh> hongbin: i need to look into this
03:13:56 <diga_> but hongbin if there is os-brick integration with fuxi, then we can have those calls implemented in fuxi implementation
03:14:00 <hongbin> ok, i will update hte existing spec for that
03:14:35 <hongbin> diga_: it is already implemented in fuxi
03:14:55 <hongbin> diga_: the goal is provide an alternative to fuxi
03:14:59 <diga_> hongbin: then in that case, its just enablement of it
03:15:21 <lakerzhou> Hongbin, I want to confirm a high-level volume use case for container. Volume attached to container should be ephemeral, right?
03:15:48 <diga_> hongbin: yeah, I understand, but then in cinder also, we are going to implement os-brick ?
03:15:59 <hongbin> lakerzhou: i guess it is
03:17:24 <lakerzhou> hongbin, thanks for clarify.
03:17:54 <hongbin> ok, folks, i will leave further discussion to reviews of the spec that i am going to submit
03:18:10 <diga_> hongbin: I hv some thoughts on "directly integrating with cinder", will talk to you separately after this call
03:18:24 <hongbin> diga_: ack
03:18:39 <hongbin> #topic Introduce container composition
03:18:46 <hongbin> #link https://review.openstack.org/#/c/437759/ The design spec
03:19:10 <hongbin> kevinz is not here today, i will drive this session
03:19:19 <hongbin> i saw kevinz pushed a spec for review
03:19:32 <hongbin> would love your feedback there :)
03:20:09 <hongbin> i don't have anything else on this topic
03:20:11 <hongbin> any comment?
03:20:41 <pksingh> i will look into it this week, i think most of the comments has been resolved
03:20:52 <hongbin> pksingh: ack
03:21:13 <hongbin> ok, next topic
03:21:18 <hongbin> #topic Support floating IP association (pksingh)
03:21:23 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/floating-ip-association
03:21:33 <hongbin> pksingh: ^^
03:21:40 <pksingh> hongbin: thanks
03:22:00 <pksingh> actually we want to attach the floating IP to our containers
03:22:20 <pksingh> i was thinking to implement a REST api for this in zun
03:22:42 <pksingh> but later came to know nova has deprecated such api in their code
03:22:52 <pksingh> they are saying to use neutron api for this
03:23:05 <zsli_> But seems nova's floating ip bind is implemented in neutron.
03:23:06 <pksingh> because nova api is just a proxy to neutron api
03:23:44 <pksingh> so what do you guys think, should we implement in zun or follow same as nova
03:23:56 <mkrai> Use neutron API
03:24:12 <pksingh> zsli_: we are using neutron networking in zun
03:24:30 <lakerzhou> +1 Use neutron API
03:24:43 <Shunli> @pksingh, yes.
03:24:57 <pksingh> Shunli: what do you thunk?
03:25:31 <Shunli> Not sure neutron api can satisfy zun floating ip binding requirements
03:26:14 <pksingh> Shunli: i was thinking to attach floating ip to fixed address port of the container
03:26:29 <pksingh> Shunli: i think nova does the same thing
03:27:44 <Shunli> @pksingh, not go through the related code in detail. Maybe we can discuss it when code review.
03:27:52 <Shunli> +1 for use neutron api.
03:28:39 <pksingh> so according to your views, we should not implement it in zun, instead of this client use neutron api to assign floating IPs
03:28:55 <hongbin> +1
03:29:29 <mkrai> But we should document it in Zun
03:29:30 <pksingh> ok thanks guys, then we dont need to do anything in this BP
03:29:31 <Shunli> @pksingh, yes. I guess nova use neutron api has some reason.
03:29:54 <hongbin> pksingh: i guess the cli still need some work?
03:30:12 <pksingh> hongbin: so you are saying we need to add cli for this?
03:30:34 <hongbin> pksingh: in addition, the container has an 'addresses' fields, right now, it only shows the fixed_ip, would be better to show the floating ip as well
03:30:36 <pksingh> user->cli->neutron-api?
03:31:13 <hongbin> pksingh: if nova does it, then yes, but i haven't gave it more thoughts
03:31:57 <pksingh> hongbin: yes, that is a valid point to show the floating IP and store in the database, do we need to add periodic task for this
03:32:31 <pksingh> hongbin: nova i think has deprecated that from client side too,
03:32:41 <hongbin> pksingh: i see
03:33:35 <pksingh> hongbin: ok , i will give it more thoughts, how we can make it better
03:33:38 <hongbin> pksingh: sorry, i need to leave for about 5 minutes
03:33:48 <hongbin> pksingh: could you chair this meeting for me?
03:34:04 <pksingh> never done this, i think mkrai can do this
03:34:09 <hongbin> folks, sorry about that
03:34:17 <pksingh> mkrai: please go ahead
03:35:06 <mkrai> sure
03:35:54 <mkrai> pksingh: Do you have anything more to discuss on this?
03:36:34 <pksingh> mkrai: no
03:36:37 <mkrai> ok I will move to next topic
03:36:40 <mkrai> #topic Add Zun Resources to Heat (Namrata)
03:36:53 <mkrai> Namrata: ^
03:36:53 <Namrata> Hi
03:37:12 <Namrata> https://review.openstack.org/#/c/437810/
03:37:23 <Namrata> I have updated the patch and its up for review
03:37:53 <mkrai> Are there any remaining patch for this work?
03:38:05 <Namrata> after completion of Add container to zun resources heat BP will be completed
03:38:34 <Shunli> one comments inline. I guess we should wait when containing is running, then the stack create complete.
03:39:01 <mkrai> Great. Thanks Namrata for working on this.
03:39:11 <hongbin> back
03:39:13 <Namrata> Thanks Shunli I will see the inlined comments
03:39:15 <mkrai> Shunli: I think the patch has a check for waiting for container status
03:39:32 <mkrai> to be in one of the completion state i.e Running, failed etc
03:39:43 <mkrai> But I need to check more in detail.
03:39:57 <Shunli> @mkrai, yes. But when container is in creating state
03:40:07 <mkrai> hongbin: Ok chair is your's now :)
03:40:09 <Shunli> check_complete returned True.
03:40:21 <hongbin> mkrai: ack
03:40:28 <mkrai> Shunli: I see that is an issue
03:40:39 <mkrai> I will review the patch today
03:41:16 <hongbin> Shunli: sorry , i am catching up your comment
03:41:17 <mkrai> Shunli: https://review.openstack.org/#/c/437810/7/heat/engine/resources/openstack/zun/container.py L143
03:41:28 <mkrai> It seems it is returning False in Creating state
03:41:32 <mkrai> So it is correct
03:42:22 <Shunli> @mkrai, sorry. I mean in created state, we still should not return true
03:42:45 <hongbin> Shunli: i see
03:42:51 <Shunli> @mkrai, only when container is running state, we can return true.
03:43:08 <hongbin> Shunli: i think there are some cases that the container might exist right away after
03:43:44 <hongbin> Shunli: for example, if hte command is "echo hello" or something, the contianer will exit right after
03:44:26 <hongbin> Shunli: ok, never mind, in that case, the container will be on stopped state
03:44:26 <Shunli> @hongin, ah ,you are right. It's a bit complicate.
03:45:09 <hongbin> Shunli: then, i agree with you, it should return false on 'created'
03:45:27 <Shunli> @hongbin, yeah.
03:45:33 <mkrai> hongbin: Namrata How do you think about adding a doc in Zun about our Heat resource?
03:47:05 <hongbin> it looks Namrata is away
03:47:18 <Namrata> I will add the doc for the same
03:47:26 <hongbin> :)
03:48:01 <mkrai> We can use the example for Zun demo in Boston summit :)
03:48:13 <hongbin> Namrata: do you see the comment from Shunli about the return value on 'Created' ?
03:48:23 <Namrata> sounds good
03:48:56 <Namrata> hongbin Yes I have seen that
03:49:25 <hongbin> Namrata: ok
03:49:26 <Namrata> It should not be true
03:50:02 <hongbin> ok
03:50:11 <Namrata> ok
03:50:14 <hongbin> thanks Namrata
03:50:20 <hongbin> next topic
03:50:22 <Namrata> thanks mkrai hongbin
03:50:32 <hongbin> #topic Others
03:50:35 <Namrata> thanks shunli
03:50:39 <hongbin> #link https://etherpad.openstack.org/p/zun-nfv-use-cases NFV use cases
03:51:15 <hongbin> i will pause for a few seconds for everyone to review hte etherpad
03:51:44 <hongbin> this etherpad is based on an initial discussion between me and lakerzhou
03:52:12 <hongbin> please feel free to write your inputs to there if any
03:52:37 <pksingh> 'it should return false on 'created'', why it should return False,
03:54:13 <hongbin> pksingh: because the heat template is actually "run" the container
03:54:38 <hongbin> pksingh: if the command is run, it will either become "Running" or "Stopped"
03:55:11 <hongbin> pksingh: if it is "Created", it will be considered as unstable state
03:55:11 <pksingh> hongbin: its not for create?
03:55:40 <hongbin> pksingh: if it is created, it will turn to "Running" or "Stopped" later
03:55:55 <mkrai> For create also, the final completion state is Stopped or Running
03:56:00 <pksingh> hongbin: means it is for 'zun run ' but not for 'zun create'
03:56:30 <pksingh> mkrai: i think we modified it, 'zun create' moves to 'Created' state, i think?
03:56:31 <hongbin> pksingh: the heat template will call 'zun run'
03:56:41 <pksingh> hongbin: ok then no issues
03:57:00 <hongbin> pksingh: ack
03:57:21 <hongbin> ok, we are almost running out of time
03:57:40 <hongbin> #topic Open Discussion
03:58:06 <hongbin> any last minute question/comment?
03:58:57 <hongbin> lakerzhou: i have a question for you (written in the etherpad)
03:59:05 <lakerzhou> ok
03:59:12 <lakerzhou> I will take a look later
03:59:17 <hongbin> lakerzhou: thx
03:59:22 <lakerzhou> np
03:59:27 <hongbin> ok, all, thanks for joining the meeting
03:59:42 <hongbin> let's continue the discussion at hte openstack-zun channel
03:59:46 <hongbin> #endmeeting