03:00:20 <hongbin> #startmeeting zun
03:00:21 <openstack> Meeting started Tue May 16 03:00:20 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:22 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:24 <openstack> The meeting name has been set to 'zun'
03:00:26 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-05-16_0300_UTC Today's agenda
03:00:30 <hongbin> #topic Roll Call
03:00:43 <kevinz> kevinz
03:01:34 <pksingh> hello
03:01:46 <kiseok7> hello o/
03:01:56 <lakerzhou> lakerzhou
03:02:09 <hongbin> thanks for joining the meeting kevinz pksingh kiseok7 lakerzhou
03:02:19 <hongbin> let's get started
03:02:35 <hongbin> #topic Announcements
03:02:43 <hongbin> 1. Welcome Fengshengqin to the core team
03:02:48 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2017-May/116467.html
03:02:51 <kevinz> welcome!
03:02:57 <hongbin> 2. Boston Summit Recap
03:03:26 <hongbin> There are several requirements gathered from the boston summit, i tried to summarize it as following:
03:03:30 <hongbin> 1. Support running containers in VMs.
03:04:07 <hongbin> 2. Container network and storage are considered as essential features.
03:04:13 <hongbin> 3. These features are considered to be useful: Capsule, NFV, pass secrets to container, acceleration resources (i.e. SRIOV, GPU).
03:04:20 <hongbin> 4. Make the project mature to attract adoption (consider getting some tags from https://governance.openstack.org/tc/reference/tags/index.html).
03:04:26 <hongbin> 5. Revisit the direction of Kubernetes integration
03:04:31 <Shunli> :)
03:04:42 <hongbin> Shunli: hey, welcome to the meeting
03:05:18 <hongbin> For #1, that is because there are some use cases for using vm as a isolation
03:05:58 <hongbin> in addition, ask operation to deploy zun without touching the compute node might be easier for them
03:06:32 <lakerzhou> Hongbin, for #4, do we have an official installation guide?
03:06:41 <hongbin> For #5, the feedback is that it is confusing to have k8s integration in the roadmap
03:07:01 <hongbin> lakerzhou: yes, i think official installation guide is a must
03:07:08 <hongbin> lakerzhou: and there is a BP for tracking that
03:07:24 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/zun-installation-guide
03:07:49 <lakerzhou> hongbin, thanks for clarification, I missed the BP
03:07:58 <hongbin> ok
03:08:18 <hongbin> lakerzhou: i would need your help to clarify the nfv parts :)
03:08:46 <hongbin> lakerzhou: will rely on you about that for the requirements
03:08:51 <kevinz> Sorry my hexchat has been killed by antivirus..
03:08:56 <kevinz> Just rejoin...
03:09:03 <hongbin> kevinz: ack
03:09:04 <lakerzhou> hongbin, sure, I will try my best.
03:09:19 <hongbin> ok, i finished my announcement
03:09:30 <hongbin> any other announcement from our team member?
03:09:52 <hongbin> #topic Review Action Items
03:10:00 <hongbin> #topic Cinder integration (diga)
03:10:05 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration The BP
03:10:13 <hongbin> it looks diga is not here
03:10:33 <hongbin> i am going to split this bp into two : 1. cinder driver, 2. fuxi driver
03:10:58 <hongbin> that is because this BP might be too big so that the progress is slow
03:11:11 <hongbin> i will talk to diga about that
03:11:22 <hongbin> ok, next one
03:11:31 <hongbin> #topic Introduce container composition
03:11:37 <hongbin> #link https://review.openstack.org/#/c/437759/ The design spec
03:11:41 <hongbin> #link https://etherpad.openstack.org/p/zun-container-composition The etherpad
03:11:59 <hongbin> kevinz: want to drive this one?
03:12:08 <kevinz> OK hongbin
03:12:55 <kevinz> The spec has been review in the last meeting. Also we have finished clarified the APIs
03:14:05 <kevinz> So I think maybe I can do the prototype now?
03:14:28 <hongbin> kevinz: i think you can
03:14:47 <kevinz> If there is something unconsidered, feel free to let me know:-)
03:14:55 <kevinz> hongbin: OK
03:16:15 <hongbin> ok, thanks kevin. i think the spec looks very close to merge , just need to wait for a while for further feedback
03:16:23 <lakerzhou> Kevinz, quick question, does volume belong to a composition or a container. Do we distinguish the two cases?
03:17:15 <kevinz> lakerzhou: If the volume is created from a yaml file , I think it belong to the capsule
03:18:09 <hongbin> from the k8s pod design, all containers inside a pod will share the volume, i think capsule might do something that is similar
03:18:23 <hongbin> that is volume belongs to a composition
03:18:24 <lakerzhou> kevinz, thanks, let me think about the use cases and discuss this later offline
03:18:32 <kevinz> +1 hongbin
03:18:36 <kevinz> lakerzhou: OK
03:19:03 <hongbin> ok, any other comment for this topic?
03:19:05 <kevinz> hongbin: do we have a bp about "support for port mapping"
03:19:36 <lakerzhou> Hongbin, my concerns was really about the expected behavor of volume for individual containers.
03:19:55 <hongbin> kevinz: #link https://blueprints.launchpad.net/zun/+spec/support-port-bindings
03:20:25 <hongbin> lakerzhou: what is the expected behavior?
03:21:35 <kevinz> hongbin: Haha I can reuse this, change port bindings from container host node to network container.
03:22:42 <lakerzhou> hongbin, if a volume does not belong to capsule, then should it be persistent?
03:22:46 <pksingh> do we need port binding? can you please explain
03:23:18 <hongbin> lakerzhou: i think you can think of this way (1) for in-capsule container, the volume belongs to the infra container, (2) for bare container (no capsule), the volume belongs to that container
03:23:45 <hongbin> lakerzhou: in both cases, volume are mounted to a container (infra container or not)
03:23:59 <kevinz> pksingh: In capsule, we need to binding container port to capsule port for external access
03:24:24 <lakerzhou> hongbin, thanks for the clarification.
03:24:26 <hongbin> kevinz: you don't have to use port binding for that
03:24:56 <hongbin> kevinz: how about using the --net=container:xxx option?
03:26:03 <kevinz> hongbin: you mean add one container to another container's network?
03:26:36 <hongbin> kevinz: sort of, let the real containers join the network namespace of hte infra container
03:26:44 <kevinz> hongbin: I see.
03:27:15 <hongbin> kevinz: this is how I implemented sandbox in before
03:27:56 <hongbin> kevinz: https://github.com/openstack/zun/blob/master/zun/container/docker/driver.py#L84
03:28:06 <hongbin> ok, any other comment?
03:28:23 <kevinz> hongbin: Thx. I will check the code to see the details
03:28:36 <kevinz> hongbin: Nothing from me :-)
03:28:59 <hongbin> ok, next topic
03:29:05 <hongbin> #topic Support different container hosting types
03:29:09 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/vm-as-container-host
03:29:27 <hongbin> i just wanted to get a quick feedback, do anyone have a comment on this bp?
03:29:33 <hongbin> good idea? bad idea ?
03:29:36 <zsli_> no
03:30:08 <kevinz> one question.
03:30:34 <kevinz> This will rely on heat to launch vm and container?
03:30:41 <pksingh> how to run compute service on VMs?
03:31:15 <hongbin> pksingh: there are several options
03:32:08 <hongbin> pksingh: we can either run a zun-compute process at each vm, or remotely talk to the docker api at the vm
03:33:21 <pksingh> hongbin: hmm, i think if we do it remotely, then how scheduling and data collection will behave?
03:34:11 <hongbin> pksingh: yes, this is a challenge, an alternative is to have a lightweight agent running on each vm
03:34:46 <pksingh> hongbin: yes that can be an option
03:35:00 <hongbin> pksingh: or simply move the whole zun-compute to each vm
03:35:16 <pksingh> will vms and baremetals will co-exist in the system?
03:35:33 <hongbin> pksingh: i think this is possible
03:36:30 <pksingh> how about multitenancy for VMs or it will be for sinngle user?
03:36:45 <lakerzhou> VMs and Baremetals can co-exist in a cloud, but not in a same server. Right?
03:37:25 <hongbin> pksingh: i think the goal of running container on vm is using vm as an isolator, therefore, the vm has to belong to a tenant
03:37:58 <hongbin> pksingh: and containers on a tenant must run on vms on that tenant
03:38:07 <lakerzhou> +1 no multi-tenant within VM
03:38:32 <hongbin> however, baremetal could be different...
03:39:30 <pksingh> hongbin: when VMs would be created?
03:39:53 <hongbin> pksingh: it could be dynamically created, or pre-created
03:40:08 <lakerzhou> Hongbin, I thought baremetal would be the same. One tenant create a node via ironic, can other tenant use the node? I need to double check it.
03:40:47 <hongbin> lakerzhou: i see, if the baremetal is provided by ironic, that it should be one tenant
03:41:04 <Shunli> +1 for baremetal still in tenant.
03:41:32 <hongbin> lakerzhou: there are actually three targets: compute host, ironic instance, vm
03:42:35 <hongbin> i think we might make it generic, for example, add an attribute in a node that identicate whether this node can run containers on other tenants
03:42:53 <hongbin> s/on/from/
03:43:00 <lakerzhou> hongbin, I agree compute host should support multi-tenant
03:43:20 <hongbin> lakerzhou: yes, but nova instances might or might not
03:44:00 <hongbin> anyway, i will write a spec for this bp to clarify all the details
03:44:04 <pksingh> hongbin: user will specify where it has to create containers, like VMs, compute hosts or Ironic BMs?
03:44:52 <Shunli> oh,my poor network. get me crazy. :-(
03:44:59 <hongbin> pksingh: i think user will specify a "target", the "target" decide how to provision the resource (i.e. container, vm)
03:45:49 <pksingh> target means where to run containers?
03:46:09 <hongbin> pksingh: kind of, it might contain more details if we want
03:46:30 <pksingh> hongbin: i think this feature will great value addition to zun
03:46:36 <pksingh> great :)
03:46:46 <hongbin> pksingh: ++
03:47:31 <hongbin> any other comment ?
03:47:56 <hongbin> #topic Open Discussion
03:48:21 <hongbin> ok, just bring up topic if you have anything that needs to be discussed as a team
03:48:28 <pksingh> hongbin: how was the response in summit this time ?
03:48:29 <Shunli> I would like to bring up one topic to discuss.
03:48:42 <hongbin> Shunli: go ahead
03:49:27 <Shunli> I think bring the container created by K8s or others into zun and managed by zun will add great value to zun.
03:49:50 <hongbin> Shunli: ack
03:50:08 <hongbin> Shunli: i guess lakerzhou will disagree with you :)
03:50:18 <lakerzhou> :) I am.
03:50:28 <Shunli> :-(
03:50:37 <hongbin> we can have a short debate here
03:50:41 <lakerzhou> Container created by k8ts should be owned by k8ts
03:51:27 <lakerzhou> shunli, we can discuss offline
03:51:55 <lakerzhou> I am interested to learn a valuable use case if it is there
03:51:56 <Shunli> But if zun cannot manage these containers, zun do not touch container deploy. where the containers come from to manage.
03:52:20 <Shunli> I guess few pepole need create container one by one in zun.
03:52:22 <pksingh> guys if you discuss on zun channel it will benificial for all of us :)
03:52:58 <hongbin> want to move the discussion to the zun channel?
03:53:19 <pksingh> no no, i mean no offline discussion on the topic
03:53:26 <pksingh> ob channel it will be good
03:53:32 <pksingh> s/ob/on
03:53:42 <hongbin> pksingh: +1
03:53:59 <lakerzhou> k8ts own the life cycle of its containers, we cannot do much about it. If there is a real value, I guess k8ts would quick implement the feature
03:55:25 <Shunli> I do not think so.
03:56:17 <Shunli> k8s is aim for deploy and orchestrcate the containers, It not definitely touch much about container mangement.
03:56:21 <lakerzhou> If Zun can manage small cluster of containers well especially within the openstack infrastructure, there are many unique use cases such as HPC, NFV
03:57:08 <lakerzhou> orchestrate == life cycle management
03:59:11 <Shunli> seems time is up. maybe we can dissucss offline.
03:59:32 <lakerzhou> I will ask what zun can do to a container, but k8ts cannot.
03:59:44 <lakerzhou> sure
03:59:45 <hongbin> ok, all, thanks for joining the meeting, overflow at #openstack-zun channel
03:59:49 <pksingh> bye
03:59:51 <hongbin> #endmeeting