22:06:28 #startmeeting 22:06:29 Meeting started Tue May 17 22:06:28 2011 UTC. The chair is dendrobates. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:06:30 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:06:38 #topic quantum 22:06:41 thx 22:06:55 Ok, Salvatore is doing a great job driving the API work 22:07:05 comments on the api on etherpad: http://etherpad.openstack.org/PbTpgXnnZZ 22:07:15 Salvatore, do you have anything to add? 22:07:33 Just updated the etherpad. Apologies for vestigial stuff left in the API spec. 22:07:37 I'm updating it right now. 22:08:02 We might spend some time discussing Alex's proposals and comment. 22:08:05 Is Alex on the call? 22:08:08 no 22:08:11 he's flying right now 22:08:30 maybe just take those to the etherpad for discussion? 22:08:49 What were the main points? was "status" of a logical port one issue? 22:08:59 1) port status 22:09:07 2) interface URLs 22:09:13 which needed more explanation 22:09:27 ah yes, and port "capabilities" 22:09:29 3) Port capabilities 22:09:32 right 22:09:54 Ok. Given that I think we need more input from Alex on these, let's try to have that discussion on the etherpad. 22:10:03 Agreed. 22:10:13 salv-orlando, is there anything holding you up from making progress in the mean time? 22:10:37 No, I'm currently starting work on API implementation 22:10:42 awesome. 22:10:54 salv-orlando: cant wait! 22:11:09 Next up, Somik has been working on adapting Troy's "starter-code" for quantum. https://blueprints.launchpad.net/network-service/+spec/quantum-project-framework 22:11:11 I think there is agreement API will just be a pass-through for our first milestone, i.e.: No quantum db. 22:11:16 Sorry Dan... 22:11:27 I think savlatore is looking at that branch as well, right? 22:11:42 np 22:11:54 Yes, but I'm only a "follower" at the moment 22:12:03 Key area's we're looking for people to step are are: 22:12:08 1) API extensions framework 22:12:18 2) API auth + keystone integration. 22:12:41 Ryu + Troy are taking a lead on the nova side of changes for the network code. 22:13:01 I would like to help with that as well 22:13:13 dendrobates: the nova side changes? 22:13:19 danwent: yes 22:13:23 great. 22:13:34 dendrobates: that would be great 22:13:44 I think we need to work on cleaning up the existing blueprints in the nova project and getting more detailed blueprints focused on dev tasks. 22:13:48 troytoman: is there a branch? 22:14:19 https://code.launchpad.net/~midokura/nova/network-service 22:14:21 I think there is some confusion on the nova end, given the different blueprints still in nova from before the summit. 22:14:23 dendrobates: just the midokura branch. I think ryu is adapting it to work with multi-nic 22:14:35 thanks 22:14:39 I've been discussing the safest way to start the Nova changes with the core devs, and will create a branch for that 22:15:06 we're trying to get multi-nic in, then the network-service branch and we can look at extending from that base 22:15:29 sounds good. 22:15:34 is multi-nic proposed for merge? 22:16:02 nm, I'll look 22:16:04 we're close 22:16:19 but I don't think it's merge-propped yet 22:16:20 that is all I had for quantum. Please let me know if you're interested in API extension + API auth work. I'd really like to get someone putting some thought into that side of things. 22:16:54 #topic donabe 22:17:20 We are trying to get our legal ducks in a row at Cisco to start pushing code 22:18:13 As you can imagine we have to make sure that no one gets in trouble. but we are spinning up a couple of dev teams and expect to push soon 22:18:29 very cool 22:18:51 in the mean time we might have some of the devs help vish with unit tests and the like 22:19:06 #topic other stuff 22:19:17 updates on melange 22:19:28 please skim: https://github.com/tv42/melange-discovery/blob/master/melange-discovery.rst 22:19:39 we've started work on the base service: 22:19:41 lp:~rajarammallya/network-service/melange_framework 22:19:42 i'd like to talk to people about the IPAM protocol, what data is transported etc 22:20:23 I hope to be able to share a draft API later this week. we have the start of it but there are some things to clean up 22:21:00 As tv alludes to, I think we need some work on overall flow though. 22:21:34 and i'd like to talk to somebody on the nova firewall side, what do they think about about MITM prevention etc 22:21:48 how do we associate a quantum network with an IP block? Does Nova establish both and create the link? or do it through quantum? 22:21:48 Tv: I recommend soren 22:21:56 as in, if there's egress filtering the vm only uses the addresses its allowed to use, then the dhcp component needs to inform it, etc 22:21:59 troytoman: Did you plan on having Melange log all the uses of an IP over time to it's database. With the recent announcements of EC2 being used for bad things, it may be useful. 22:22:36 carlp: we have not started logging yet. but, we can add that as a requirement. 22:23:01 tv: what MITM attack are you referring to specifically? 22:23:20 rogue DHCP? 22:23:30 or more general? 22:23:30 should we set up an etherpad to jointly work through the flows between Nova/Quantum/Melange? 22:23:42 yeah, probably easier than trying to use IRC :) 22:23:42 troytoman: awesome. I have some ideas that may help with that, but I'll wait until we have some code before throwing them at you :) 22:23:52 danwent: rogue DHCP, ARP proxy, spoofed source, ... 22:23:54 troytoman: I think so. IRC is hard for this 22:24:08 let's move this to etherpad 22:24:57 is that all for melange? 22:25:03 i think so 22:25:04 Tv: I think this is a Quantum problem, not a nova problem 22:25:05 danwent: the part that ties in with the DHCP most is the dynamic part; your vm should not be able to send packets as 10.0.0.3 outside of the time you hold a valid lease for that IP address 22:25:38 romain_lenglet: i think parts of it are irrevokably tied to current IPAM state 22:25:38 I see, you are talking about general spoofing filters. 22:26:09 yeah basically two things: 1. general MITM prevention 2. enforcing address allocation 22:26:13 a provider may or may not want to enforce such filters on a given interface. 22:26:24 1. is nova or quantum, 2. is also nova or quantum but requires IPAM knowledge 22:26:29 Tv: both problems are Quantum problems 22:26:35 not nova 22:26:42 the github url i pasted earlier talks about having the dhcp server notify local firewall how to update rules for #2 22:26:48 agreed that it's tied to IPAM integration 22:26:58 romain_lenglet: i'm saying nova only because this thing is being pushed to happen faster than quantum, afaik ;) 22:27:16 We need to make sure that everyone that submits code to any of these projects has signed the openstack CLA 22:27:23 let's make sure the flows we discuss includes an example of a spoofing filter. 22:27:26 if we want to become official projects 22:28:16 I am working with the infrastructure people to setup a testing environment and we will soon be checking CLA compliance at merge 22:28:38 great 22:29:01 do we want to do this time and day every week? 22:29:12 works for me 22:29:17 I'll update the wiki, if there are no objections 22:29:24 works for me as well 22:29:26 +1 22:29:39 still good for me 22:29:43 cool. I have a hard stop now. 22:30:06 nothing more from me. 22:30:19 Ok, let's just circulate the etherpad link for joint melange-quantum-donabe discussion 22:30:20 someone please send out an etherpad for the IPAM discussion 22:30:25 :) 22:30:28 feel free to carry on, but I'll stop the recording now 22:30:33 #endmeeting