03:00:11 <hongbin> #startmeeting higgins
03:00:11 <openstack> Meeting started Tue Jun  7 03:00:11 2016 UTC and is due to finish in 60 minutes.  The chair is hongbin. Information about MeetBot at http://wiki.debian.org/MeetBot.
03:00:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:14 <openstack> The meeting name has been set to 'higgins'
03:00:17 <hongbin> #link https://wiki.openstack.org/wiki/Higgins#Agenda_for_2016-06-07_0300_UTC Today's agenda
03:00:21 <hongbin> #topic Roll Call
03:00:32 <yuanying_> OTSUKA, Yuanying
03:00:32 <sudipto> o/
03:00:33 <mkrai> Madhuri Kumari
03:00:37 <Wenzhi> Wenzhi Yu
03:00:38 <Namrata> o/
03:00:42 <yanyanhu> hello
03:00:44 <Vivek__> o/
03:00:50 <sbalukoff> Hello!
03:00:53 <Wang__Jian> o/
03:01:01 <haiwei_> hi
03:01:03 <shu-mutou> (^o^)/
03:01:27 <adisky> hii
03:01:29 <Qiming> o/
03:01:33 <eliqiao> o/
03:01:47 <hongbin> Thanks for joining the meeting yuanying_ sudipto mkrai Wenzhi Namrata yanyanhu Vivek__ sbalukoff Wang__Jian haiwei_ shu-mutou adisky Qiming eliqiao
03:01:54 <hongbin> #topic Announcements
03:02:00 <flwang> o/
03:02:03 <hongbin> I have no annoucement
03:02:06 <hongbin> hey flwang
03:02:11 <flwang> hongbin: hi
03:02:18 <hongbin> Anyone has annoucement?
03:02:28 <flwang> will we talk about the new name?
03:02:33 <hongbin> yes
03:02:44 <hongbin> #topic Review Action Items
03:02:50 <hongbin> 1. hongbin collect a list of advanced features (DONE)
03:02:58 <hongbin> #link https://blueprints.launchpad.net/python-higgins?searchtext=%5Blong-term-idea%5D
03:03:13 <hongbin> I created a few BPs for tracking long-term ideas
03:03:22 <flwang> cool\
03:03:38 <hongbin> If you have any long-term ideas, please submit a BP and mark it as [long-term-idea]
03:03:45 <hongbin> We will revisit them one-by-one
03:04:01 <hongbin> Any comment about that?
03:04:08 <sudipto> hongbin, great!
03:04:10 <Qiming> sounds good
03:04:24 <Wenzhi> good
03:04:24 <hongbin> 2. hongbin raise a ML to collect idea of project naming (DONE)
03:04:31 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2016-June/096318.html
03:04:37 <hongbin> #link https://lists.launchpad.net/launchpad-users/msg06826.html Request for launchpad to rename
03:04:58 <hongbin> I raised a ML in openstack-dev, it seems most people like the name "Zun"
03:05:03 <yanyanhu> aha
03:05:05 <hongbin> However, another thing is
03:05:06 <yanyanhu> yep
03:05:06 <flwang> again, i like Zun
03:05:06 <Qiming> including me
03:05:20 <hongbin> I contacted the launchpad "higgins" owner
03:05:24 <mkrai> +1 for Zun
03:05:34 <hongbin> He said he is willing to give the name "higgins" to us
03:05:47 <Wenzhi> haha...
03:05:50 <sbalukoff> Hmmm... Zun is pronounced a lot like Xen. Just sayin' ;)
03:05:50 <hongbin> In this case, I am still OK to rename it to "Zun" if you like
03:06:02 <mkrai> That would be great
03:06:07 <flwang> hongbin: should we vote?
03:06:16 <hongbin> sure, want to vote?
03:06:17 <yanyanhu> +1 for renaming :)
03:06:20 <mkrai> I think we should keep it higgins then
03:06:32 <mkrai> Ok vote
03:06:37 <eliqiao> lots of codes are hard coded as higgins
03:06:51 <eliqiao> we'd better to change the name as early as long
03:06:52 <flwang> eliqiao: then it's good time to fix it :)
03:07:05 <hongbin> #vote Project name? higgins, zun
03:07:06 <eliqiao> yeah, I agree, the earlier the better.
03:07:24 <hongbin> #startvote what is project name? Higgins, Zun
03:07:25 <openstack> Begin voting on: what is project name? Valid vote options are Higgins, Zun.
03:07:26 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
03:07:34 <Qiming> #vote Zun
03:07:40 <mkrai> #vote Higgins
03:07:41 <yuanying_> #vote Zun
03:07:47 <yanyanhu> #vote Zun
03:07:48 <Namrata> #vote Zun
03:07:51 <adisky> #vote Higgins
03:07:51 <Vivek__> #vote Higgins
03:07:53 <fnaval_> #vote Higgins
03:07:54 <sudipto> #vote Higgins
03:07:57 <Wang__Jian> #vote Higgins
03:07:57 <haiwei_> #vote Zun
03:07:59 <eliqiao> #vote Zun
03:08:03 <shu-mutou> #vote Zun
03:08:17 <flwang> #vote Zun
03:08:22 <hongbin> I guess everyone has voted?
03:08:37 <hongbin> #endvote
03:08:38 <openstack> Voted on "what is project name?" Results are
03:08:39 <openstack> Zun (8): eliqiao, shu-mutou, Qiming, Namrata, flwang, haiwei_, yuanying_, yanyanhu
03:08:40 <openstack> Higgins (6): Vivek__, mkrai, Wang__Jian, sudipto, fnaval_, adisky
03:08:46 <sheel> ah sorry..I missed
03:08:55 <sheel> btw, my vote is for higgins
03:09:08 <hongbin> Then, Zun still win
03:09:15 <adisky> :)
03:09:16 <hongbin> Zun has 8 votes
03:09:18 <mkrai> hongbin: what's your vote?
03:09:23 <hongbin> Higgins has 7 votes
03:09:27 <sheel> ^^
03:09:30 <hongbin> mkrai: I am OK with both :)
03:09:42 <sheel> to save a tie, its best option :)
03:09:43 <sudipto> +1 hongbin
03:09:47 <mkrai> Me too but I just wanted to avoid the renaming effort
03:10:00 <hongbin> Then, let't rename it to Zun
03:10:12 <hongbin> #agreed rename project name to Zun
03:10:25 <hongbin> #topic Drive consensus on project scope
03:10:26 <flwang> hongbin: and i have already got the support from Monty and ttx for the name
03:10:34 <Qiming> right, if we are gonna rename it, then do it NOW
03:10:36 <flwang> s/i/we
03:10:40 <hongbin> #link https://etherpad.openstack.org/p/container-management-service etherpad for collaborating on project requirements
03:10:54 <hongbin> #action hongbin submit a request to rename the project
03:11:07 <hongbin> 1. Nova integration
03:11:11 <mkrai> I will do it for higginsclient
03:11:19 <hongbin> mkrai: thx
03:11:45 <mkrai> Is there any bp for this now?
03:11:47 <hongbin> OK, then let's back to the project scope discussion
03:11:56 <hongbin> #link https://blueprints.launchpad.net/python-higgins/+spec/nova-integration
03:12:17 <hongbin> We discussed the idea in the last meeting
03:12:24 <hongbin> This is a continued discussion
03:12:27 <eliqiao> the plan for nova integration is in 'Zun' side?
03:12:40 <hongbin> eliqiao: ??
03:12:54 <hongbin> eliqiao: Like a Zun virt-driver for Nova
03:12:58 <eliqiao> as for as I know, nova has reached spec freeze now.
03:13:14 <sudipto> eliqiao, yup
03:13:18 <hongbin> We don't have to get it into Nova tree
03:13:23 <eliqiao> ya, so in Newton, we can not nothing in nova.
03:13:36 <hongbin> We can have the driver in our repo at the beginning
03:13:43 <eliqiao> hmm. and nova team doesn't support out-of-tree virt-driver.
03:13:48 <mkrai> This can live in zun repo
03:13:56 <yanyanhu> eliqiao, I think it's ok to keep it in zun repo in current stage
03:13:58 <yanyanhu> yea
03:14:00 <hongbin> eliqiao: really?
03:14:08 <hongbin> eliqiao: ............
03:14:09 <eliqiao> ya, I will find a link
03:14:15 <flwang> hongbin: yep, we can have a separate project temporarily for the driver
03:14:18 <eliqiao> we may need to hack nove code.
03:14:30 <yanyanhu> ...
03:14:51 <hongbin> However, Nova should be designed to be pluggable
03:15:05 <mkrai> Agree hongbin
03:15:07 <flwang> hongbin: +1 and we do port it in next release
03:15:15 <flwang> that's not a big deal, IMHO
03:15:24 <hongbin> Yes
03:15:36 <hongbin> Everyone agree to have a Zun virt-driver for Nova?
03:15:44 <hongbin> Any opposing point of view?
03:15:47 <mkrai> +1
03:15:51 <yanyanhu> +1
03:16:01 <Qiming> +1
03:16:05 <Wenzhi> +1
03:16:08 <Namrata> +1
03:16:21 <haiwei_> +1
03:16:30 <shu-mutou> +1
03:16:30 <hongbin> #agreed Nova integration is in the scope of project
03:16:38 <sheel> +1
03:16:43 <Vivek__> +1
03:16:44 <hongbin> OK. Next one
03:16:51 <hongbin> 2. Neutron/Kuryr integration
03:17:25 <eliqiao> +1
03:17:31 <hongbin> BTW, if anyone interest to work on Nova integration, we requires a spec
03:17:42 <hongbin> And here is the BP: https://blueprints.launchpad.net/python-higgins/+spec/nova-integration
03:18:11 <hongbin> I think we need a spec to clearify the design
03:18:31 <hongbin> OK. That is it for the Nova integration
03:18:46 <sheel> I can help in that but wont be able to take sole ownership
03:18:52 <adisky> i will also
03:19:34 <adisky> i will give spec for nova integration along with sheel
03:19:45 <hongbin> adisky: thx
03:20:01 <hongbin> OK. Second item
03:20:07 <adisky> :)
03:20:07 <hongbin> 2. Neutron/Kuryr integration
03:20:12 <sudipto> sheel, adisky i can help with reviews :)
03:20:22 <sheel> sudipto: great
03:20:23 <adisky> thnx sudipto...
03:20:23 <sudipto> hongbin, +1
03:21:00 <hongbin> For neutron/kuryr integration, I think it is a must do
03:21:09 <hongbin> At least for neutron integration, it is a must
03:21:20 <sudipto> hongbin, agreed!
03:21:36 <Wenzhi> agreed
03:21:41 <yanyanhu> yes, definitely, otherwise, we can't call zun container service "in openstack"
03:22:03 <hongbin> OK, it seems everyone agree
03:22:07 <mkrai> We need expertise with networking for this
03:22:18 <Qiming> does kuryr have a clearly defined scope?
03:22:33 <mkrai> I am interested in it but not sure what it takes to work on Kuryr
03:22:37 <Qiming> is it only about networking or is it about storage too?
03:22:38 <hongbin> Qiming: ??
03:22:55 <hongbin> Qiming: Kuryr will do both
03:22:59 <hongbin> Network and stokrage
03:23:02 <hongbin> storage
03:23:17 <Qiming> okay
03:23:44 <hongbin> #agreed Nuetron/Kuryr integration is in scope
03:24:03 <hongbin> For our side, we agreed to use Kuryr for networking
03:24:11 <hongbin> I am not sure the storage part
03:24:12 <haiwei_> so Zun will integrate with kuryr for both network and storage?
03:24:31 <hongbin> We can discuss hte storage part
03:25:04 <hongbin> For me, I cannot tell how Kuryr is going to do the storage part
03:25:09 <hongbin> The code is not there at all
03:25:11 <yanyanhu> quick question, storage here only means something about "volume"?
03:25:39 <hongbin> yanyanhu: Yes, it means cinder volume for container data volume
03:25:46 <yanyanhu> I see
03:25:59 <sheel> yanyanhu: I think yes... It seems related to Zun and cinder integratino
03:26:07 <sheel> hongbin: right?
03:26:17 <hongbin> sheel: yes
03:26:19 <eliqiao> hongbin: should volume part, it will be a driver of Zun?
03:26:42 <hongbin> eliqiao: not sure, maybe it can be a driver
03:27:08 <hongbin> eliqiao: however, Zun will be duplicated with Cinder if we want to implement a voume driver?
03:27:10 <eliqiao> for now, we don't have any agent(maybe Kuryr) on the Host, how can we handle any driver functions
03:27:34 <hongbin> We need to implement a agent (like nova-compute)
03:27:39 <hongbin> IMO
03:27:44 <eliqiao> hongbin: agreed
03:27:49 <Wenzhi> agreed
03:28:34 <hongbin> Everyone, Kuryr for storage? or pure Cinder for volume?
03:28:42 <hongbin> Or decide it later?
03:28:50 <adisky> decide it later
03:28:56 <sheel> pure cinder for volume
03:29:05 <mkrai> We need to look at Kuryr part also
03:29:09 <yanyanhu> that depends on the maturity of Kuryr I think
03:29:19 <mkrai> so I think we should decide later
03:29:23 <hongbin> yanyanhu: yes
03:29:24 <Wang__Jian> decide later,
03:29:29 <haiwei_> currently kuryr storage seems too far to be used
03:29:35 <yanyanhu> and IMHO, maybe cinder is a better start point
03:29:36 <sheel> haiwei_: yes and cinder seems stable
03:29:38 <Wenzhi> not familiar with Kuryr, but Cinder is reliable
03:29:46 <sheel> yanyanhu: +1
03:30:09 <hongbin> Then, we start with Cinder, and decide to switch to Kuryr later if it makes sense
03:30:26 <mkrai> +1
03:30:28 <sheel> hongbin: seems right choice
03:30:30 <Wenzhi> hongbin: sounds like a plan
03:30:31 <sheel> +1
03:30:34 <adisky> +1
03:30:36 <shu-mutou> +1
03:30:47 <yanyanhu> +1
03:30:55 <hongbin> #agreed start with Cinder integration and revisit Kuryr later
03:30:55 <Wang__Jian> +1
03:31:07 <hongbin> 4. Glance integration
03:31:35 <hongbin> We discussed this in hte previous meeting
03:31:53 <hongbin> We can use Glance for storing container images
03:31:55 <sudipto> sorry i missed the last meeting but i find the support of docker fs in glance inadequate at the moment. I will talk to flwang and see if he agrees.
03:32:48 <sudipto> but unless we are looking at just storing the docker images ...it might be alright.
03:33:16 <hongbin> sudipto: Glance don't support other container images?
03:33:27 <sudipto> but i feel glance could be a meta-store of docker images, then storing the binaries again via "docker save"
03:33:34 <flwang> hongbin: glance doesn't support layered images for now
03:33:43 <sudipto> hongbin, well it does...but only static .gz files.
03:33:47 <hongbin> bummer
03:33:59 <flwang> sudipto: +1
03:34:27 <sudipto> flwang, I will chat with you about this, glare might be another option...
03:34:39 <flwang> sudipto: cool
03:34:41 <sudipto> however, the support needs to be built up.
03:35:03 <hongbin> If we don't use glance/glare, any other options?
03:35:31 <hongbin> maybe hosting a private docker registry?
03:35:35 <sudipto> hongbin, i was thinking, if we don't have an in-band (openstack based) support for image repository - that may not help us in long term? (Considering release cycles etc) ?
03:35:49 * sudipto might be wrong
03:36:04 <flwang> hongbin: though private docker registry works, but i don't think it's a good opion
03:36:15 <hongbin> sudipto: flwang ack
03:36:15 <flwang> since it's a container mgmt service based on openstack
03:36:22 <sudipto> flwang, +2!
03:36:37 <mkrai> Agree flwang
03:36:37 <flwang> if we don't use the services of openstack, then we don't have to keep this, right?
03:36:48 <Wenzhi> Agree flwang
03:36:52 <hongbin> yes
03:37:06 <flwang> we can push changes in openstack/glance if we need something which don't exist for now
03:37:25 <hongbin> For glance, we can use it for docker, but the drawback is it doesn't support layer of images. right?
03:37:31 <eliqiao> flwang: +1, cool
03:37:44 <sudipto> hongbin, yeah - very minimal support of the docker images too.
03:37:44 <flwang> if we can figure out what we need for glance/glare, i can propose a spec and push it
03:37:51 <sudipto> flwang, +1
03:37:56 <sheel> flwang: awesome
03:38:07 <hongbin> OK. Short term solution is using Glance for docker
03:38:22 <hongbin> Long term solution is to contribute to Glance/Glare to get everything we want
03:38:30 <sudipto> hongbin, ++
03:38:32 <hongbin> Do I summary everything correct?
03:38:42 <flwang> hongbin: good for me
03:38:48 <Wenzhi> +1
03:38:57 <flwang> hongbin: would you mind creating a bp for glance integration?
03:39:04 <flwang> so that we can use it to track the requirements
03:39:08 <flwang> for glance/glare
03:39:14 <hongbin> #action hongbin create a bp for glance integration
03:39:15 <flwang> and assign it to me
03:39:22 <hongbin> flwang: ack
03:39:28 <flwang> hongbin: thanks
03:39:48 <hongbin> OK. Sounds we have a good discussion for image management
03:39:56 <sudipto> flwang, will tag team with you on that one!
03:40:08 <hongbin> cool
03:40:32 <hongbin> Next item
03:40:33 <hongbin> 5. Keystone integration
03:40:39 <hongbin> This is a must
03:40:42 <flwang> sudipto: ping me later :)
03:41:03 <hongbin> I guess everyone will agree on Keystone integration?
03:41:10 <sheel> +1
03:41:13 <mkrai> Yes
03:41:15 <hongbin> If no, we aren't able to join the big tent
03:41:25 <Wenzhi> sure thing
03:41:30 <eliqiao> I got a question, will different tenant's containers run on same Host?
03:41:31 <hongbin> #agreed Keystone integration is in scope
03:41:41 <hongbin> eliqiao: Good question
03:41:56 <eliqiao> as we know, containers have bad isolation.
03:42:03 <mkrai> Same question eliqiao
03:42:13 <flwang> eliqiao: i would like to have a param to say if i want a fully isolation
03:42:26 <flwang> when boot the container
03:42:52 <mkrai> We need to implement similar concept as "namespaces" in k8s for isolation of containers
03:42:54 <eliqiao> flwang: then, that tenant will oppuy a whole host
03:43:01 <flwang> it's a little bit complicated than the VM case
03:43:26 <flwang> eliqiao: yep, and the user need to pay more ;)
03:43:28 <mkrai> I don't like the idea of occupying whole host for a tenant
03:43:44 <flwang> we have billing
03:43:54 <hongbin> Another option is to use the hypervisor-based container runtime
03:44:00 <hongbin> Like clear container, hyper
03:44:01 <Wenzhi> agree mkrai
03:44:18 <sudipto> we should be careful while choosing the option here - given clear containers/hyper might co-exist for different tenants on the same host.
03:45:04 <hongbin> IMO, we have a config for scheduler
03:45:19 <mkrai> hongbin: That is one container per vm
03:45:26 <mkrai> sudipto: Agree
03:45:55 <hongbin> We can let operator to config a scheduling policy
03:46:04 <hongbin> 1. Tenent per host
03:46:16 <hongbin> 2. Tenants share host
03:46:35 <hongbin> Operators should tune the config based on their requirements
03:46:56 <sudipto> hongbin, that sounds like a good optoion
03:47:00 <sheel> multiTenant
03:47:05 <sbalukoff> Just a side note, I work on the Octavia project, and our use case emphasizes small container footprint over separation (since operators ought to be able to create service containers on hosts separate from standard tenants). So thank you for not insisting containers run only within a VM.
03:47:36 <eliqiao> sbalukoff: haha ..
03:48:01 <hongbin> sbalukoff: ack
03:48:18 <eliqiao> sbalukoff: I was thinking it running containers before..
03:48:31 <hongbin> Any other comment for multi-tenancy?
03:48:54 <hongbin> 6. TLS support
03:48:55 <eliqiao> if you want a container, create a vm and that vm is fro that tenant, if vm's full of container, creat another one.
03:49:20 <mkrai> eliqiao: no that is not the case with hypercontainers
03:49:20 <hongbin> mkrai: could you elaborate the TLS support?
03:49:39 <mkrai> Yes sure
03:49:57 <sbalukoff> eliqiao: We specifically want to be able to run the containers on hosts, and not within a VM.
03:50:00 <mkrai> We would need TLS support for secure communication
03:50:05 <hongbin> eliqiao: For hyper, containers of different tenants will co-locate
03:50:25 <eliqiao> sbalukoff: okay
03:50:31 <mkrai> But now I don't see any use case as we don't have any other services running outside openstack
03:50:45 <eliqiao> hongbin: yes, I see. hyper and clear conatiner has better isolation.
03:51:32 <hongbin> mkrai: Personally, I couldn't find how TLS fit into Zun
03:51:43 <hongbin> mkrai: as we don't need to secure anything
03:51:47 <mkrai> As of now, me too
03:52:00 <mkrai> So we can leave it for now
03:52:02 <hongbin> OK, then let's skip the TLS for now
03:52:15 <hongbin> #topic Implement Higgins host agent
03:52:25 <hongbin> #link https://review.openstack.org/#/c/325707/ The patch
03:52:30 <hongbin> #link https://blueprints.launchpad.net/python-higgins/+spec/higgins-host-agent The BP
03:53:08 <mkrai> Is it not good to let conductor do it?
03:53:38 <mkrai> What additional will host-agent do?
03:53:56 <hongbin> if we need that, we need to rename zun-conductor to zun-agent (or something else)
03:54:08 <hongbin> However, that is an option
03:54:25 <mkrai> hongbin: ^^
03:54:28 <hongbin> Right now, nova has 1) api 2) conductor 3) compute
03:54:49 <hongbin> Zun can has #1, #2, #3
03:54:59 <hongbin> or Zun has #1 and #3
03:55:09 <hongbin> Which option is better?
03:55:32 <sudipto> conductor is helpful for upgrades too
03:56:03 <hongbin> sudipto: yes, I agreed, since conductor is the only place to access DB
03:56:09 <mkrai> It is better to follow nova design
03:56:12 <sheel> I think its ok to use conductor for local operations than seperate agent..
03:56:12 <eliqiao> 1 2 3
03:56:14 <Wenzhi> IMO, for better support for scheduler in the future, we should keep #1, #2, #3
03:56:43 <Wenzhi> then we can just borrow the design from nova API->Conductor->Scheduler->Compute
03:57:06 <hongbin> Wenzhi: ack
03:57:19 <hongbin> Everyone agree to have #1 #2 #3?
03:57:45 <hongbin> (might be a scheduler in future)
03:57:46 <mkrai> hongbin: I would like to work on scheduler part
03:57:55 <hongbin> mkrai: ack
03:57:57 <mkrai> So have assigned the bp to me
03:58:08 <Wenzhi> mkrai: I am willing to help
03:58:10 <hongbin> #topic Open Discussion
03:58:16 <mkrai> Thanks Wenzhi
03:58:39 <sheel> we have only 2 more minutes..
03:59:01 <sheel> do we have any architecture diagram with us for now?
03:59:11 <hongbin> good question
03:59:17 <mkrai> Not yet
03:59:19 <hongbin> No, so far
03:59:27 <mkrai> Design is not yet finalized :)
03:59:34 <hongbin> However, it seems we agreed to borrow Nova architecture
03:59:37 <sheel> I would need this for API design or I have to create one
03:59:55 <sheel> hongbin: right, It seems we can follow Nova..
04:00:08 <hongbin> OK. Time is up
04:00:16 <mkrai> Thanks everyone
04:00:17 <hongbin> All, thanks for joining hte meeting
04:00:19 <hongbin> #endmeeting