Tuesday, 2016-09-06

*** Wenzhi has joined #openstack-zun00:43
*** yanyanhu has joined #openstack-zun01:23
*** yuanying has joined #openstack-zun01:24
*** yuanying has quit IRC01:24
hongbin_yanyanhu: Qiming : ping01:25
hongbin_yanyanhu: Qiming eliqiao Wenzhi : i have a proposal which will have a significant change :  https://review.openstack.org/#/c/365754/01:26
yanyanhuhi, hongbin01:26
hongbin_need your feedback on it01:27
Wenzhihi hongbin01:27
hongbin_hey01:27
Wenzhisure01:27
yanyanhuhongbin_, sure, will check it and leave comments01:27
hongbin_yanyanhu: thx01:27
yanyanhuso it's about multi-tenant network support?01:27
yanyanhuhongbin_, my pleasure01:28
hongbin_yes01:28
yanyanhuI see01:28
yanyanhuwill take a look at it01:28
hongbin_I will brief the idea here01:28
hongbin_the idea is to use nova-docker to provision a container with all the networking01:29
hongbin_then have zun launch a container and joining the nova-docker container01:29
hongbin_that is because nova-docker has everything we want: security group, port binding, etc.01:30
yanyanhuso that nova-docker will be the "switch/router"01:30
hongbin_sort of01:30
yanyanhubut nova docker will be eof in future?01:31
yanyanhuI guess01:31
hongbin_there are several choice01:31
hongbin_either we provide something like nova-docker, or claim support for nova-docker01:31
hongbin_1. folk nova-docker01:31
hongbin_2. contribute to nova-docker01:32
yanyanhuit's ok for zun to rely on nova-docker if it will keep living I think01:33
hongbin_yanyanhu: my initial idea is to do the port binding by hand, but when i looked into it closer, it requres to copy thousands lines of code from nova, which is undesirable01:33
hongbin_yanyanhu: will talk to dims about that01:34
yanyanhuhongbin_, yes, if we want to provide similar support in zun, huge effort(or at least code) is unavoidable01:34
yanyanhuhongbin_, that will be great01:34
yanyanhusince he is the maintainer anyway01:34
hongbin_yes01:35
Wenzhiagree to rely on nova-docker, we can fork it and we can maintain it in zun code base in future01:35
hongbin_ok01:35
Wenzhimaybe we have a chance to shift to kuryr in future01:36
hongbin_frankly, i don't think kuryr is right choice01:36
hongbin_what it does is to that:01:37
hongbin_1. users call docker run ...01:37
hongbin_2. docker call libnetwork, which call kuryr01:37
hongbin_3. kuryr translate the calls to neutron01:38
hongbin_basically, it is just an API adaptor, it doesn't solve our problems01:38
WenzhiI see01:38
hongbin_yanyanhu: btw, the proposal has a side effect that zun will reuse the nova scheduler, resource management, cells, etc.01:54
yanyanhuhongbin_,I thought only the "network bridge" container will be managed by nova?01:56
hongbin_yanyanhu: it is more than a network bridge01:57
yanyanhuother containers are still managed by Zun01:57
hongbin_yanyanhu: in container, there is a concept of namespace01:57
yanyanhuhongbin_, yes01:57
hongbin_yanyanhu: so there is an empty container provisioned by nova01:58
yanyanhuyou mean the namespace in k8s?01:58
hongbin_yanyanhu: then the zun container join the namespaces of the sandbox container01:58
yanyanhunot the linux namespace01:58
hongbin_yanyanhu: no, linux namespace, i.e. network namespace, IPC namespace01:58
yanyanhuhongbin_, ok, I see01:59
hongbin_yanyanhu: so the container provisioned by nova already pick up a host01:59
yanyanhuso you mean all other zun containers will run beside this 'empty' container02:00
yanyanhuin the same host02:00
hongbin_yanyanhu: think of a sandbox like a pod02:00
yanyanhubecause they need to be in the same namespace02:00
yanyanhuyes, that will be a pod02:00
hongbin_yanyanhu: you can have one-to-one mapping between sandbox and zun container02:01
hongbin_yanyanhu: or one-to-many mapping02:01
yanyanhuok, sounds interesting02:01
hongbin_yanyanhu: however, the empty container is scheduled by nova, cpu/memory is specified in nova02:01
hongbin_yanyanhu: what zun needs to do is just run a container in a sandbox02:02
hongbin_yanyanhu: nova does everything for the sandbox (networking, resources management, storage, etc.)02:02
yanyanhuthen the 'resource requirement' for that 'special' container actually depends on the pod resource demand02:03
hongbin_yes02:03
hongbin_so, pod has resource constraint, zun container don't have02:03
hongbin_or i should say zun container depends on its pod02:04
yanyanhufrom service deployment perspective, it makes sense to let pod become the primitive02:04
hongbin_yes02:05
yanyanhubut there could be case user wants to apply for a single container02:05
hongbin_then create a pod with one container02:05
yanyanhuthen the map will be one-one?02:05
hongbin_yes02:05
hongbin_actually, we can do that: zun create <container>02:06
yanyanhubut we still need to expose interface for "container" management, right02:06
yanyanhunot just pod management02:06
hongbin_it creates a sandbox and a container02:06
hongbin_could be. the api could be disucssed further02:06
hongbin_my initial thinking is02:06
hongbin_1. zun create ... : create a sandbox and a container02:07
hongbin_2. zun create --sandbox ... : create a container and join a existing sandbox02:07
hongbin_however, pod management is proxyed to nova api calls02:08
yanyanhuhmm, maybe we should hide sandbox container from enduser?02:08
* hongbin_ has a feeling that the scope of the proposal is more than networking02:09
yanyanhuif user want to create a new container which will join an existing network/storage, we handle the sandbox finding/joining at background02:09
yanyanhuand make this progress transparent to user02:09
hongbin_yes, that can be done02:09
yanyanhusince sandbox is not a conception user should care about :)02:10
*** itzdilip has joined #openstack-zun02:10
hongbin_yes it might introduce extra complexity02:10
yanyanhuhongbin_, that's true02:11
hongbin_yanyanhu: for the nova-docker, i might not care. if it is not nova-docker, it needs to be a nova driver02:12
hongbin_yanyanhu: since we want to reuse everything in nova02:12
yanyanhuunderstand02:12
hongbin_ok02:12
hongbin_will bring this proposal up at the team meeting02:13
hongbin_to get more feedback02:13
yanyanhuok02:13
hongbin_will leave for a while, then come back to run the meeting02:14
yanyanhuok, ttyl02:14
*** hongbin_ has quit IRC02:49
*** hongbin_ has joined #openstack-zun02:50
hongbin_all, team meeting will start in about 9 minutes at #openstack-meeting channel02:51
*** yuanying has joined #openstack-zun02:52
*** shu-mutou-AFK is now known as shu-mutou02:55
*** yuanying has quit IRC02:55
*** vikasc has quit IRC02:56
*** yuanying has joined #openstack-zun02:57
*** vikasc has joined #openstack-zun02:57
*** yuanying has quit IRC03:00
*** sudipto has joined #openstack-zun03:00
*** sudipto_ has joined #openstack-zun03:00
*** yuanying has joined #openstack-zun03:00
*** shubhams has joined #openstack-zun03:01
*** janki has joined #openstack-zun03:09
*** yuanying has quit IRC03:18
*** yuanying has joined #openstack-zun03:20
*** adisky has joined #openstack-zun03:47
*** janki has quit IRC03:51
*** yuanying has quit IRC04:00
hongbin_need to leave now. see you folks04:00
*** hongbin_ has quit IRC04:01
*** yuanying has joined #openstack-zun04:02
*** sudipto_ has quit IRC04:06
*** sudipto has quit IRC04:06
*** shu-mutou is now known as shu-mutou-AFK04:12
*** sudipto has joined #openstack-zun04:53
*** sudipto_ has joined #openstack-zun04:53
*** yasemin has joined #openstack-zun05:04
*** chandankumar has joined #openstack-zun05:34
*** janki has joined #openstack-zun05:45
*** sudipto has quit IRC05:47
*** sudipto_ has quit IRC05:47
*** sudipto has joined #openstack-zun05:53
*** sudipto has quit IRC07:05
*** mikelk has joined #openstack-zun07:59
*** Wenzhi has quit IRC08:04
*** sudipto has joined #openstack-zun08:34
*** shubhams has quit IRC08:53
*** chandankumar has quit IRC09:19
*** chandankumar has joined #openstack-zun09:25
*** mfedosin has joined #openstack-zun09:25
*** yanyanhu has quit IRC10:01
*** chandankumar1 has joined #openstack-zun10:35
*** chandankumar has quit IRC10:39
*** yasemin has quit IRC10:47
*** chandankumar1 is now known as chandankumar10:54
*** yasemin has joined #openstack-zun11:00
*** mfedosin has quit IRC11:37
*** mfedosin has joined #openstack-zun11:51
*** sudipto has quit IRC11:55
*** vikasc has quit IRC12:47
*** sudipto has joined #openstack-zun12:51
*** vikasc has joined #openstack-zun13:00
*** vikasc has quit IRC13:43
*** vikasc has joined #openstack-zun13:55
*** chandankumar has quit IRC14:00
*** chandankumar has joined #openstack-zun14:01
*** janki has quit IRC14:26
*** mikelk has quit IRC14:49
*** janki has joined #openstack-zun15:13
*** sudipto has quit IRC15:31
*** tbh has joined #openstack-zun15:52
*** manikanta_tadi has joined #openstack-zun15:59
*** chandankumar has quit IRC16:10
*** manikanta_tadi has quit IRC16:34
*** tbh has quit IRC16:59
*** janki has quit IRC17:08
*** harlowja has joined #openstack-zun17:38
*** mfedosin has quit IRC18:40
*** vikasc has quit IRC19:42
*** vikasc has joined #openstack-zun19:44
*** flwang1 has quit IRC20:21
openstackgerritHongbin Lu proposed openstack/zun: Fix cannot delete container in Error status  https://review.openstack.org/36529023:07
openstackgerritHongbin Lu proposed openstack/zun: Add more parameters for container create  https://review.openstack.org/35837823:14
*** hongbin has quit IRC23:17

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!