21:03:48 #startmeeting networking 21:03:48 Meeting started Mon Aug 19 21:03:48 2013 UTC and is due to finish in 60 minutes. The chair is markmcclain. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:03:49 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:03:51 The meeting name has been set to 'networking' 21:03:51 can i go back to sleep :) 21:04:04 #link https://wiki.openstack.org/wiki/Network/Meetings 21:04:38 this one will probably run a little longer than 30s 21:04:44 #topic Announcements 21:04:59 #link https://launchpad.net/neutron/+milestone/havana-3 21:05:32 #info The feature proposal freeze is end of day Friday August 23rd 21:05:40 #link https://wiki.openstack.org/wiki/FeatureProposalFreeze 21:06:24 We're actually looking pretty good for this deadline. We've got almost everything already proposal 21:06:36 s/proposal/proposed/ 21:07:18 which means we'll spend the next 2 weeks reviewing/merging and closing out the critical bugs 21:07:21 #topic bugs 21:07:30 #link https://bugs.launchpad.net/neutron/+bugs?search=Search&field.importance=Critical&field.status=New&field.status=Confirmed&field.status=Triaged&field.status=In+Progress 21:08:06 We've got 3 open critical bugs 21:08:14 https://bugs.launchpad.net/neutron/+bug/1208661 21:08:16 Launchpad bug 1208661 in neutron "nova show command sometimes don't includes ip address" [Critical,In progress] 21:08:17 and 21:08:24 https://bugs.launchpad.net/neutron/+bug/1210483 21:08:27 Launchpad bug 1210483 in neutron "ServerAddressesTestXML.test_list_server_addresses FAIL" [Critical,Confirmed] 21:08:34 are related to bugs discovered tempest testing 21:08:40 Accoding to 1208661, 21:08:51 Sometimes, nova show didn't has ip address. 21:09:08 I can't reproduce it yet, but I send devstack patch for adding more logging. It is merged now 21:09:15 so We may get more hint 21:09:33 May be we can drop priority for high, because error late by this one is not so high 21:10:00 ok 21:10:53 any other critical or high bugs we need to discuss? 21:11:11 yes 21:11:32 the gate blocking bug is fixed, waiting on a merge of the renabling patch 21:11:57 there is a bug in the grenade gate that is delaying approval, but hopefully it goes in before any other bugs slip through 21:12:11 marun: do you have a number? 21:12:38 https://bugs.launchpad.net/devstack/+bug/1210664 21:12:40 Launchpad bug 1210664 in tempest "neutron can't setup basic network connnectivity in gate jobs" [Undecided,In progress] 21:12:55 the fixes are in, it's just the tempest patch to enable the connectivity check that is pending 21:13:07 ah cool 21:13:17 marun, markmcclain: the latest gating issue led me to think that probably we should try and cover more scenarios in tempest. What do you reckon? 21:13:37 salv-orlando: no comment 21:14:12 salv-orlando: the lack of good lower-level testing make adding more scenarios a problematic choice 21:14:45 cool. Thanks for the input. I don't think this is the right meeting topic 21:14:45 \ 21:14:51 so let's move on. 21:14:55 fair enough 21:15:44 salv-orlando: yeah I think we to bulk up the tests on a few different levels.. we should definitely setup a discussion on this 21:15:57 cool 21:16:01 Any other bug items? 21:16:31 https://review.openstack.org/#/c/42737/ 21:16:49 This is third times duplicated work for multi workers. 21:17:00 # I'm not sure we should talk on it now 21:17:34 yeah.. this not really a bug as much as a new small feature 21:17:57 Whatever is finally merged, is there consensus that a non-threaded mode is desirable to aid in debugging? 21:18:34 there is a bp for multi-workers 21:18:47 Ok I'll -2 for this patch, and let's go on meetings 21:19:08 jackmccann: right.. I think that is where the duplication occurred because one version filed via BP and the other via a bug 21:19:38 markmcclain: so https://review.openstack.org/#/c/36487/ is correct one? 21:19:41 marun: yes it is nice to be able to trigger single threaded mode at times 21:20:39 nati_ueno: possibly I'll compare the different versions after the meeting 21:20:46 markmcclain: I'll make a note on the bp 21:20:53 marun: thanks 21:21:08 #topic docs 21:21:09 markmcclain: Ok so could you -2 for https://review.openstack.org/#/c/42737/. After you decided correct one 21:21:24 nati_ueno: done 21:21:32 markmcclain: Thanks 21:21:39 Paul M. committed the VPNaaS API: https://review.openstack.org/#/c/41702/ 21:21:52 reviews are welcome! 21:21:56 and needed! 21:22:00 yes sir! 21:22:05 oo! With samples, nice. 21:22:06 pcm_: thanks for writing the docs 21:22:30 o/ wanted to ask a Q 21:22:52 annegentle: hi.. go ahead 21:23:13 The doc team is noodling on two things - 21:23:40 one is, assigning a "doc lead" per team. emagana has been doing a great job at this, just wanted to let you all know we want to replicate across teams 21:24:08 basically the doc lead will help triage doc bugs and help get info. emagana is good at this :) 21:24:15 annegentle: Thanks!! 21:24:28 two is, we're probably going to "only" release the Install Guide and a Config Ref for Havana 21:24:50 this means a couple of things - the Network Admin Guide may have some sections deleted/moved 21:25:11 +1 I think having a doc lead is needed role 21:25:42 ok.. is there a preliminary list of sections to be cut or it too early? 21:25:45 It's possible the Network Admin Guide will fold into the Config Ref. I was able to do that for the Block Storage Admin Guide. 21:25:48 Not so sure it'll work on the Network Admin Guide, but, it is a ton of config 21:26:27 markmcclain: for example, move install info into the install guide with one patch 21:27:04 ok.. agreed the network guide is definitely a lot of config 21:27:08 markmcclain: your Admin guide is one I hate to do too much to, but it is mostly config 21:27:39 markmcclain: all of this is to try to offer "OpenStack unified docs" rather than project-by-project... it's still under discussion 21:27:50 markmcclain: but I want to bring it up at individual project meetings to get input and feedback 21:27:58 make sure we're not missing something obvious, and so on 21:28:11 since neutron's core it's pretty easy to say what "has" to be documented 21:28:22 Integrated, it's harder to say. 21:28:38 So just wanted to share and let you all know what' we're noodling on ahead of release 21:28:50 And, I want the teams to be able to know where to put docs 21:29:04 questions? 21:29:41 annegentle: How about API guide? 21:29:51 nati_ueno: the API guide remains the same 21:29:57 annegentle: gotcha 21:30:06 thanks for sharing.. .I think unified docs make for a better user experience so I'm glad the discussion is occurring 21:30:10 this discussion is all about "release" docs 21:30:26 API docs are ongoing 21:30:37 markmcclain: thanks for having a docs topic in your meetings! 21:30:59 * annegentle is done now 21:31:12 annegentle: I tend to agree with a unified admin guide for all openstack projects. My only latent concern is that it will become a sort of encyclopaedia (i.e.: huge set of books) 21:31:25 a bit like windows NT administrator guides 21:31:49 salv-orlando: oh believe me I share that concern :) it's intimidating as can be. 21:32:18 salv-orlando: I think the Operations Guide struck a balance, but it doesn't have SDN to speak of 21:32:51 it's totally possible that Networking needs its own guide 21:32:55 annegentle: SDN? what is SDN? ;) we understand only neutrons here 21:33:00 salv-orlando: hee hee 21:33:08 * mestery chuckles. 21:33:26 what's your sense of Who are the admins? Operators? Network admins? Sys admins? 21:33:47 we have done some user analysis with the user committee's data but would like your sense of it too 21:34:00 In my experience, we get all of them - but I do not have a lot of data points. 21:34:07 salv-orlando: yep 21:34:27 my experience has been a random mix of folks too.. really depends on the size of the deployment 21:35:19 Any other doc items? 21:35:23 markmcclain: yeah at a meetup in Austin 2 months ago I ran into a few network admins but they are few and far between. And they don't like SDN that much (security concerns mostly it seemed, like "you're gonna let users do what with my network? ) 21:35:32 hah 21:35:32 elect doc lead for Neutron? 21:35:40 new bug file for Mellanox plugin: https://bugs.launchpad.net/openstack-manuals/+bug/1214117 21:35:42 Launchpad bug 1214117 in openstack-manuals "Include Mellanox plugin in networking guide" [Undecided,New] 21:35:48 salv-orlando: emagana volunteered! I don't wanna add more governance :) 21:36:01 so emagana is 21:36:30 :-0 21:36:41 salv-orlando: though I consider you the point for API docs 21:37:11 +1 for emagana :) 21:37:29 annegentle: Yup, I am still the API docs guy. 21:37:59 speaking of the API 21:38:04 #topic API 21:38:07 I haven't yet been moaning about API docs for the new features, because the guys have been really busy with the admin docs 21:38:20 but I will begin moaning, or barking, soon. 21:38:49 Codewise, everything is quiet on the API side. 21:38:58 except for the commit discussion 21:39:01 However, there is this thing about commit logic for Fw rules 21:39:09 markmcclain: yup 21:39:17 I am happy to move the discussion to gerrtit 21:39:28 unless we feel we want to chat about it here 21:39:35 in which case I suggest the open discussion topic 21:39:43 as we're already 42 mins into the meeting 21:39:54 ok.. let's focus the discuss on the review 21:40:07 #topic VPNaaS 21:40:34 OK still codes are in review. 21:40:40 nati_ueno: seems to be a bit of progress this week on whether to support openswan or strongswan 21:41:22 I understand the reason for switching 21:41:23 markmcclain: I'm going to support both. because RHEL only support openswan 21:41:24 markmcclain: Ah no, we don't switch, I'm adding both 21:41:24 but wondering whether the burden will higher than if we just picked one 21:41:49 which would have to be openswan unless strong could be included in RDO correct? 21:41:53 markmcclain: it should be 200-300 line review burden https://review.openstack.org/#/c/42264/ 21:42:08 ok 21:42:24 markmcclain: so in other hand, may guys want to use StrongSwan, 21:42:39 markmcclain: so 200-300 lines code is good for this 21:43:00 markmcclain: also who don't like mounting can use openswan version 21:43:03 nati_ueno: too much free time :P 21:43:23 marun: free time? 21:43:27 right.. the burden will be more on docs and support as the there will be differences 21:43:28 nati_ueno: is that patch for strong swan or open swan? 21:43:37 nati_ueno: if resources are limited, pick one and get it right before supporting two 21:43:43 salv-orlando: 42264 is for openswan 21:44:21 cool the commit message confused me a bit (first line says openswan and the 2nd says 'wii' to support also openswan) 21:44:35 salv-orlando: Ah sorry the patch is still WIP 21:44:41 so you will have a single driver for both openswan and strong swan? 21:44:44 or two drivers? 21:44:50 salv-orlando: Two drivers 21:44:56 OK so let's choose 21:45:06 ok - so chances of strong swan support breaking open swan are negligible? 21:45:09 A) 1 driver with StronSwan 21:45:13 B) 2 drvier 21:45:18 C) 1 driver with OpenSwan 21:45:31 salv-orlando: I believe so 21:45:50 let's take a look at the reviews and can discuss this more over the ML 21:45:51 Anyway, in future, we will have multiple drvier. so discussion is for H3 21:45:51 I will vote for the safest solution, i.e.: the one in which I know openswan driver works pretty much everywhere. 21:46:24 markmcclain: gotcha 21:46:41 markmcclain: please note the openswan support is in WIP 21:46:48 That's all from me 21:46:53 nati_ueno: noted… thanks for the update 21:46:55 #topic Nova 21:46:59 garyk: hi 21:48:09 #undo 21:48:10 Removing item from minutes: 21:48:17 #topic FWaaS/SG 21:48:39 hi 21:48:44 for FWaaS - Driver patch was merged, nice work RajeshMohan, and thanks to the reviewers 21:48:54 Devstack patch (rchunduru) and Horizon patch (KC) are awaiting (hopefully) a final push from the reviewers 21:49:08 and of course - the "hot" topic as voted by salv-orlando - commit API :-) 21:49:29 I removed the WIP on the commit operation patch over the weekend, it's ready for review 21:49:38 RajeshMohan has started CLI work for this 21:49:52 thoughts/questions/comments? 21:50:00 (my update is done) 21:50:24 I am reviewing the code, even if I will now suspend and resume when i wake up. I will comment on gerrit 21:50:34 salv-orlando: thanks 21:50:52 gerrit is a good place to focus the discussion 21:51:17 #topic LBaaS 21:51:32 enikanorov: hi 21:51:37 hi 21:51:56 two major patches are pending 21:52:21 integration with service type framework - I think we need some discussion about noop driver 21:52:56 nati_ueno has a followup patch that applies the same approach to vpnaas 21:53:37 SumitNaiksatam: FWaaS is going support this? 21:53:54 nati_ueno: not in H3, there isn't' enough time 21:54:06 it wasn't planned to begin with 21:54:10 SumitNaiksatam: ok 21:54:16 the initial issue, to give more context, is 'what happens when a provider is removed'? 21:54:49 there are a couple of issues, I believe. but right, that is where it started 21:55:02 it seems, from previous discussions, that this a sort of 'natural' use case, and neutron should take steps for 'salvaging' orphaned resources 21:55:27 now, which steps should be taken, and how orphaned resources should be treated is what is being discussed 21:55:43 i think it's a part of the question 21:55:46 It seems there's wide agreement on the communities working on VPN and LB on this approach 21:55:56 I don't know what people working on FW think of it. 21:56:03 more generic is whether to allow update on 'provider' attribute 21:56:46 IMO, we need provide way to remove a provider for admin 21:57:17 i don't see why it should be restricted to admins, actually 21:57:49 Exactly what problem are you aiming at tackling for the Havana release? 21:57:51 I agree with enikanorov that should we restrict a tenant from switching for simplicity the answer for Havana might be no or will be something outside the scope we'll support 21:57:58 *should not 21:58:00 if we ever allow changing providers for the resource, we must support removing provider from resource as well 21:58:10 that would be logicaly natural 21:58:52 and it also will cover the case of 'removed' provider 21:59:20 agreed.. honestly this feels a like a good summit session instead of something the cram in at the last minute 21:59:47 My option would be to just deal, if we want, with the configuration issue arising from removing a provider which is used by active resources 21:59:59 My comment is for H3, so "at least admin can remove provider" 21:59:59 ok. another phrasing could be 'creating pure logical resources' 22:00:13 and as markmclain suggest, discuss provider associates updates and unbound resources at the summit 22:00:32 We're running short on time, so we can carry this over to a ML discussion 22:00:50 #topic ML2 22:00:50 ok, sure 22:00:50 enikanorov: I think you'll find people arguing all neutron resources are purely logical, but let's move on 22:00:50 mestery: want to update? 22:00:58 marmcclain: Hi 22:01:31 So, ML2 is coming along nicely. We're tracking the 2 final BPs for H3 now (port-binding and multi-segment API). 22:01:41 We are striving to get reviews out for those before feature freeze. 22:01:59 Also, some MechanismDrivers are close to merging as well, so that's good news. 22:02:09 good news all around 22:02:10 Overall, ML2 is humming along nicely. 22:02:17 thanks for the update 22:02:27 markmcclain: sure, thanks! 22:03:02 #topic Open Discussion 22:03:21 As I mentioned a couple of weeks ago, we’re submitting a (potentially controversial) proposal for managing multivendor multi-instance phys/virt L3-L7 resources. We’re talking about Icehouse, not Havana. We plan to demo a proof-of-concept implementation in Hong Kong and discuss including it in the Icehouse program. I’ve just posted the Blueprint: it’s at https://blueprints.launchpad.net/neutron/+spec/dynamic-netw 22:03:29 -2 minutes left for open discussion 22:03:33 -3 even 22:03:52 FYI we can see list of reviews here http://status.openstack.org/reviews/#neutron sorted by priorites 22:04:03 geoffarnold: Thanks for the link, will take a peek at this. 22:04:07 geoffarnold: make sure you submit a design session when it opens 22:04:10 geoffarnold: broken link? 22:04:14 geoffarnold: broken link 22:04:24 https://blueprints.launchpad.net/neutron/+spec/dynamic-network-resource-mgmt 22:04:53 with the conference and summit running concurrently it is hard for many on the core team to see too many conference sessions until the videos are posted 22:04:56 Full version here: https://wiki.openstack.org/wiki/File:Dnrm-blueprint-001.pdf 22:05:25 I've submitted a conf session; I'll submit a design session too 22:05:44 Any other open discussion items? 22:05:57 since enikanorov pointed out we're over time :) 22:06:07 :) 22:07:17 I want to thank everyone for their hard work getting the proposals in on time 22:07:49 Be on the lookout for a few discussions to spring up the ML or the gerrit reviews we discussed 22:07:53 #endmeeting