03:00:49 <hongbin> #startmeeting zun
03:00:50 <openstack> Meeting started Tue Mar  7 03:00:49 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:52 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:54 <openstack> The meeting name has been set to 'zun'
03:00:55 <hongbin> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2017-03-07_0300_UTC Today's agenda
03:00:59 <hongbin> #topic Roll Call
03:01:00 <Namrata> Namrata
03:01:04 <shubhams> Shubham
03:01:04 <lakerzhou> lakerzhou
03:01:05 <kevinz> kevinz
03:01:09 <mkrai_> Madhuri Kumari
03:01:10 <pksingh> Hello All
03:01:10 <yatinkarel> Yatin Karel
03:01:41 <hongbin> thanks for joining the meting Namrata shubhams lakerzhou kevinz mkrai_ pksingh yatinkarel
03:01:49 <hongbin> #topic Announcements
03:01:54 <hongbin> 1. Propose to switch to cycle-with-intermediary release model starting from Pike
03:02:03 <hongbin> #link https://review.openstack.org/#/c/441524/
03:02:31 <hongbin> this proposal means zun will aglin with openstack release sschedule starting from pike
03:02:46 <pksingh> cool :)
03:02:57 <hongbin> zun will make a release at the end of pike in particular
03:02:59 <mkrai_> That's great!
03:03:08 <hongbin> :)
03:03:25 <kevinz> Great:-)
03:03:26 <hongbin> any comment about this announcement?
03:03:47 <shubhams> Do we need to create release docs then?
03:03:58 <pksingh> when will be our firts release, any date?
03:04:10 <tonyb> pksingh: when you're ready
03:04:15 <hongbin> shubhams: it is good to have but not mandatory
03:04:16 <pksingh> :)
03:04:18 <tonyb> cycle-with-intermediary doesn't dictae that
03:04:30 <lakerzhou> Do we need formal installation guides, and other stuff which are common to all the other projects.
03:04:35 <shubhams> hongbin: tonyb : ok
03:04:35 <tonyb> shubhams: do you mean release notes?
03:04:42 <hongbin> pksingh: i think it is good to have a first release right before the boston summit
03:04:44 <shubhams> tonyb: yes
03:04:59 <pksingh> hongbin: i think the same
03:05:01 <hongbin> pksingh: then have the final release at the end of pike
03:05:07 <tonyb> shubhams: they get added with the change so you're always createing them
03:05:17 <shubhams> tonyb: ok.
03:05:19 <pksingh> hmm
03:05:35 <hongbin> lakerzhou: again, it is good to have, but not mandatory (if i understand correctly)
03:05:55 <diga> o/
03:05:57 <tonyb> hongbin: Yup that's right
03:06:07 <hongbin> tonyb: thanks for confirming
03:06:12 <hongbin> diga: hey
03:06:43 <diga> hongbin: Hi
03:06:43 <hongbin> ok, it seems all the questions were addressed
03:06:55 <hongbin> #topic Review Action Items
03:07:01 <hongbin> 1. Wenzhi created a bp for migrate from 'id' to 'uuid' in the sql backend once the etcd backend is finishing migration (DONE)
03:07:06 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/replace-id-with-uuid
03:07:34 <hongbin> this bp means we will graudatly be moving from id to uuid
03:07:57 <hongbin> any comment ?
03:08:31 <hongbin> seems no
03:08:38 <hongbin> #topic Cinder integration (diga)
03:08:43 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/cinder-zun-integration The BP
03:08:46 <hongbin> diga: ^^
03:09:04 <diga> Hi, I have uploaded PS yesterday
03:09:24 <hongbin> #link https://review.openstack.org/#/c/429943/
03:09:26 <diga> but will add next patch today,
03:09:48 <diga> I forgot to add some files & there are some code fixes remaining in the PS
03:10:15 <mkrai_> Is it ready for review diga ?
03:10:21 <diga> I have also uploaded CLI volume PS for client
03:10:24 <pksingh> diga: patch has some issues, would be better to make that in WIP
03:10:40 <diga> mkrai_: I am uploading latest PS then you can review
03:10:51 <mkrai_> diga: Ok thanks
03:11:32 <diga> pksingh: I forgot to add latest PS so by mistake it pushed older changes from another folder
03:11:50 <pksingh> diga: ok :)
03:11:56 <diga> pksingh: I have ready PS, will push in sometime
03:12:32 <hongbin> diga: thanks for the huge effort of doing this patch
03:12:32 <diga> but No test cases implemented yet, will cover test cases today/tomorrow
03:12:52 <hongbin> diga: yes, just let us know when you are done
03:13:09 <diga> hongbin: Thanks you
03:13:11 <diga> hongbin: sure
03:13:50 <hongbin> diga: i think it would be inefficient to give comments on this large patch, would you mind the reviewers directly update your patch for comments?
03:14:54 <hongbin> diga: it is your call
03:15:18 <diga> hongbin: sure
03:15:38 <diga> hongbin: No Problem
03:15:46 <hongbin> diga: ok, then just let us know once you uploaded all the change
03:15:55 <diga> hongbin: yep
03:16:02 <hongbin> diga: i will go though it once you are ready
03:16:17 <diga> hongbin: yeah
03:16:17 <hongbin> thanks diga
03:16:21 <diga> hongbin: welcome!
03:16:34 <hongbin> ok, next topic
03:16:39 <hongbin> #topic Kuryr integration (hongbin)
03:16:45 <hongbin> #link https://blueprints.launchpad.net/zun/+spec/kuryr-integration The BP
03:17:02 <hongbin> i was working on this bp last week
03:17:26 <hongbin> submitted several patches to kuryr, mainly for fixing bugs and enable the existing network and ipv6 feature
03:18:06 <diga> okay
03:18:18 <hongbin> i was playing with kuryr heavily last week, it seems we need to create an port in user's tenant, and pass the port to kuryr to bind
03:18:49 <hongbin> basically, all resources creation needs to be handled out of kuryr to statisfy the multi-tenancy model
03:19:44 <hongbin> #link https://review.openstack.org/#/q/project:openstack/kuryr-libnetwork+and+owner:%22Hongbin+Lu+%253Chongbin.lu%2540huawei.com%253E%22
03:19:46 <hongbin> fyi
03:19:55 <hongbin> any question for this bp?
03:19:56 <diga> hongbin: do you mean creating port in neutron then pass it to kuryr ?
03:20:03 <hongbin> diga: yes
03:20:15 <diga> hongbin: okay
03:20:22 <pksingh> hongbin: why do we need port?
03:20:25 <hongbin> if we let kuryr to create the port, the port will belong to admin tenant
03:20:38 <hongbin> assign floating ip to admin port will be impossible
03:20:42 <diga> pksingh: may be this is required for VIF binding
03:20:58 <hongbin> pksingh: every container needs to have a neutron port
03:21:35 <pksingh> hongbin: ok
03:22:02 <hongbin> any other question?
03:22:03 <mkrai> Zun will create this port itself?
03:22:09 <hongbin> mkrai: yes
03:22:14 <diga> it should
03:22:26 <mkrai_> Ok
03:22:36 <hongbin> and we need to make sure the port is cleanup after the container is deleted
03:22:48 <hongbin> basically, more work for us
03:22:57 <diga> hmm
03:23:40 <hongbin> more questions?
03:23:57 <diga> hongbin: in this case, once we delete the container, then this care should be taken by us
03:24:08 <hongbin> diga: yes
03:24:18 <diga> hongbin: got it
03:25:09 <hongbin> ok, seems no more question
03:25:12 <hongbin> next topic
03:25:13 <hongbin> #topic Introduce host capabilities and cpusets (sudipto)
03:25:18 <hongbin> #link https://review.openstack.org/#/c/427007/ The spec
03:25:22 <hongbin> sudipto: there?
03:25:25 <sudipto_> hongbin, hi yes.
03:25:39 <hongbin> sudipto_: hey, thanks for joining
03:25:43 <sudipto_> I willsend out a review of the spec with Eli's comments incorporated.
03:26:03 <sudipto_> Also i will be sending out the patchsets that hook up resource tracker with node init
03:26:18 <sudipto_> Then once that is done, we will have to make the necessary changes in the scheduler in zun client.
03:26:20 <diga> sorry, I didn't get time to go through it, it will review it today
03:26:39 <sudipto_> I would say - don't review the spec as yet, i will make some changes to it.
03:26:53 <sudipto_> A good time to review would be post 12 hours from now :)
03:27:04 <diga> :) ok
03:27:36 <sudipto_> hongbin, things seem to progress, i just didn't have time last week, but i will resume this week. That's all i have.
03:27:42 <diga> sudipto_: are we trying to use nova schedular capabilities here ?
03:27:56 <sudipto_> diga, no nova isn't involved.
03:28:00 <hongbin> sudipto_: np for that, just let us know once you need workers :)
03:28:19 <sudipto_> We would want to eventually move to the placement API - when it's ready.
03:28:32 <sudipto_> But for now, it's our own tables.
03:28:52 <diga> sudipto_: ohh, you are introducing schedular in zun for resources ?
03:29:01 <diga> sudipto_: okay
03:29:02 <sudipto_> there's already a scheduler in zun :)
03:29:05 <sudipto_> not introducing one.
03:29:18 <hongbin> yes, there is a foo scheduler in zun
03:29:18 <sudipto_> enhancing it...
03:29:32 <pksingh> foo scheduler :)
03:29:46 <diga> :) okay
03:30:28 <hongbin> sudipto_: ok, thanks for the update
03:30:36 <hongbin> any other comment on this bp?
03:30:38 <diga> I am having less knowledge of zun :), my bad
03:30:59 <diga> will dive into it to understand things
03:31:00 <hongbin> diga: np for that
03:31:26 <diga> hongbin: :)
03:31:40 <hongbin> ok, if no more comment, let's advance topic
03:31:49 <hongbin> #topic Discussion of the image API
03:31:54 <hongbin> #link https://etherpad.openstack.org/p/zun-image-api the etherpad
03:32:09 <hongbin> this is the topic tabled in the last meeting
03:32:47 <hongbin> i would leave some time for everyone to go though the etherpad
03:33:56 <hongbin> mkrai: i might have a different opinions with you about storing image in db or not
03:34:34 <hongbin> personally, i don't think storing each image in each host in zun db will be scalable
03:34:48 <mkrai_> hongbin: Sorry there is some issue with my IRC channe;
03:34:48 <hongbin> i lean to the image api to be stateless
03:35:02 <hongbin> but that is my personal taste
03:35:02 <mkrai_> hongbin: which API are you talking about?
03:35:10 <hongbin> mkrai_: image api
03:35:25 <mkrai_> No I mean which specific API
03:35:45 <hongbin> mkrai_: i think i commented on all of them
03:35:59 <mkrai_> hongbin: Ok I am reading it
03:36:35 <hongbin> all, comments on this?
03:37:06 <shubhams> hongbin:  so you mean, we should not store db info on each host
03:37:20 <hongbin> shubhams: i think yes
03:37:36 <mkrai_> hongbin: I think the image API can be made stateless but need to think more on the glance side also
03:38:09 <hongbin> mkrai_: could you elaborate?
03:38:15 <mkrai_> Yes sure
03:38:25 <shubhams> hongbin: I agree to that but at the same time, I think that pulling image on all nodes should not be preferred or default behaviour atleast
03:38:55 <pksingh> i have on question, why we are going user->zun->image-repo why not user->image-repo?
03:39:08 <pksingh> atleast for get calls?
03:39:17 <mkrai_> For example, when using glance as image driver, the image-list should list only the container images not all images
03:39:21 <shubhams> pksingh: sorry I didnt get your point
03:39:28 <hongbin> shubhams: perhaps i agree with you for this comment
03:39:49 <mkrai_> pksingh: Because we are going the same way for containers also
03:39:52 <hongbin> shubhams: somehow, the default is to pick a host and pull it
03:40:13 <mkrai_> shubhams: +1
03:40:16 <pksingh> mkrai_: containers and images are different, we are managing containers not images
03:40:44 <hongbin> pksingh: i think user-> image-repo can be implemented in zunclient not server?
03:40:52 <mkrai_> pksingh: Agree, but Zun should also provide a way to manage images used for their containers
03:41:15 <shubhams> hongbin:  then if user specifies a host then image will be pulled on that host else it can be pulled on any random host ?
03:41:25 <pksingh> hongbin: i think we dont need to implement at the client side, user has docker as well as glance cli,
03:41:41 <hongbin> mkrai_: if in docker hub, zun image-list will list all the images in Docker Hub?
03:41:43 <pksingh> mkrai_: i think no coe manages images, AMAIK
03:42:40 <hongbin> shubhams: yes and no, if specify a host, pull on that host, otherwise, pull on all hosts or a random host
03:42:44 <mkrai_> hongbin: only the images which container are running similar to `docker images`
03:43:03 <hongbin> mkrai_: i see
03:43:44 <hongbin> mkrai_: but docker images is list all the image in localhost
03:44:03 <hongbin> mkrai_: i am not sure how to do that in multi-host senario...
03:44:20 <hongbin> pksingh: ack
03:44:40 <hongbin> pksingh: perhaps we should split the discussion into two, client side and server side
03:44:42 <mkrai_> hongbin: yes. That is where we need DB
03:44:56 <shubhams> hongbin: perhaps in db, inside image table we have a column for "host"  that can have value "hostname", "all",?
03:45:24 <hongbin> mkrai_: shubhams yes, that can be done, but i would worry the scalabillity
03:45:38 <hongbin> if there is hundreds/thousands of hosts, the db will be too large
03:45:59 <hongbin> and all the information there is duplicated, it is just the same images in different host
03:46:11 <hongbin> (not all, some are duplicated)
03:46:18 <pksingh> in future if we have something like replication then will be inserting the same image for every node in db?
03:46:41 <mkrai_> host can be a list
03:46:57 <hongbin> pksingh: interesting idea
03:47:11 <hongbin> mkrai_: yes, that can be a solution
03:47:19 <mkrai_> pksingh: the image API was implemented with regard to docker driver. I am not sure whether it can be scaled to COE at this time
03:48:35 <pksingh> mkrai_: i think we are not just proxy to docker driver, atleast we have scheduler now and more intelligence
03:48:44 <diga> hongbin: mkrai_ : may be we can introduce some filters in image-api which will filter the images to the host
03:49:17 <diga> to distribute images across the hosts
03:49:23 <diga> just a thought
03:49:25 <hongbin> if we follow the nova model, host is invisible to non-admin users
03:49:41 <diga> hmm
03:50:23 <hongbin> ok, it looks mkrai_ shubhams flavor for storing image in zun db
03:50:36 <hongbin> pksingh: what is your view on this?
03:51:11 <pksingh> hongbin: i am not sure, but after every pull during container creation we will add the image in db?
03:51:12 <mkrai_> hongbin: We can take it like this, either we manage image API(for the we need DB) or drop it
03:52:28 <hongbin> mkrai_: yes, we need to decide on one over the other
03:53:20 <hongbin> mkrai_: shubhams : perhaps you two could write the draft of the proposal in the etherpad, then we will revisit it in the next meeting
03:53:30 <shubhams> hongbin: sure
03:53:30 <mkrai_> hongbin: yes. Give me this week time to think over it and let's make a decision by next meeting
03:53:46 <mkrai_> pksingh: Please write your thoughts too
03:53:49 <hongbin> shubhams: mkrai_ : ok
03:53:54 <mkrai_> cool
03:54:09 <hongbin> #topic Open Discussion
03:54:12 <yatinkarel> Hi All, One query:
03:54:13 <yatinkarel> I started looking for magnum-zun integration and this lead me to k8s-integration(pointed out by hogbin) but after going through the Etherpad(https://etherpad.openstack.org/p/zun-k8s-integration) and meeting discussions(pointed by shubhams) referenced in etherpad,
03:54:13 <yatinkarel> Got some conflict between Zun's vision(After seeing zun wiki/Meeting Discusions) and multiple COE's support
03:54:19 <pksingh> mkrai_: sure, may be we can sync up on some other channel
03:54:32 <mkrai_> pksingh: sure
03:54:37 <yatinkarel> - Provide Unified API to container Technologies(docker,lxc-docker,rkt)
03:54:44 <yatinkarel> - COE's implementation in zun itself.(Competition with oter COE's)
03:54:50 <yatinkarel> - COE's support eventually.(May be an extension, seperate from Zun core api's)
03:55:09 <hongbin> yatinkarel: i think we agreed to introduce COE support in before
03:55:37 <hongbin> yatinkarel: we just set it to a relatively low priority since we wanted to focus on docker first
03:56:03 <hongbin> yatinkarel: if anyone want to start the work of k8s/coe integration, i think the team will take it
03:56:43 <yatinkarel> hongbin, but as i can see Unified API's vision(Introducing COE's may get distraction), is this OK for zun
03:57:26 <hongbin> yatinkarel: as long as the COE was introduced as a zun driver, it will implement the zun api
03:57:29 <yatinkarel> or start for other container systems(rkt, lxc-docker)
03:58:08 <hongbin> we are currently focusing on docker as a starting point
03:58:22 <yatinkarel> hongbin, Ok
03:58:28 <hongbin> support of other container runtime might be in a low priority
03:58:59 <yatinkarel> hongbin, Ok for now I would dig more into zun to get more idea
03:59:01 <hongbin> yatinkarel: what is your point of view about zun's roadmap?
03:59:33 <hongbin> perhaps, we could take it offline
03:59:37 <yatinkarel> yatinkarel, For me Unified would be the first(but this would lead to limited features(because we have to target common features))
03:59:45 <yatinkarel> hongbin, Ok
03:59:52 <hongbin> all, time is up
03:59:58 <hongbin> all, thanks for joining the meeting
04:00:00 <yatinkarel> Thanks hongbin
04:00:07 <hongbin> #endmeeting