03:00:02 #startmeeting zun 03:00:03 Meeting started Tue Jul 12 03:00:02 2016 UTC and is due to finish in 60 minutes. The chair is mkrai. Information about MeetBot at http://wiki.debian.org/MeetBot. 03:00:04 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 03:00:06 The meeting name has been set to 'zun' 03:00:10 #link https://wiki.openstack.org/wiki/Zun#Agenda_for_2016-07-12_0300_UTC Today's agenda 03:00:17 #topic Roll Call 03:00:26 Wenzhi Yu 03:00:27 o/ 03:00:27 hello 03:00:32 shubham o/ 03:00:36 o/ 03:01:02 Thanks Wenzhi sudipto yanyanhu shubhams eliqiao for joining today 03:01:19 Let's wait for a minute for others to join 03:02:08 #topic Announcements 03:02:11 O/ 03:02:19 hongbin is on travel this week so I will chair this meeting. 03:02:35 Hey Namrata_ 03:02:44 Any other announcement from team? 03:02:52 he is gonna join openstack day china I think :) 03:03:10 Yes I think he already have done it 03:03:16 yea 03:03:18 o/ 03:03:25 Hey flwang1 03:03:31 mkrai: not yet, it's the day after tomorrow. 03:03:32 o/ 03:03:33 mkrai: hey there 03:03:38 Oh I see 03:03:43 Hi vivek___ 03:03:57 #topic Review Action Items 03:04:07 hongbin create an etherpad for the COE API design (TBD) 03:04:18 This task is still to be done 03:04:31 We will discuss the status in next meeting 03:04:40 Anyone has something to add on this? 03:05:20 Ok let's advance topic 03:05:26 #topic Runtimes API design 03:05:33 #link https://blueprints.launchpad.net/zun/+spec/api-design The BP 03:05:41 #link https://etherpad.openstack.org/p/zun-containers-service-api Etherpad 03:06:04 Ok so I have written down all the basic APIs for containers 03:06:15 And also some advanced and miscellaneous 03:06:26 I will wait for few minutes for everyone to read 03:07:03 #link https://etherpad.openstack.org/p/zun-containers-service-api-spec 03:07:17 Please see above link 03:08:07 Please feel free to add or update any APIs 03:08:19 I plan to submit spec this week 03:08:36 quick question, for basic operations like CUDR, will COEs and runtime based implementation share the same API interface? 03:09:00 yanyanhu, As of now, no 03:09:21 I see 03:09:21 It is quite not possible to club both APIs 03:09:32 yes, feel so as well 03:09:48 We will create APIs for COEs this week or so 03:10:47 Ok I will leave etherpad offline, please add your ideas 03:11:23 Shall we advance or someone has to add anything? 03:11:56 will add comment offline 03:12:04 Ok thanks yanyanhu 03:12:20 #topic Nova integration 03:12:30 #link https://blueprints.launchpad.net/zun/+spec/nova-integration The BP 03:12:39 Is aditi here today? 03:13:05 guess not 03:13:11 Ok I think she has not attended quite few meetings 03:13:34 And as I feel this bp is important for us, so please feel free to take up this one 03:13:47 Anyone interested here to work on this? 03:14:00 Yes I am 03:14:09 Thanks Namrata 03:14:25 Please connect with aditi 03:14:29 And I guess we may need a spec or etherpad for this topic as well 03:14:38 Okay 03:14:40 for discussion and tracking 03:14:43 Agree yanyanhu 03:14:47 +1 03:15:05 Yes it will be bit complex as compared to ironic driver 03:15:30 #action mkrai to create an etherpad for nova-integration 03:15:33 yes, not that straightfoward I think 03:16:22 If i may - what does the nova-integration actually mean? Creating a compute driver for zun? 03:16:38 sudipto, yes 03:16:45 Yes 03:17:09 and ... how does it have similarity to ironic? In terms of a 2 layered scheduler? 03:17:50 sudipto, yes that's what I am trying to highlight that it would be complex as Zun will also have its own scheduler 03:17:50 also, how is it going to be different from the nova-docker driver? 03:18:18 nova-docker driver has very limited functionality I guess 03:18:25 And not even maintained well 03:18:36 but has an overlap to this...you probably know why it had issues... 03:18:57 that is w.r.t not integrating well with nova. 03:19:31 I agree to it to some extent as containers and vms are not same 03:19:51 yeah and i think the same debate is going to come up again with this? 03:20:11 But here we just aim to provide same set of nova APIs for containers 03:20:20 Yes certainly 03:20:40 Nova is good point to sell Zun IMO 03:20:50 Nova providing same set of APIs for containers was the problem with the nova-docker driver AFAIK. 03:21:14 I agree, limited by nova data model, I think nova-zun driver will also be difficult to design 03:21:28 sudipto, ack 03:22:40 It is quite difficult to take out common APIs between VMs and containers, but still we have few that satifies both 03:23:16 I tend to think that the Nova workflow could actually cater to something like an isolated/secure container workflow, that has overlaps with a VM lifecycle. 03:23:32 And IMO it's worth spending some effort to consider this 03:24:27 sudipto, Sorry I don't get it. Could you please explain? 03:25:43 mkrai, going with a container API that fits the VM APIs is fundamentally wrong and it would lead to the same fate as nova-dockers at least that's what i feel. However, if you imagine something like a container in a VM workflow - that probably fits the APIs of a Virtual Machine. 03:26:43 however with that said - we are free to try and still do whatever we think is the best :) 03:26:59 sudipto, What I understand here is the host where we are running our containers. Right? 03:27:18 mkrai, didn't understand your last statement? 03:27:59 Ok the point you stated is one where we are running containers inside vm or not inside vm 03:28:47 we have stated that we want to support hyper like workflows into openstack - i meant that use case could fit into a nova integration per say - but in general running containers with Nova APIs - sounds similar to nova-docker. 03:29:01 I would like to hear everyone's thought around it as well, who knows - i might be short sighted here :) 03:29:42 yes I agree that is similar to nova-docker but with more features 03:29:58 More container runtime tools and also COEs 03:30:06 Yes I want to ask team here 03:30:06 You are right sudipto , but anyway from an instance's perspective (baremetal/vm/container) , we need to use nova only, right? 03:30:21 Do they feel this work is worth spending some effort? 03:30:49 shubhams, you mean provision the instance via nova and then have containers run inside them via zun? 03:31:20 nope, I mean everything ( a vm/bm or container ) should be provisioned by nova 03:31:28 shubhams, Yes we aim to do so 03:31:39 But it is not hard and fast 03:31:44 shubhams, why? 03:31:57 are you referring to the host management being done by nova? 03:32:08 Yes sudipto 03:32:16 Ok let's take this discussion in Open discussion 03:32:23 alrite. 03:32:31 are we bound to use nova for all this ? 03:32:31 Thanks 03:32:44 #topic Re-consider RabbitMQ. How about using key/value store (i.e. etcd) for passing messages 03:33:00 In our last meeting, we discussed about managing state of containers in Zun 03:33:12 We talked about etcd which is distributed key-value store 03:33:24 However we also discussed few more options like rabbitmq and taskflow. 03:33:36 I want to know team's opinion on it. 03:33:48 I gues yuanying is not present today 03:33:57 s/gues/guess/ 03:34:00 for passing messages, I prefer rabbitmq 03:34:06 I think we need a PoC for etcd 03:34:12 +1 sudipto 03:34:21 I think etcd is not designed for this(message exchange) 03:34:24 I strongly feel so 03:34:48 Yes it is meant to store distributed data 03:34:54 yes 03:35:11 Anyone is interested in doing this work? 03:36:22 ok .. I will take this up 03:36:33 althouugh its new for me .. but will see how to do that 03:36:33 Thanks shubhams 03:36:40 Appreciate it 03:36:56 I feel a bp is also needed for it 03:37:18 #action shubhams to create a bp for managing state of containers 03:37:28 i like to join too in that 03:37:39 Thanks itzdilip 03:37:50 You can work together with shubhams 03:38:05 Please feel free to ping me or hongbin anytime on this 03:38:06 thanks itzdilip 03:38:37 Do anyone has something to add? 03:38:43 sure I will 03:39:17 Also yuanying is good point of contact for same 03:39:53 mkrai, ok we will connect with yuanying 03:40:02 Thanks shubhams 03:40:16 Shall we advance topic? 03:40:26 yep 03:40:30 #topic Open Discussion 03:41:17 sudipto, We can continue the discussion 03:41:51 mkrai, well i guess i was trying to understand shubhams point on 'why nova is needed' 03:42:11 shubhams, Would you like to answer? 03:42:27 My point on nova integration was : Before going ahead , we should first note it down (may be on etherpad) that do we really want to work around "Nova" or we want a separate solution . 03:43:20 s/work around/work around with nova 03:43:22 shubhams, Separate solution for us is Zun itseld 03:43:42 Zun should be designed as independently as possible IMHO 03:43:59 Yes sudipto that we all agree 03:44:28 ok - i don't mean to derail the approach...please go ahead if you think it's needed :) 03:44:34 and it's something that can eventually fly. 03:44:44 I am sure there are probably strong reasons behind doing it. 03:44:47 This bp just aims to provision containers from nova as we provision baremetal 03:45:22 And that shouldn't impact Zun design at all 03:45:41 baremetal provisioning forms a pre-requisite to VM provisioning, i am not sure that's the case here. 03:46:25 if you ask me, i feel baremetal could be made as a pre-req for container provisioning - but that means an ironic integration to zun 03:47:08 That is the host where we run our container i.e host management 03:47:21 And we are not targeting host management in this bp 03:47:44 Exactly the same way nova-docker does 03:48:03 Yep .. so let host management be the responsibility of nova and container management is left for Zun , right? 03:48:39 shubhams, agree with later part 03:48:53 But host management is itself a huge topic in itself 03:49:03 think of it like this - if host management is done by nova or something else - why make zun worry about it? 03:49:21 Sudipto, agree 03:49:50 Host management can be independent of Zun. Operators can manage host or we might in future want to manage it ourself 03:50:46 It can be either we already have pool of host or we provision one at runtime 03:51:03 There are many options that we can think of 03:52:08 Team I want to record an action, whether we want to spend effort on this task? 03:52:13 I may be wrong but my whole point is : if we are creating something relevent to what already exists (ex: nova-docker) then we should we have clear boundaries and reasons that why we need the solution that we want to create. 03:52:31 +1 shubhams 03:52:35 and so far I am not sure why we need this 03:53:29 #action madhuri Add points why we want to integrate with nova on BP whiteboard 03:53:48 Team feel free to add any points that you have in mind 03:53:58 Yes sure 03:54:02 #link https://blueprints.launchpad.net/zun/+spec/nova-integration 03:55:01 Any more discussion do you want to have? 03:55:18 If not, I will end meeting early 03:55:36 seems ok to me 03:55:47 Thanks everyone for joining 03:55:58 thanks all 03:55:59 Thanks 03:56:02 #endmeeting