21:01:51 #startmeeting Networking 21:01:52 Meeting started Mon May 27 21:01:51 2013 UTC. The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:01:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:01:55 The meeting name has been set to 'networking' 21:02:25 #link https://wiki.openstack.org/wiki/Network/Meetings 21:02:30 #topic Announcments 21:03:47 H1 will be cut this week 21:04:34 I've started moving a few blueprints that are not complete or in review to H2 21:07:34 Before we run through the reports, I wanted to says thanks to OpenStack Israel organizing committee for putting together and hosting a great conference here and to garyk and sbercovici for being excellent hosts for me 21:08:14 markmcclain: it has been great having you over in our part of the world 21:08:21 it's exciting the exciting things happening in the OpenStack community up close 21:08:44 *to see 21:09:15 garyk: I definitely have a new appreciation for the midnight meetings :) 21:09:23 :) 21:09:26 Let's run through the reports 21:09:31 #topic API 21:09:58 Salvatore if off today, but has updated his section of the agenda 21:10:00 #link https://wiki.openstack.org/wiki/Network/Meetings#API_.28salv-orlando.29 21:10:59 the one item of note is modular L3 has been moved back to H2 21:11:21 the code is in review, but changeset is large because of the amount of code that has been moved 21:11:56 Salvatore and I will work through reviewing the patch 21:12:10 any questions on API? 21:12:54 #topic VPNaaS 21:13:10 nachi is off today as well, but has updated the agenda 21:13:41 there is a work in progress version of the VPN API code available 21:14:02 https://review.openstack.org/#/c/29812/ 21:14:15 take a look and any feedback you have to help out 21:14:34 #topic Nova Integration 21:15:01 garyk: hi 21:15:16 aloha 21:15:30 markmcclain: sadly there has not been much progress made with the migrations path 21:15:30 salv-orlando: hi 21:15:57 garyk: that's fine 21:16:04 markmcclain: nachi has made a patch for the driver which is still in review 21:16:21 is this the host_id patch? 21:16:32 markmcclain: rkukura https://review.openstack.org/#/c/21946/ 21:16:39 nevermind, that's gongysh's 21:16:55 rkukura: yes, that is yongs patch. 21:17:32 markmcclain: other than that nothing else toupdate on the nova front (sorry) 21:17:43 both effect port binding, which ml2 needs, and are still in review 21:17:56 rkukura: are they pre-reqs? 21:17:59 rkukura: do you have a link? 21:18:11 https://review.openstack.org/#/c/29767/ 21:18:13 markmcclain: https://review.openstack.org/#/c/29767/ 21:18:18 thanks 21:18:35 not a prereq for 1st merge, but for H-2 work 21:18:38 ah that's the nova side. 21:19:28 ok 21:20:14 I've made notes that those are needed for ML2 21:20:34 salv-orlando: I just pasted your link to the agenda 21:21:13 do you have anything you want add since you were not online for the API section? 21:21:58 #topics Security Groups 21:22:00 not really. I just wish to have you guys 21:22:20 for another review cycle on the only blueprint we're targeting now. 21:22:26 Otherwise I will untarget that as well. 21:22:47 hi 21:22:58 Nothing new to report on the security profile sections. I brought up moving the port creation from nova-compute to nova-api in order to allow quantum to decide if a port should be part of a default security group or not since nova is automatically putting everything in a default group right now. 21:23:01 salv-orlando: GW modes? 21:23:08 yup 21:23:18 Sumit is out but he has a review up for the inital fwaas framework here: https://review.openstack.org/#/c/29004/ 21:23:27 arosen: cool 21:23:29 He said that Ragjesh is making progress with the iptables driver and they should shortly have that part up for review too. 21:23:35 that's it. 21:23:59 arosen: thanks for the update 21:24:32 salv-orlando: looks like we have several cores on that review 21:24:37 I'll take a another look too 21:24:39 https://review.openstack.org/#/c/25525/ 21:24:58 it's you and amotoku 21:25:02 amotoki, sorry 21:25:23 If you're still in Europe tomorrow we can sort that out in the morning 21:25:28 ah no worries… it's important that the h1 items get review attention 21:25:39 yeah.. we can chat a bit in the morning when we're awake 21:25:42 unless you're planning on a beach trip :) 21:25:59 I've got 3g :) 21:26:24 #topic ML2 21:26:27 rkukura: hi 21:26:57 just posted non-WIP patch: https://review.openstack.org/#/c/20105/ 21:27:13 devstack patch: https://review.openstack.org/#/c/27576/ 21:27:26 cool 21:27:34 There is plenty more work to do, but I think what's there is enough for initial merge 21:27:51 main missing feature is GRE support, including tunnel endpoint RPCs 21:28:11 GRE seems like something we can add in a follow up patch 21:28:33 it's just a new driver right? 21:28:40 Also, not yet returning a useful binding:vif_type, which needs nova to set binding:host_id, so GenericVIFDriver cannot currently be used 21:29:03 GRE needs the GreTypeDriver which is very straightforward 21:29:15 And also the RPC methods for tunnel endpoint management 21:29:34 ok.. that seems a nice standalone approach so that we can get ML2 21:29:53 and others who want to start writing drivers will have something develop against 21:30:04 That's the idea 21:30:16 great 21:30:37 So review comments on WIP patch sets have all been addressed 21:31:05 If we get reviews, it could make H-1 21:31:07 thanks keeping the review up to daye 21:31:09 *date 21:31:41 yeah.. we'll have some time on Tuesday to review 21:32:34 anything else besides the related vif_type review you need to bring up? 21:32:52 not right now 21:35:20 do we have any cores that want to help review? 21:36:17 I think ML2 is going to be a long stream of patches across H-2 and H-3. So if this one is self contained, and does not break anything else, it might make sense to merge it 21:36:34 even if there are still several missing bits, which is more than understandable 21:36:45 salv-orlando: yeah.. that's my feeling too 21:36:51 i can take a look. 21:37:02 garyk: thanks 21:37:12 salv-orlando: would you mind being the other core? 21:37:24 I don't mind 21:37:35 salv-orlando: thanks 21:38:08 appreciated - also, gongysh, nachi, and arosen have looked at WIP versions 21:38:19 good stuff 21:38:37 Look Akihiro is offline, so we'll skip Horizon this week 21:39:00 #topics Other team reports 21:39:25 lbaas? 21:39:38 enikanorov: sorry 21:39:38 extra_dhcp_opts? 21:40:07 the LBaaS reviews haven't moved much this week 21:40:14 I sat down with Sam and Alex today 21:40:20 I'll fill you in offline 21:40:35 good, thanks. 21:40:52 dkehn: yes.. let's talke extra_dhcp_opts 21:41:02 * lifeless eyeballs the channel :) 21:41:12 #link https://review.openstack.org/#/c/30441/1/quantum/db/extradhcpopt_db.py 21:41:21 so during the review garyK brought the issue of a more genric approach 21:41:22 garyk posted a question there, to which I responded 21:41:26 metadata server? 21:41:29 * devananda let's dkehn talk :) 21:41:38 soory 21:41:57 just bring everyone up to speed.. the review implements 21:41:57 https://blueprints.launchpad.net/quantum/+spec/pxeboot-ports 21:42:01 go devananda , since its you response 21:42:20 k 21:42:39 so, baremetal (and ironic) both want to be able to have openstack networking 21:42:52 respond to dhcp boot requests 21:43:06 devananda: i have yet to go over the comments - i'll do so tomorrow. i do not think that is a blocking issue but may be worth discussing here 21:43:09 so we dont need to run a separate dhsmasq process 21:43:23 garyk: great! happy to hear it 21:43:38 our concern was that it seemed like you wanted a generic implementation in lieu of the existing one 21:43:46 the idea was to have matadata for each primitive. would be intersting to know what markmcclain and salv-orlando think about having the db modeil have metadat 21:44:11 it may make things more flexible moving forwards. 21:44:39 garyk, can you explain the flexibility? 21:45:23 dkehn: in order to implement the extra parameters you needed to change the datamodel for the db (migration etc.) 21:45:56 afaict from the review, it's already pretty generic. it looks like one could set arbitrary dhcp options (not just the boot options) 21:46:01 garyk: FWIW I'd be wary of reimplementing SQL DDL a layer up; it tends to perform very poorly :). [generic metadata vs structured data]. 21:46:03 so i'm not sure what you're suggesting to change 21:46:11 dkehn: if the quantum database had metadat support, then then we would not have had to do the update and one could have added values as a key:value pair. 21:46:23 garyk: you can start an offline discussion on metadata, I'd be happy to participsate 21:47:08 I tend to agree with lifeless. Tried that in the past. Very happy until it hit production scale. Very sad after that. 21:47:14 garyk, at preset more option in the db would just mean more extradhcpopts records, associated to a port 21:47:15 lifeless: understood. 21:48:06 scaling for this - for ironic we'll be setting 3 options per node 21:48:25 yeah.. this is first that I'd considered that for multiple objects.. my immediate concern is metadata tends to be a bucket where folks dump items that should be attributes to avoid changing database schema 21:48:37 a future backend-optimisation can coalesce identical options inside the dnsmaq options file 21:48:44 we want to scale this well past 100K physical nodes. 21:49:47 metadata fields aren't very different from json blobs 21:50:26 for what its worth, not having this is blocking some work in nova 21:50:27 true; but in this case the coalescing I refer to can avoid bringing back 300K rows from the DB - we might bring back 500 or so, depending on the # of ironic servers. 21:50:39 lifeless: the proposed db change has one option and one value. what are the 3 options? 21:50:43 thats much harder to do when the data is buried in a string 21:50:50 garyk: each option;value pair is one dhcp option. 21:51:10 garyk: the three options are the tftp filename, server name, server ip: three rows per port that is being PXE booted. 21:51:42 garyk: the future optimisation I'm referring to is a SELECT DISTINCT approach across that. 21:51:45 Its a none-> many 21:52:13 garyk: afaict the current patch is proposing 0:N opts, not 1, per port. 21:52:27 so it is extensible beyond just the 3 we currently need 21:52:31 dkehn: am i right ^ ? 21:52:32 poor garyk, three people answering every utterance :) 21:52:36 heh 21:52:41 it is 21:52:48 devananda: dkehn lifeless - i need to look at the patch in more detail 21:53:05 garyk: thanks, much appreciated 21:53:18 garyk: this is the single biggest operational headache for folk doing nova baremetal; *anything* we can do to get it landed, we're up for. 21:53:30 garyk: commensurate with it being a good idea, of course. 21:53:54 let's take a look and then we can discuss offline tomorrow 21:54:12 lifeless: i understand the urgency. 21:54:17 via review comments if there are any questions 21:54:20 thanks 21:54:44 #topic Open Discussion 21:55:17 Actually one other item I forgot to point out 21:55:17 https://review.openstack.org/#/c/27265/ 21:55:38 this review sync up the Quantum db code with Oslo which should bring improvements 21:56:02 those that have been running into evenlet and transaction oddities please take a look at this patch 21:56:25 Any other items for Open Discussion? 21:57:34 yes, a quantum bug day? 21:57:47 salv-orlando: +1 21:58:02 yeah.. I think that is a good idea 21:58:54 Try for one next week so that we can alert folks? 21:58:59 June 7th possibly? 21:59:00 what about Tuesday June 4th? 21:59:06 7th is good as well 21:59:33 salv-orlando: markmcclain tuesday is good 22:00:14 I've got meetings the 4th, but it is not necessary for me to be around if most folks are available Tuesday 22:00:53 I am fine with any day next week actually, excluding monday when I have other commitments 22:01:59 I'll send an email out and conduct a straw poll of the reviewes 22:02:10 k thanks 22:02:11 *reviewers and we'll a day when most of us can be around 22:02:29 any other item before we wrap up? 22:02:43 it has been a long day. i am going to crash. havea good one 22:02:47 #endmeeting