03:00:09 <hongbin_> #startmeeting zun
03:00:10 <openstack> Meeting started Tue Aug  9 03:00:09 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:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
03:00:13 <openstack> The meeting name has been set to 'zun'
03:00:16 <hongbin_> #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-08-09_0300_UTC Today's agenda
03:00:20 <hongbin_> #topic Roll Call
03:00:28 <Namrata> Namrata
03:00:31 <shubhams> shubham
03:00:32 <mkrai> Madhuri Kumari
03:00:39 <Wenzhi> Wenzhi
03:00:43 <yanyanhu> hi, yanyan is here
03:01:00 <itzdilip> Dilip
03:01:08 <vikasc> vikas
03:01:11 <flwang> o/
03:01:20 <hongbin_> Thanks for joining the meeting Namrata shubhams mkrai Wenzhi yanyanhu itzdilip vikasc flwang
03:01:27 <hongbin_> #topic Announcements
03:01:39 <hongbin_> I have no announcement, anyone has?
03:01:54 <hongbin_> #topic Review Action Items
03:01:57 <hongbin_> none
03:02:03 <hongbin_> #topic Runtimes API design (mkrai)
03:02:08 <hongbin_> mkrai: ^^
03:02:40 <mkrai> I have tested the api patch and it is working for all apis except for container-show command
03:03:11 <mkrai> I have uploaded the patch in zunclient for all container related command
03:03:24 <mkrai> #link https://review.openstack.org/#/c/352357/
03:03:39 <hongbin_> Nice
03:04:01 <mkrai> Everyone please review the patch
03:04:08 <hongbin_> What is wrong with the show command though?
03:04:23 <mkrai> The container controller patch needs a revision which I will do after meeting
03:04:31 <hongbin_> sure
03:04:47 <mkrai> hongbin_, Issue is with response being an object
03:05:04 <mkrai> It should not be a difficult issue
03:05:10 <mkrai> I will fix it today
03:05:18 <hongbin_> sounds good
03:05:26 <mkrai> Rest of the commands are working fine :)
03:05:46 <mkrai> Please feel free to test the APIs and post your comments
03:06:10 <mkrai> hongbin_, I have also updated your compute patch
03:06:27 <hongbin_> mkrai: Yes, I saw that. It looks good
03:06:41 <mkrai> Yes it is working now
03:07:05 <mkrai> That's all from my side
03:07:24 <hongbin_> Thanks mkrai .
03:07:33 <hongbin_> Any question about the runtime API?
03:08:12 <hongbin_> #topic Nova integration (Namrata)
03:08:17 <hongbin_> #link https://blueprints.launchpad.net/zun/+spec/nova-integration The BP
03:08:21 <hongbin_> #link https://etherpad.openstack.org/p/zun-containers-nova-integration The etherpad
03:08:29 <hongbin_> Namrata: ^^
03:08:30 <Namrata> I am working on the specs of nova integration
03:08:36 <Namrata> and will submit it by this week
03:09:24 <hongbin_> Great
03:09:47 <mkrai> Namrata, let us know if you need any help on that
03:09:53 <Namrata> yeah sure
03:09:57 <Namrata> Thanks mkrai
03:10:05 <hongbin_> Namrata: Could you tell us your general thoughs about the design?
03:11:03 <Namrata> I will include both the implementation details which we discussed in last meeting
03:11:27 <Namrata> And as of now we don't of scheduler so we will consider Nova's scheduler only
03:11:46 <Namrata> And the driver will work same as ironic driver
03:12:16 <hongbin_> OK
03:12:33 <hongbin_> I remembered we discussed two approach at the last meeting
03:12:48 <hongbin_> 1. Ironic approach (use nova shceduler)
03:12:56 <Namrata> Yeah i will write both the implemenatations in the spec
03:13:01 <hongbin_> 2. VMWare approach (disable nova scheduler)
03:13:13 <hongbin_> En, ok
03:13:33 <mkrai> hongbin_, Is there a way to disable scheduler?
03:13:52 <hongbin_> mkrai: Just use Nova as a proxy
03:14:31 <hongbin_> Nova -> ZUn API -> Zun scheduler -> Zun compute
03:14:44 <mkrai> Ok got it
03:14:50 <hongbin_> Like this: http://docs.openstack.org/kilo/config-reference/content/vmware.html
03:15:01 <yanyanhu> hongbin_, actually nova scheduler still takes effect. Just the scheduling happens cross multiple vcenters
03:15:26 <hongbin_> yanyanhu: Then, it sounds like a two level scheduling
03:15:28 <yanyanhu> hongbin_, yes, basically, the 'real' scheduling is done inside vcenter/zun
03:15:41 <hongbin_> Interesting
03:15:44 <yanyanhu> if we only have one zun/vcenter instance there
03:16:06 <mkrai> yes scheduler is tightly coupled so it can't be disabled I guess
03:16:09 <yanyanhu> so, what you stated is right
03:16:43 <hongbin_> ok
03:16:51 <yanyanhu> mkrai, using the second way, the will be only one available host for nova scheduler to choose actually :)
03:17:08 <yanyanhu> s/host/nova-compute node
03:17:25 <yanyanhu> the compute-node is actually zun service
03:17:25 <mkrai> yanyanhu, How?
03:17:53 <yanyanhu> in that case, Zun will be a nova-compute node for Nova
03:18:05 <yanyanhu> so
03:18:32 <yanyanhu> there is no real scheduling happen at nova side I feel
03:18:44 <Wenzhi> yes just like ironic
03:19:43 <yanyanhu> if we choose another way, nova will be responsible to schedule instance
03:20:19 <hongbin_> I think the first appraoch is more scalable: Nova choose a cluster, Zun pick a node in the cluster
03:20:29 <yanyanhu> just my understanding, maybe not accurate
03:20:57 <yanyanhu> hongbin_, what you mean here by cluster?
03:21:21 <hongbin_> Like VMWare, Nova pick a cluster, vcenter pick a host
03:21:32 <yanyanhu> I see
03:21:36 <hongbin_> Oh, I might misunderstand something
03:21:40 <yanyanhu> so two level scheduling
03:21:44 <hongbin_> Yes
03:22:43 <hongbin_> OK, let's discuss the detail in the spec Namrata will write
03:22:50 <yanyanhu> sure
03:22:57 <hongbin_> Thanks Namrata for working on this
03:22:58 <mkrai> +1
03:23:11 <hongbin_> #topic Integrate with Mesos scheduler (sudipto)
03:23:20 <hongbin_> sudipto_: here?
03:24:01 <hongbin_> It looks sudipto is not here. Anyone else want to discuss this topic?
03:24:35 <hongbin_> OK. Then, let's start the open discussion
03:24:42 <hongbin_> #topic Open Discussion
03:25:08 <hongbin_> I have one topic to discuss, if nobody else has anyting
03:25:20 <mkrai> hongbin_, After we have the basic docker API support, what shall we work on?
03:25:24 <yanyanhu> sure, go ahead plz
03:25:38 <hongbin_> mkrai: There are several priority
03:25:40 <mkrai> We should decide on some features
03:25:47 <hongbin_> mkrai: image, network, storage
03:26:14 * sudipto_ is eavesdropping
03:26:15 <hongbin_> mkrai: Do you have any feature in mind?
03:26:23 <hongbin_> sudipto_: hey
03:26:28 <mkrai> So I think we should add few of these topics in next meeting
03:26:37 <sudipto_> sorry i am out for a customer visit... so couldn't join in time.
03:27:04 <mkrai> I also feel image, storage and networking are priority
03:27:11 <hongbin_> mkrai: sure, will start exploring additional topics next time
03:27:23 <hongbin_> sudipto_: NP at all
03:27:47 <mkrai> Let's enhance the docker support first
03:28:09 <hongbin> hey
03:28:16 <mkrai> Thanks hongbin
03:28:17 <hongbin> Not sure why my name changed
03:28:26 <hongbin> ....
03:28:44 <yanyanhu> haha
03:28:45 <hongbin> OK. Let's continue
03:28:56 <sudipto_> yeah my view is the same, the mesos updates can wait till we finalise the docker support...
03:29:07 <hongbin> sudipto_: ack
03:29:44 <hongbin> For the next priority, I remembered we have an etherpad to list them
03:29:58 * hongbin is finding the etherpad
03:30:27 <hongbin> #link https://etherpad.openstack.org/p/container-management-service
03:31:07 <hongbin> Several things in the list
03:31:30 <hongbin> 1. Implement a simple scheduler
03:31:57 <hongbin> 2. Neutron integration
03:32:03 <mkrai> yes let's list it somewhere so  that contributors can take it
03:32:10 <hongbin> 3. Cinder integration
03:32:45 <hongbin> mkrai: sure. First, we needs to decide which one is the priority first
03:32:55 <hongbin> 4. Glance integration
03:32:59 <mkrai> Yes
03:33:15 <hongbin> mkrai: Do we have a Keystone integration ready?
03:33:20 <vikasc> neutron intergration should be easiest one
03:33:35 <mkrai> Yes
03:33:36 <vikasc> since kuryr already supports libnetwork
03:34:12 <hongbin> vikasc: hopefully, it is easy
03:34:38 <vikasc> and kuryr currently supports baremetal only
03:34:40 <hongbin> mkrai: How about multi-tenancy?
03:35:02 <mkrai> hongbin, No it is not yet supported
03:35:18 <hongbin> mkrai: ack. I think multi-tenancy is very important
03:35:23 <mkrai> We need to look into it
03:35:25 <mkrai> Yes agree
03:35:43 <hongbin> #action hongbin created a BP for multi-tenancy support
03:36:08 <hongbin> Anything else?
03:36:31 <hongbin> 5. Host management
03:36:39 <hongbin> 6. Magnum integration
03:37:17 <yanyanhu> also Composition maybe
03:37:26 <yanyanhu> but not urgent
03:37:32 <hongbin> yanyanhu: ack
03:37:37 <mkrai> Shall we pick some priority topics to be included in next meeting?
03:37:50 <hongbin> mkrai: if you want, yes
03:38:08 <mkrai> I think multi tenancy and glance integration is priority I feel
03:38:16 <sudipto_> mkrai, totally agreed. I think we have to narrow our focus to get something working first.
03:38:50 <hongbin> sudipto_: mkrai get the basic of runtime API working already
03:39:04 <sudipto_> hongbin, oh great. I wasn't aware.
03:39:11 <yanyanhu> +1 as well for glance integration and multi-tenancy support
03:39:20 <sudipto_> Maybe i could do some code reviews - if you guys add me?
03:39:29 <mkrai> sure sudipto_ I will add you
03:39:48 <hongbin> sudipto_: as core reviewer?
03:40:01 <sudipto_> hongbin, well i didn't ask for that :) A basic reviewer would do too.
03:40:29 <hongbin> sudipto_: a basic review don't need to be added :)
03:40:52 <hongbin> However, I can propose you to be a core
03:41:02 <mkrai> +1 for it hongbin :)
03:41:07 <sudipto_> hongbin, alright sounds good!
03:41:15 <yanyanhu> +1 from me
03:41:18 <hongbin> sudipto_: will propose you later
03:41:26 <sudipto_> hongbin, ok thanks!
03:41:33 <hongbin> anyone else want to become a core. Please contact me as well
03:42:07 <hongbin> OK. Back to the Glance integration.
03:42:37 <hongbin> We have about 17 minutes left, want to discuss Glance integration now?
03:42:52 <mkrai> I see glance integration is taken by Fei long
03:43:03 <hongbin> flwang: ^^
03:43:04 <sudipto_> flwang, are you there?
03:43:53 <hongbin> I am not sure if you guys know. Glare has been splitted out from Glance
03:43:58 <sudipto_> I am not really sure where glance is going.
03:44:04 <sudipto_> with Glare and all that.
03:44:06 <yanyanhu> yes, long thread in mailing list :)
03:44:20 <yanyanhu> some discussion (argument as well :P )
03:44:42 <hongbin> Yes, it is a long debate
03:45:32 <hongbin> Glare's API is suitable to implement layers of docker images
03:46:01 <hongbin> Basically, Glare is like a superset of Glance
03:46:10 <yanyanhu> oh, I thought it is for template storing before
03:46:41 <hongbin> yanyanhu: It seems it is not. It is a model to represent the image and its meta-data
03:46:53 <yanyanhu> I see
03:47:01 <yanyanhu> so basically add versioning support
03:47:12 <hongbin> What we needs is the ability to express dependencies between image layers
03:47:43 <hongbin> which Glare can do
03:48:07 <sudipto_> so you want to detach yourself from the docker hub and create a private registry of sorts?
03:48:28 <hongbin> sudipto_: Yes, that is an alternative
03:48:51 <flwang> sorry
03:48:54 <flwang> back
03:49:00 <hongbin> flwang: hey
03:49:15 <hongbin> flwang: I guess you saw the news that Glare was splited out?
03:49:23 <flwang> yep i know
03:49:43 <hongbin> flwang: Then, what the Glare API will look like, a superset of Glance API?
03:49:55 <flwang> and as the discussion with nikhil, implement the layer in glance is most like 'impossible'
03:50:16 <flwang> hongbin: it's an artifacts repo
03:50:27 <flwang> not a superset of glance api
03:50:38 <hongbin> flwang: I see
03:51:18 <flwang> in other words, or IMHO, it's most like a definition for an OS/image
03:51:45 <flwang> it can define very detailed attributes of an image
03:51:53 <hongbin> flwang: but the image blob data must store somewhere?
03:52:07 <sudipto_> till glance and glare sorts out stuff, should we just go with a private registry?
03:52:17 <flwang> i would say the image data is still in glance
03:52:50 <flwang> sudipto_: that's a reasonable option
03:53:01 <flwang> since i can see it will still last very long time to settle down
03:53:13 <sudipto_> flwang, same feelings.
03:53:23 <hongbin> The weakness of docker registry is the multi-tenancy support
03:53:27 <hongbin> and keystone
03:54:17 <flwang> hongbin: right
03:54:19 <hongbin> It looks docker registry is single tenant, that means we need to setup one registry per tenant
03:54:39 <hongbin> or modify the docker registry to make it compatible with multi-tennacy model
03:54:40 <flwang> hongbin: and it's hard to maintain i think
03:55:28 <hongbin> flwang: I might have a crazy idea. Have Glance backed by docker registry
03:56:01 <hongbin> so that we use Glance API at front, use docker registry as a backend
03:56:20 <flwang> hongbin: that's the initial plan I discussed with Sam
03:56:24 <flwang> years ago
03:56:34 <flwang> but i can't remember the details now :(
03:56:54 <hongbin> sounds like the idea was rejected
03:58:12 <flwang> because even if you can work out docker registry as a glance backend, you still have to make glance respect the layers
03:58:14 <flwang> right?
03:58:26 <hongbin> flwang: maybe not
03:58:31 <flwang> how?
03:58:37 <sudipto_> how about an offline mailing list discussion on this? maybe not to the whole community but with a few of us in it?
03:58:47 <flwang> ok, sure
03:58:48 <sudipto_> coz we are on the brink of the hour.
03:58:58 <hongbin> sure...
03:58:59 <flwang> let's back to zun channel
03:59:13 <hongbin> All, thanks for joining the meeting
03:59:22 <hongbin> #endmeeting
03:59:29 <hongbin> ...
03:59:36 <Namrata> thanks..
03:59:59 <mkrai> Meetbot isn't working?
04:00:00 <hongbin_> #endmeeting