16:01:04 #startmeeting networking_ml2 16:01:05 Meeting started Wed Jul 8 16:01:04 2015 UTC and is due to finish in 60 minutes. The chair is Sukhdev. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:01:06 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:08 The meeting name has been set to 'networking_ml2' 16:01:32 #topic: Agenda 16:01:37 #link https://wiki.openstack.org/wiki/Meetings/ML2 16:01:45 Good morning folks 16:02:05 hi 16:02:18 #topic Announcements 16:02:35 I do not have any specific announcement on the agenda 16:02:45 does anybody have any announcement? 16:03:03 yes.. hold on 16:03:12 * Sukhdev waiting 16:03:23 the last date for talks is 17th for submissions of talks 16:03:40 am i right? 16:03:52 shivharis: for Tokyo summit? 16:03:56 yes 16:04:02 shivharis: No it is 15th July 16:04:18 ok, it is fast approaching so best to remind folks 16:04:21 Sukhdev, shivharis: RIght, email says the 15th 16:04:40 Good point shivharis - thanks for reminder 16:04:57 BTW, I am proposing one talk for the main session - 16:05:06 for design summit - we have lots of time 16:05:34 Sukhdev: What’s your topic? 16:06:02 rkukura: not finalized yet - but, it will be on the lines of Ironic/Neutron integration 16:06:12 Arvind and I are proposing topology as a service 16:06:37 shivharis: I was thinking of that for design session 16:06:52 shivharis: I mean for design session for sure 16:07:06 actually the touch points of this is both in nova and neutron 16:07:32 i am getting Nova folks about this 16:08:01 shivharis: you should do the same way as i did in last summit - present in design session for both projects 16:08:27 exactly - Arvind and I were thinking that way 16:08:56 shivharis: yup - that will be a good idea 16:08:57 but i dont want to lose the opportunity to do a talk in the general sessions 16:09:24 shivharis: sure - you should try that too 16:09:25 sukhdev: The main track is to get a broader audience to present the scope of the project 16:10:01 asomya: correct - if you can get them to approve it 16:10:12 and sometimes it helps developers understand it. 16:10:30 asomya: I think this will be good for both sessions 16:10:36 amotoki: agreed, design talks are a must for both Nova and Neutron 16:10:51 Sukhdev: Agreed, maybe we can have both? 16:10:53 Sukhdev: +1 16:11:22 shivharis asomya: But, first you have to present it to us - here :-):-) 16:11:32 Sukhdev: +1 16:11:40 +2 16:11:43 shivharis: I am not sure what projects are related to your proposal. only nova and neutron? it is out of scope of this meeting though... 16:11:55 anyways, I have it on agenda for today's discussion - so, hold on to your seats :-) 16:12:08 amotoki: The first iteration is a bit Neutron and nova focused, the scope can be expanded later to storage etc. as required 16:12:27 asomya: +1 16:12:53 asomya: thanks. I just feel so from the word "topology as a service". 16:13:03 amotoki: why do think it out of scope - I think in Neutron, this is more applicable to ML2 drivers than anything else 16:13:42 Sukhdev: ML2 driver is a consumer 16:13:52 Sukhdev: Like amotoki said, it's a generic topology service that can be consumed by any other service .. neutron/ml2 is just one of them 16:13:53 Sukhdev: "out of scope of the meeting" is confusing... sorry, precisely speaking, the current topic is "announcement". 16:14:28 but topology as a service is not specific to ml2. 16:14:35 amotoki: ah ha got it - yes, I have this topic on the agenda 16:15:06 speaking of that - lets get back on track to the agenda 16:15:21 #topic: Action Items 16:15:47 rkukura: was going to work with manishg to finalize the ML2 mid-cycle 16:16:09 Sukhdev: I think discussion is going via email with all those interested. 16:16:10 I noticed we have lots of discussion on this, but, we need to finalize the details and plan 16:16:40 I think we have all participants here - shall we finalize it here now? 16:16:47 and looks like next week is out. So likely dates are late Aug or early Sep (due to other conflicts and release schedules). 16:16:57 Sukhdev: sure 16:17:17 manishg: based upon the emails, it seems like early sept is best - 16:17:32 Sukhdev: sounds good to me. how about others? 16:17:48 rkukura made a good point that this will not go into liberty anyway - so, might be better to plan a bit better 16:17:59 Early Sept works best for me at this point 16:18:10 week of Sep/7 will be a short week. 16:18:46 manishg: is that labor day week? 16:18:47 feature freeze is the first week of Sep. 16:18:52 isn't it too late? 16:19:05 it's just a question 16:19:15 amotoki: we are thinking that we will push it for M release - 16:19:19 Sukhdev: I think so. 16:19:27 got it. 16:19:56 BTW if you are having issues of hosting, i can arrange taht 16:19:58 So, shall we do in the week after the labor day week? 16:20:40 shivharis: now we have three bids on the table - shall we start the bidding - I do not take less than $100 bills :-) 16:20:52 $0 16:20:53 just kidding :-) 16:21:04 jk 16:21:30 who wants to take the action to finalize this - ie. who is hosting, where, when, etc….? 16:21:52 rkukura: has already put together an ehterpad for this 16:22:05 #link: https://etherpad.openstack.org/p/Neutron_ML2_Mid-Cycle_Sprint 16:22:08 I just need a weeks headstart to arrange 16:22:24 the venue 16:22:33 Is everyone OK with early September in the Bay Area? 16:22:46 rkukura: yes 16:23:08 shivharis: you are third in the line - $500.00 brings on the top of the line :-) 16:23:15 And the idea of doing the work on a branch, hopefully to merge in early M? 16:24:19 I’ll update the etherpad to try to identify a week in early September 16:24:24 rkukura: +1 16:24:49 I’ll list each week and ask people to put their name with Y or N. 16:24:52 rkukura: looks like you are volunteering for planing this 16:24:57 yes 16:25:19 yay!!! - thanks rkukura - I will assign you an action 16:25:28 I’d like to nail down the dates by next Wednesday’s meeting 16:25:53 #action: rkukura to coordinate with rest of the team to finalize the detailed plan for ML2 mid-cycle sprint 16:26:07 So if you are interested in participating, please get your name onto the etherpad and we’ll include you in any emails. 16:26:26 anything else on this topic? 16:26:42 so lets call it late-cycle. It is more accurate and defenitely more cool. 16:26:52 rkukura: I have possible one volunteer from Arista who might join as well - 16:26:52 One last detail is which projects in addition to async will be worked on at the mid-cycle 16:26:59 rkukura: actually put ur name as attending + interested and not attending 16:27:23 split of ML2? 16:27:49 rkukura: make sure banix is there to head the cheerleading staff 16:28:16 would be a good idea to move to a separate repo before branching if we are going to do that 16:28:23 banix: kidding aside you have a good point 16:28:32 "pre-cycle sprint for M**" rather than "mid-cycle" 16:28:50 rkukura: I was thinking stackforge - but, that may be too heavy handed 16:29:23 I think a feature branch in the same repo where ML2 lives would be fine. Any reason to do it in stackforge instead? 16:29:28 github for sure maybe not stackforge 16:29:40 rkukura: like ur idea 16:29:58 We want to be able to easily rebase the branch as other changes are merged 16:30:49 I only thought of stack forge so that this can be released as a package and anybody who wants to play with it can pull it from pypi 16:31:17 Sukhdev: Worth considering. Lets get back to that at a future meeting 16:31:20 but, I am OK either way - do not want to make it too heavy handed thought 16:31:36 pypi can deal with branches, i think 16:32:09 shivharis: not sure - you may be right - may be worth looking into this 16:32:30 Any ways - lets move on 16:32:54 #topic: L2 modular agent 16:33:20 banix: want to give us the details - 16:33:44 banix: I mean update - 16:33:59 Sukhdev: I haven’t made any progress; trying to consolidate wrt ungoing enhancement to the agents 16:35:10 I think "modular agent" has several aspects: 16:35:18 modularity for features 16:35:21 yamamoto - anything you want to share? 16:35:25 modularify for backends 16:36:13 amotoki: correct 16:36:46 re: the first point, ajo proposal is worth considered. 16:37:33 Sukhdev: ? 16:37:55 Sukhdev: about modular agent? nothing from me 16:38:09 yamamoto: sounds good - 16:39:11 anything else on this topic? 16:39:23 * Sukhdev waiting 16:39:45 #topic: Physical Topology Discussion 16:39:52 banix: could you update the progress in bug 1468803? 16:39:52 bug 1468803 in neutron "Modular L2 Agent" [Undecided,Confirmed] https://launchpad.net/bugs/1468803 16:40:01 or it there any place to see? 16:40:15 #undo 16:40:16 Removing item from minutes: 16:40:37 amotoki: will do 16:40:49 banix amotoki : thanks 16:41:03 #topic: Physical Topology Discussion 16:41:18 shivharis asomya: Folks want to give us some update? 16:41:33 got any link to share? about your work so far? 16:41:48 We are in the process of refining the design 16:42:05 we are discussing this with folks in Nova 16:42:14 shivharis: care to share what ever you have? 16:42:34 as discussed earlier it will have touch points in both nova and neutron 16:42:43 possibly cinder as we go forward 16:43:12 shivharis: is it realted to scheduler or more? 16:43:19 we will share it in the next week or two and possibly at the early M meeting we are planning 16:43:38 amotoki: right 16:44:11 the input to db model will be getting info of the host ids from nova 16:44:11 shivharis asomya: I am a bit lost here about this service 16:44:43 shivharis asomya : Are you actually doing any work to tie it with any of these projects or just a white paper? 16:45:00 we will present the entire picture in the pre-M meeting we are planning 16:45:21 Sukhdev: A high level overview, it's a generic topology manager that can store and retrieve topology, anything can ask or store topolgy via the API 16:45:41 asomya shivharis: there is a prior work done on this topic by issaku - which was presented in Atlanta summit - have you seen it? 16:45:49 is it on the same lines? 16:45:51 Sukhdev: asomya what first primary use case do you have in mind? 16:45:52 currently it will be nova and neutron - the design will not exclude cinder 16:46:17 yamahata: The primary use case is Neutron and nova 16:46:18 s/Sukhdev/ shivharis / 16:46:57 asomya: VM scheduling? 16:47:06 at a high level there are discovery agents feeding the topology discoverd to a consolidator 16:47:25 yamahata: Getting hardware information required by driver and plugins to configure the physical fabric 16:47:42 i think yamahata is asking what is the main target as a high-level goal. what can it achieve? 16:47:43 the consolidator will expose an API that can be queried by any project 16:48:26 asomya: then your first goal is to abstract fabric management? 16:48:51 amotoki: exactly. thanks for explanation. 16:48:52 the main target at a high level to begin with with will be neutron or ML2 16:49:02 yamahata: expose it rather than abstract it 16:50:02 shivharis asomya : Are you working on a POC, along with a use case, for this or it is just white paper? 16:50:22 POC is underway 16:50:25 i think what asomya means is to export it in a unified/general way 16:50:47 shivharis: good 16:51:39 shivharis asomya: So, this leads me to the next question - we were planning on working on this during mid-cyle (or late-cyle or pre-cycle) sprint - 16:52:02 Do we still need to put on the agenda for the sprint - 16:52:29 without having much information about it, it may be hard to dive into the implementation - 16:52:46 Sukhdev: This is outside of Neutron, development is independent. we can talk a bit about API refinement etc in the late-cycle 16:54:00 asomya: so, this is not really targeted to be implemented in the sprint then, right? just for the discussion - am I getting it right? 16:54:08 Sukhdev: correct 16:54:34 asomya: thanks - this clears my confusion 16:55:05 rkukura: so, you can update the etherpad accordingly so that people have right expoctation 16:55:16 ok 16:55:24 anything else on this topic? 16:55:47 asomya shivharis: Thanks 16:55:55 does this relate to metering monitoring efforts? 16:56:05 already being undertaken 16:56:13 banix: no 16:56:22 I mean there are coceptually similar 16:56:23 banix: I do not think so 16:56:36 s/there/they/ 16:57:18 banix: I would say - metering will query information from the known components - physical topology will discover components 16:57:27 banix: for a lack of better words 16:57:38 Sukhdev: i see. thanks. 16:58:16 physical topology helps you discover how your DC topology looks like so that you can make placement decisions 16:58:41 once the VMs are placed, then metering kicks in to monitor how they are performing 16:58:52 time check, 2 mins 16:58:56 banix: hope this helps 16:59:05 shivharis: thanks 16:59:11 well, i have to learn more about the proposed project; i see convergence with discovery/monitoring of virtual resources…. but i am probably off the tracks 16:59:13 #topic: Ironic Discussion 16:59:21 I will be short and sweet - 16:59:43 banix: perhaps it is about network topolgy about virtual reosurces, ie tenants. 16:59:51 For those who do not know - there is a lot of work going on in the Ironic/ML2/Neutron integratipon 17:00:28 Sukhdev: what’s the best way of tracking that work/ learn about them 17:00:43 Sukhdev is making great work. 17:00:43 since we are out of time - let me post the link so that you can discover/read on your own 17:00:56 #link: https://wiki.openstack.org/wiki/Meetings/Ironic-neutron 17:01:17 Sukhdev: thanks 17:01:26 banix: the meetings take place every monday at 9am (PT) at #openstack-meeting-4 - please come join us 17:01:49 amotoki is one of the active reviewer of the work being done there 17:02:05 Sukhdev: will try to attend 17:02:29 The idea is that ML2 drivers should be able to deal with VMs as well bare metal deployments 17:02:39 we are out of time folks 17:02:47 thanks for attending the meeting 17:02:54 have a wonderful day 17:02:54 bye 17:02:56 bye 17:02:59 #endmeeting