03:00:15 <hongbin> #startmeeting zun
03:00:16 <openstack> Meeting started Tue Feb 21 03:00:15 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:17 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:19 <openstack> The meeting name has been set to 'zun'
03:00:21 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-02-21_0300_UTC Today's agenda
03:00:25 <hongbin> #topic Roll Call
03:00:32 <shubhams> Shubham
03:00:40 <kevinz> kevinz
03:01:16 <lakerzhou> lakerzhou
03:01:30 <hongbin> thanks for joining the meeting shubhams kevinz lakerzhou
03:01:41 <hongbin> pause a few more seconds for more attendee
03:01:49 <kevinz> OK
03:02:10 <sudipto_> o/
03:02:13 <diga> o/
03:02:30 <hongbin> sudipto_ diga hi, thanks for joining the meeting
03:02:34 <hongbin> let's get started
03:02:45 <hongbin> #topic Review Action Items
03:02:52 <hongbin> 1. hongbin send a ML to discuss the team mascot (hongbin)
03:02:58 <hongbin> #link http://lists.openstack.org/pipermail/openstack-dev/2017-February/112171.html
03:03:26 <hongbin> here is the proposed choices
03:03:33 <diga> hongbin: can we start cinder integration first
03:03:33 <hongbin> 1. Barrel
03:03:44 <hongbin> diga: ok, go ahead
03:04:03 <hongbin> #topic Cinder integration (diga)
03:04:22 <hongbin> diga: ^^
03:04:27 <diga> I have completed base implementation, will push latest PS today
03:05:02 <diga> Tests cases will try to complete this week
03:05:20 <diga> CLI work is not yet started
03:05:44 <hongbin> #link https://review.openstack.org/#/c/429943/
03:05:52 <diga> But will be able to complete everything by next meeting
03:06:09 <hongbin> diga: awesome
03:06:16 <diga> Sorry for delay in work due to medical issues at home
03:06:28 <diga> hongbin: thanks
03:06:29 <hongbin> no problem for that
03:06:43 <hongbin> diga: thanks diga for the updates
03:06:54 <hongbin> all, any question for this bp?
03:07:14 <diga> hongbin: that's all from my side
03:07:30 <hongbin> diga: ok, thanks for joining the meeting
03:07:35 <diga> hongbin: will let you know if there is any
03:07:45 <diga> hongbin: welcome
03:07:56 <hongbin> ok, let's get back to the mascot topic
03:08:20 <hongbin> we have several proposed choices of team mascot
03:08:28 <hongbin> 1. Barrel
03:08:32 <hongbin> 2. Storks
03:08:37 <hongbin> 3. Falcon
03:08:42 <hongbin> 4. Dolphins
03:08:47 <hongbin> 5. Tiger
03:09:03 <hongbin> which one you like most?
03:09:09 <diga> Dolphins
03:09:26 <kevinz> I vote for Barrel
03:10:01 <hongbin> diga: kevinz ack
03:10:23 <hongbin> i knew Qiming proposed Barrel
03:10:53 <shubhams> +1 for Barrel
03:11:00 <hongbin> and pradeep proposed Dolphins
03:11:15 <hongbin> ok, Barrel has 3, and Dolphins has 2
03:12:12 <hongbin> sudipto_: how about your opinion?
03:12:23 <hongbin> pksingh: hey
03:12:23 <pksingh> hello, sorry i am late
03:12:26 <sudipto_> hongbin, either is fine, no choice :)
03:12:39 <hongbin> pksingh: np, we are discussing the choice of mascots right now
03:12:39 <pksingh> hongbin: hello
03:12:51 <hongbin> sudipto_: -_-
03:13:05 <pksingh> hongbin: so which one? :)
03:13:15 <hongbin> Barrel has 3, and Dolphins has 2
03:13:30 <pksingh> hongbin: barrel is annimal?
03:13:31 <hongbin> pksingh: i counted your vote on Dolphins already
03:13:46 <hongbin> pksingh: it doen't need to be an annimal
03:14:20 <pksingh> hongbin: i think all project mascots are animals, i read it somewhere
03:14:46 <hongbin> pksingh: heat is not, senlin is not
03:14:57 <kevinz> I just ask Wenzhi in Wechat and he is choice is Barrel
03:15:06 <pksingh> hongbin: ok
03:15:31 <hongbin> then, it seems most people vote for barrel
03:15:40 <shubhams> looks like more votes for barrel
03:15:45 <hongbin> i guess the reason is tha tit is a container :)
03:16:02 <hongbin> ok, then let's choose barrel for now
03:16:07 <pksingh> 'We've limited project mascots to real creatures and natural features because we believe they are generally globally recognizable and offer rich flexibility for artistic interpretation. We also note that animals are often personified by characteristics and personality traits, which can help connect to the themes and functionality of the project.'
03:16:10 <sudipto_> Barrel also looks like you have some scotch inside it? :)
03:16:44 <hongbin> pksingh: i see
03:17:02 <pksingh> forest and flame are natural
03:17:13 <hongbin> yes, that is a valid point
03:17:15 <pksingh> https://www.openstack.org/project-mascots/
03:17:37 <hongbin> if we take out barrel, what are the favorite choices?
03:17:43 <hongbin> let's vote it again
03:17:52 <hongbin> 1. Storks
03:17:56 <hongbin> 2. Falcon
03:18:02 <hongbin> 3. Dolphins
03:18:07 <hongbin> 4. Tiger
03:18:37 <pksingh> mine 3
03:18:50 <hongbin> shubhams: kevinz diga ^^
03:19:03 <shubhams> bullock cart ? How about this?
03:19:21 <diga> Dolphins
03:19:41 <shubhams> Something like this  : https://ui.cltpstatic.com/camp/images/ai/000/752/324/752324/published/w/bullock-cart-ride-2.jpg?1469170035
03:19:43 <pksingh> shubhams: bullock cart is not natural, right?
03:19:46 <kevinz> +1 for Dolphins
03:20:08 <shubhams> pksingh: No, check out the image I have shared
03:20:33 <shubhams> pksingh: its like an animal who is carrying things.
03:21:06 <pksingh> shubhams: ox or bull is OK, but i think bullock cart is man made thing
03:21:33 <hongbin> ok, it looks dolphins is the favorite choice
03:21:37 <pksingh> hongbin: may be we can take more time if there is an option for that
03:21:47 <hongbin> pksingh: sure
03:21:55 <shubhams> pksingh:  bullock cart is incomplete without bull so can be taken into consideration
03:22:03 <hongbin> i will wait for a few more days for people to cast votes
03:22:07 <diga> pksingh: yeah, but let's avoid confusion by proposing other mascot
03:22:43 <sudipto_> linux's mascot is a tux btw.
03:22:48 <sudipto_> (penguin)
03:22:58 <diga> hongbin: let's choose from given list
03:23:16 <hongbin> ok...
03:23:31 <hongbin> let's table this one
03:23:42 <hongbin> i proposed everyone to cast their vote on the ml
03:24:10 <pksingh> hongbin, why magnum choose shark, any idea?
03:24:16 <hongbin> simply reply your choice in this ml should be enough:   #link http://lists.openstack.org/pipermail/openstack-dev/2017-February/112171.html
03:24:33 <lakerzhou> can we use Barrel to replace the red blocks in openstack logo?
03:24:38 <hongbin> pksingh: i guess docker is a whale, so magnum choose a shark
03:24:49 <pksingh> hongbin: ok
03:24:51 <pksingh> :)
03:25:16 <hongbin> ok, let's table this topic
03:25:45 <diga> Then Let's choose sea animal's
03:25:49 <hongbin> or leave it to open discussion if we have time
03:26:12 <hongbin> #topic Kuryr integration (hongbin)
03:26:19 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/kuryr-integration The BP
03:26:23 <hongbin> #link https://review.openstack.org/#/c/425883/
03:26:33 <hongbin> thanks everyone for the review, the spec just got merged
03:26:57 <hongbin> i am working on the implementation now, there are several patches need to go into kuryr
03:27:10 <hongbin> i am trying to pushing them in these weeks
03:27:45 <hongbin> it is mainly for supporting creating docker network by using existing resources (i.e. network, subnetpool)
03:28:05 <pksingh> hongbin: if you need any help in implementation please let me know,
03:28:18 <hongbin> pksingh: ack, thx
03:28:44 <hongbin> ok, that is all from my side about this bp
03:28:48 <hongbin> any question?
03:28:49 <pksingh> hongbin: kuryr does not support for existing network?
03:29:07 <hongbin> pksingh: it does, but it deosn't support existing subnetpool
03:29:16 <pksingh> hongbin: ok
03:29:45 <hongbin> for your reference, here is the proposed bp for kuryr
03:29:47 <hongbin> #link https://blueprints.launchpad.net/kuryr-libnetwork/+spec/existing-subnetpool
03:30:30 <pksingh> subscribed it :)
03:30:31 <hongbin> ok, it looks that is it for this topic
03:30:34 <hongbin> next one
03:30:36 <hongbin> #topic Introduce host capabilities and cpusets (sudipto)
03:30:41 <hongbin> #link https://review.openstack.org/#/c/427007/ The spec
03:30:44 <hongbin> sudipto_: ^^
03:31:34 <sudipto_> So based on the coding experience, it seemed that we were doing a couple of things by going the RP way: 1. Repeating code from nova 2. Unecessarily going the REST API way - because eventually the REST API is for de-coupling the scheduler.
03:32:23 <sudipto_> Add to that the fact that Nova hasn't quite merged everything on it. So it seemed that we were going to do something of our own in that space eventually and then re-adjust back when the placement API was available.
03:33:20 <sudipto_> So we decided to keep things simple and do a inventory of the compute nodes (and not care about shared resources at the moment) - write an intermediary layer in phase 2 that can convert things into a RP/Inventory based object.
03:33:47 <sudipto_> Phase 1 is about simply doing things to support the cpusets mostly in the way that kubernetes/older nova way of doing things.
03:34:15 <sudipto_> I need to update the spec, I will do that this week. I have been pushing a few patches for review at the same time to get opinions.
03:34:31 <sudipto_> that's all i have hongbin :)
03:34:44 <hongbin> sudipto_: thanks for the detailed updates
03:34:58 <hongbin> all, do you have any comment on this bp?
03:35:26 <pksingh> it looks ok to me till now, trying to grasp
03:35:46 <hongbin> ok
03:35:56 <hongbin> thanks sudipto_
03:36:24 <hongbin> lakerzhou: just chime in if you have any comment about this topic
03:36:49 <hongbin> ok, next topic
03:36:51 <hongbin> #topic Update image API to support multi-compute scenario (Wenzhi)
03:36:58 <hongbin> #link https://review.openstack.org/#/c/432857/
03:37:07 <hongbin> it looks wenzhi is not here
03:37:38 <hongbin> this topic is about the support of multi-host senario of hte image api
03:37:59 <lakerzhou> I didnot get chance to review the code, but agree with Sudipto, better to divide-n-conquer
03:38:03 <hongbin> pksingh: made a good point that image-search don't need to support multi-host senario
03:38:11 <hongbin> lakerzhou: ack
03:38:44 <hongbin> after that, we need to decide how to do the rest of image operation: i.e. image-list, image-show, image-pull
03:39:15 <pksingh> i have an query to every one, why do we need image pull?
03:39:18 <hongbin> in particular, how to deal with the situation that there are multiple hosts
03:40:03 <hongbin> shubhams: i think you are madhuri did the work of image api, do you have any comment regarding to pksingh 's question?
03:40:49 <pksingh> my purpose is to figure out the usecase so that we can think more about it
03:41:18 <shubhams> hongbin: IMO, we need to consider that its not about docker driver but also about glance image driver
03:41:57 <hongbin> shubhams: yes, i agree that we should consider both image drivers
03:42:21 <shubhams> If we see from docker perspective then multihost scenario has not much sense as docker daemon is centralized for all hosts
03:43:10 <shubhams> I was going through the patch set and somewhat agree with Pradeep.
03:43:28 <hongbin> it seems docker daemon is one-per-host, unless it is on swarm mode, that is true, swarm mode is centralized for all hosts
03:43:31 <sudipto_> docker daemon is centralised from all the hosts --> this means?
03:44:03 <sudipto_> we aren't going the swarm mode way - or are we?
03:44:12 <hongbin> no, we don't
03:44:24 <shubhams> This mean : that from other hosts , we just use docker client (using rest api) to call docker daemon for pulling the images
03:44:42 <shubhams> right?
03:46:03 <hongbin> ok, it seems you mean zun-api is centralized for all hosts
03:46:12 <sudipto_> yeah...
03:46:15 <shubhams> hongbin: yeah
03:46:45 <hongbin> shubhams: then, back to pksingh 's question, do you have any comment?
03:47:26 <shubhams> hongbin: pksingh : I have a query on that too, if we do not support image pull then how do we provide support for running containers?
03:48:03 <hongbin> the image was pulled when we need to run a container
03:48:23 <pksingh> shubhams: i am talking about exposing image_pull to end user
03:49:29 <shubhams> hongbin: pksingh : The use case was : it has to be used by the operator where they want some images to be pre-pulled and not expose the resource/registry to the user who calls "zun run"
03:50:12 <hongbin> shubhams: ok, i got your points
03:50:28 <pksingh> shubhams: ok great, it seems the same usecase which i was thinking
03:50:41 <pksingh> hongbin: do you have any other use case in mind
03:50:49 <hongbin> pksingh: no i don't
03:50:52 <shubhams> pksingh: If we do not want image pull , then probably we need to support private registry and giving control commands to the operator
03:51:16 <pksingh> so can we pull the image at all nodes in compute node when user calls image_pull?
03:51:45 <hongbin> yes, if that is the use case, we should pull them into all nodes
03:51:57 <hongbin> in addition, we should make this api admin-only
03:52:10 <shubhams> hongbin: Yes
03:52:10 <pksingh> and this api should be exposed to admins only :)
03:52:32 <sudipto_> that seems a bit weird to me. Why would you want to pull the images to all the compute nodes?
03:52:32 <hongbin> ok, it seems we are all in the same page
03:52:49 <pksingh> sudipto_: like pulling sandbox image
03:52:58 <shubhams> pksingh: hongbin : If we want to remove this api then we can do so but then  we need to provide some sort of management clis (to the operator of cloud infra) for image registry
03:53:41 <sudipto_> pksingh, ah ok. The sandbox image is a standard image?
03:53:42 <hongbin> shubhams: you can edit the policy.json file to make it admin-only, no need to touch the code
03:53:49 <shubhams> and then "zun run" will be pulling images from the registry exposed by using these clis
03:54:31 <pksingh> sudipto_: currently its kubernetes/pause
03:54:45 <sudipto_> pksingh, ok
03:55:03 <pksingh> sudipto_: we would like to have same image on all nodes, so i was thinking to pull them at the same time
03:55:30 <shubhams> sudipto_: I agree with your point that its bit weird to pull images on all host . Guys can this be a blocker for adapting zun in real world ?
03:56:05 <hongbin> #topic Open Discussion
03:56:11 <hongbin> let's continue the discussion
03:56:55 <sudipto_> admin-only is probably fine.
03:57:11 <sudipto_> (though i have to review the code to be honest)
03:58:05 <hongbin> i think it is not common to pull images on all hosts, this will incurs overhead if the image is too large
03:58:21 <pksingh> hongbin: +1
03:58:23 <hongbin> that is my feeling
03:58:42 <shubhams> hongbin: Yeah and that could affect adversaly when we try to sell zun .
03:58:44 <hongbin> however, the most often use cases is to clean up the images in host
03:59:13 <hongbin> ok, it looks time is up
03:59:27 <hongbin> let's continue the discussion in the review
03:59:33 <pksingh> ok
03:59:44 <hongbin> all, thanks for joining the meeting
03:59:45 <pksingh> bye all, have a great day ahead
03:59:46 <shubhams> ok
03:59:48 <hongbin> #endmeeting