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