22:00:19 <danwent> #startmeeting
22:00:19 <ttx> danwent: floor is yours
22:00:19 <openstack> Meeting started Tue Oct 18 22:00:19 2011 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:20 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:00:25 <danwent> thanks ttx
22:00:36 <edgarmagana> Hi Folks!
22:00:39 <danwent> hello netstackers
22:00:52 <carlp> Hi!
22:00:54 <zykes-> hmmm, cloudserver having a bad day ? :p
22:00:55 <RamD> Hello All
22:01:06 <salv-orlando> hi
22:01:06 <SumitNaiksatam> Hi
22:01:13 <danwent> ok, agenda: http://wiki.openstack.org/Network/Meetings
22:01:26 <danwent> any general discussion before we jump into project updates?
22:01:32 <danwent> general announcements rather
22:01:36 <danwent> (open discussion will be later)
22:01:48 <danwent> is troy here?
22:02:13 <danwent> ok, we'll start with quantum and switch to melange later if troy shows up.
22:02:17 <danwent> #topic Quantum Status
22:02:27 <danwent> carlp: you're up first
22:02:27 <troytoman> o/
22:02:46 <danwent> ah troy..
22:03:01 <danwent> Ok, let's switch over and let troy give a quick update on melange
22:03:06 <danwent> #topic melange status
22:03:32 <troytoman> we're trying to get one last review on the initial merge prop into nova
22:03:42 <troytoman> i think we are close
22:03:47 <danwent> great
22:03:55 <troytoman> started working on MAC address assignment this week
22:04:03 <troytoman> will write up a blueprint for that tomorrow
22:04:17 <danwent> #info basic melange that works with Quantum Manager is in last stages of nova review
22:04:36 <troytoman> will add nova blueprints for /interfaces as well to tie in Quantum/multi-nic/melange
22:04:56 <danwent> troy: definitely send an email to netstack with that BP
22:05:08 <troytoman> will do
22:05:10 <danwent> will be very help
22:05:11 <danwent> ful
22:05:24 <danwent> also, any BP for packaging melange (either with nova, or by itself?)
22:05:43 <troytoman> yes. need to add that one as well. thx for the reminder
22:06:17 <danwent> #action troy send email to netstack with with BP for "interfaces" API, and for melange packaging
22:06:28 <danwent> Anything else?  Any questions for melange?
22:06:47 <bhall_> one quick one
22:06:59 <bhall_> troytoman: will melange also track dhcp start address?
22:07:12 <RamD> yes. curious to know more about "interfaces" api...will wait for Troys BP
22:07:13 <bhall_> we're still getting that from nova.. but most of the other pieces we get from melange
22:07:36 <carlp> bhall_: The goal is to have Melange be the definitive source for all of that, yes
22:07:37 <troytoman> i think it can do that via policies
22:07:47 <danwent> RamD:  basically this is how to use the nova API to define VM vNICs
22:07:51 <bhall_> ok, I'll have to look at policies
22:07:53 <bhall_> thanks!
22:08:17 <troytoman> you assign a block to a network and add policies that will give you the right starting point
22:08:30 <bhall_> that makes sense
22:08:34 <troytoman> carp is going to work on DHCP calling melange to get the auto-assigned IP
22:08:41 <troytoman> ^carlp that is
22:08:42 <uvirtbot> troytoman: Error: "carlp" is not a valid command.
22:08:48 <bhall_> ok
22:08:49 <carlp> haha
22:08:57 <danwent> I like "carp" better
22:09:00 <carlp> Yep, I'm the DHCP dude for now
22:09:07 <troytoman> i'll get carp to work on it too
22:09:11 <troytoman> more help the better
22:09:17 <danwent> :)
22:09:22 <danwent> Ok, anything else for melange?
22:09:47 <danwent> #info carlp will be working on DHCP service using melange data
22:10:02 <danwent> #topic quantum status (for real this time)
22:10:28 <danwent> carlp, update on jenkins with respect to functional/system test?
22:10:40 <danwent> this is really going to have to be a team effort, but you're the point person :)
22:11:00 <carlp> I have the hardware ready to go, robertn and I should have the networking done as speced by the notes from two weeks ago by the end of the week
22:11:21 <bhall_> #action bhall ask jeblair about a jenkins job for code coverage for quantum
22:11:21 <danwent> cool.  is there a BP tracking this work?
22:11:24 <carlp> I'm also hoping to get some one-on-one with mtaylor this week to get Jenkins setup as well
22:11:34 <carlp> I was going to get that straightened out tonight
22:11:56 <danwent> Ok, great.
22:12:03 <carlp> I know you gave me one, I just need to flush it out
22:12:33 <danwent> #info all milestones for essex are now open.  please start assigning BPs to them https://launchpad.net/quantum/+milestones
22:12:37 <danwent> carlp: great
22:13:03 <danwent> #info carlp is in the process of setting up quantum jenkins infrastructure
22:13:56 <danwent> Ok, next up, topics from the nova-parity discussion we had at the summit.  Goal is to make sure that users can use Quantum to achieve at least the same use cases as they could with traditional nova networking
22:14:08 <danwent> I saw that bhall created some blueprints on this
22:14:18 <danwent> sumit and salvatore as well
22:14:24 <danwent> bhall, want to go first?
22:14:35 <bhall_> yup, they're created but still need more detail
22:14:38 <bhall_> sure
22:15:16 <bhall_> #info parity blueprints linked as dependencies here: https://blueprints.launchpad.net/quantum/+spec/nova-network-parity
22:15:23 <carlp> bhall_: You can assign the dhcp one to me
22:15:31 <bhall_> ok
22:15:43 <zykes-> so basically networking will be removed from nova late ron or ?
22:16:00 <bhall_> we've got a review on gerrit for adding interim dhcp support
22:16:10 <bhall_> the work carl is doing will supercede that, though
22:16:15 <danwent> carlp:  most of the nova parity things can be thought of along two lines:  a short-term solution that likely integrates with nova-network capabilities (e.g., DHCP with dnsmasq) and the better long term approach, which is extracting the functionality to be its own service
22:16:31 <danwent> this will be the case for DHCP, L3, floating ips, etc.
22:16:49 <salv-orlando> #agree
22:17:04 <bhall_> I think Sumit's team was going to take security groups and vpn
22:17:11 <bhall_> but we still need volunteers for the other pieces
22:17:25 <danwent> zykes:  basic networking capabilities will likely remain in nova for ease of use.
22:17:26 <carlp> danwent: understood.  I figured getting a simple service up and running now would be a good short term solution (so it can talk to any supported driver) and then add more features as time goes on
22:17:46 <bhall_> that's pretty much where we are at this point
22:17:54 <danwent> zykes: also, nova today acts not just as compute, but also as an orchtestrator (e.g., creating gateways for tenants automatically)
22:17:57 <carlp> bhall_: I was going to look at VPN as well, but if sumit wants to take lead that's fine with me
22:18:22 <danwent> zykes: long-term that may change, with orchestration being pulled out into another service (e.g., donabe)
22:18:29 <bhall_> carlp: either way is OK with me.. maybe they can take security groups and give you vpn
22:18:32 <SumitNaiksatam> bhall/carlp: we will look at it, but we can sure collaborate
22:18:44 <bhall_> lets talk about it on the mailing list
22:18:50 <danwent> sumit/carlp:  I looked at the vpn stuff, should be quite managable
22:18:50 <carlp> sounds good
22:19:25 <danwent> sumit, I believe your team was going to send out mail about the security groups + vpn stuff?
22:19:59 <salv-orlando> danwent:: do you mean cloudpipe vpn porting or APIs for configuring VPN access?
22:20:18 <danwent> salv:  just cloudpipe porting, thanks for clarifying
22:20:18 <RamD> danwent: yes, we will send soon...also thinking about the overlap between VPN and "Network extensions" that we discussed at boston
22:20:28 <danwent> salv:  short-term
22:20:42 <salv-orlando> danwent: ok
22:21:10 <salv-orlando> sumit, RamD: are you including also AWS-style security groups in your L3 service design?
22:21:12 <danwent> RamD: yeah, I think that will be part of the "long-term" phase of remote connectivity.  would be nice to have a uniform API that works for different types of remote access.
22:21:38 <zykes-> is there any involvement from Vyatta for example for integrating their vm into the netstack ?
22:21:43 <RamD> salv-orlando: yes. atleast thinking is along those lines
22:21:54 <salv-orlando> RamD: ok, thanks
22:21:55 <danwent> zykes:  would be nice, but I haven't seen any openstack interest from them
22:22:06 <danwent> RamD:  aren't security groups more of a per VM VIF thing?
22:22:17 <RamD> salv-orlando: but the priority is ensure current nova model works and supported short term
22:22:19 <salv-orlando> danwent: that's my wau of looking at them
22:22:29 <danwent> RamD:  anyway, we can take this offline and have a broader discussion about what should/should not be in the L3 abstraction
22:22:34 <salv-orlando> wau => way
22:22:45 <danwent> again, defining an L3 API is not in the set of the first things we're tackling for essex
22:23:04 <danwent> we have to get quantum as-is solid first
22:23:05 <RamD> danwent: Yes. Agree we need a discussion on L3 service
22:23:30 <danwent> Ok, so let's try to settle on next steps regarding nova-parity
22:23:47 <RamD> danwent: completely agree on Quantum stability...but if we can acheive some of the nova parity work with immeidate L3 service API then it would be great for long term as well
22:24:11 <danwent> #action: sumit + team is exploring short-term cloudpipe integration
22:24:58 <salv-orlando> #idea circulate list of parity-related blueprints on ML. Volunteers will pick individual blueprints.
22:25:19 <bhall_> salv-orlando: good idea
22:25:30 <edgarmagana> +1 salv
22:25:39 <bhall_> salv-orlando: I'll send mail with the bp links/etc
22:25:53 <salv-orlando> bhall_: thanks
22:25:54 <bhall_> #action bhall cirtualte parity-related bps
22:26:04 <danwent> RamD:  my guess is that defining a canonical tenant-facing L3 API will be a big undertaking that will require signficant effort from lots of different members of the netstack team.
22:26:56 <danwent> RamD: i have a feeling its scope is much beyond simply replacing the basic L3 gateway that is in nova today.
22:27:18 <salv-orlando> danwent: my only concern is that for Quantum we came to the diablo summit with an half-cooked API proposal and finalized the API 3 days before rbp... with L3service, we don't have even a project name yet :)
22:27:46 <RamD> danwent: Agree on the overall L3 Service APIs and we need lots of help. As we are doing the nova parity if we can do those "functionalities" only for now using L3 API "Set" then we can take up the "fuller" service later
22:27:55 <jmeredit> Personally I'd rather see a continuation of the tight, concise building block approach.  Get a minimal feature set working and build from that.
22:28:42 <RamD> salv-orlando:I thought L3 service will inherit Quantum project name itself...atleast that's what I heard in the summit.
22:29:04 <danwent> Salv:  do I understand you correctly in saying that L3 will be significant effort, or are you saying something else?
22:29:25 <salv-orlando> danwent: I'm exactly saying it will be a significant effort.
22:30:26 <RamD> jmeredit: The L3service proposal more like what we have started in the Quantum L2 side....basic bldg blocks and keep expanding...for example start with L3 Subnet + Nat as in the nova parity list
22:30:28 <danwent> RamD:  yes, that is what we talked about.
22:30:29 <salv-orlando> basically, I don't think it would be safe to bet on the L3 service for nova-parity in Essex nevertheless I do hope to see some form of L3 service with tenant facing APIs for the Essex release
22:30:45 <somik> One approach would be to discuss and spend our energy on solidifying the core quantum nova-net parity effort and if there are more cycles left towards E3, we can discuss L3.
22:31:31 <danwent> somik:  I agree.  I think we should focus on getting our core solid, hopefully early in the essex cycle, then we can start to push on L3 so we have a solid proposal in place for the next summit
22:31:44 <RamD> salv-orlando:  if we can have L3 service to meet some of the nova parity work..then as well we can spend energy on it rather than two step process
22:31:55 <danwent> but I agree with Ram that we can start learning and thinking about L3 in the mean time
22:32:22 <danwent> thinking about what the relationship between QuantumManager, and L3 service, and melange might look like
22:32:43 <RamD> I think L3 "constructs" are huge missin block for any openstack used to use Quantum..which I think we all agree.
22:32:51 <somik> RamD: The two stetp process is a risk tradeoff, this way we go slower but we can atleast deliver something solid and usable for the community in the short term
22:33:22 <danwent> I just want to make sure developers are rewarded for focusing on making quantum production quality.  I don't want anyone feeling left out of the L3 discussions because they spent time building functionality tests, working on jenkins, etc.
22:33:45 <danwent> RamD:  definitely agree.  L3 is THE next big part of the puzzle in my mind.
22:34:12 <danwent> I just want to make sure we wrap up the L2 part of the puzzle first, as there are people that actually want to put Quantum in project with L2-only.
22:34:19 <danwent> project -> production
22:34:36 <RamD> danwent: Having the focus on making Quantum prodcution ready is absoulte must and ahving L3 basic construcsts will only help in that direction...I completely agree on complete participation on this
22:34:46 <salv-orlando> I'm a bit puzzled here. On one side I see danwent has a good point, but on the other side we should not stop progress on L3 service if there are people willing to start work on it.
22:35:49 <danwent> salv:  I agree.  I'd rather see everyone pitch in to make things solid, then everyone move on to focus on L3
22:36:10 <danwent> that way no one feels left out by working on the "boring" but necessary stuff, while others do the "fun" stuff like L3 :)
22:36:12 <RamD> the wiki posting from Sumit today shows one such case in which the L3 service how it can potentially help on the nova-parity side as well ..
22:36:50 <somik> salv-orlando: if we start on L3 before solidying L2, we are compromising resources that could get us to stable L2 faster, and gotten Quantum into production.
22:36:54 <danwent> RamD:  agreed… L3 service would be a (large) super-set of what is needed by nova
22:37:10 <salv-orlando> somik: agree
22:37:20 <danwent> that in fact is my concern, as I think it will be a much larger effort than just trying to get the equivalent of nova.
22:37:29 <RamD> danwent: I think the proposal is already we all agree on fixing the L3 using nova parity work stream...the point is if we can achieve that and provide enough hooks to future by starting of with basic L3 service today I thing its great
22:37:39 <salv-orlando> danwent: I estimate at least the same effort we put into Quantum
22:37:56 <danwent> salv:  can you clarify?  I think I lost context :)
22:38:04 <danwent> ah, amount of work?
22:38:06 <RamD> That way all the developers trying/signing up for the parity work example NAT can readily particiapte on the basic L3 service as well
22:38:08 <salv-orlando> yeah
22:38:17 <salv-orlando> I don't want to be boring, but we are almost 40 mins into the meeting and nowhere near the middle of the agenda :)
22:38:45 <RamD> shall I propose to set up a webex for L3 discussions?
22:38:52 <danwent> RamD:  actually, parity can be achieved quite simply by leveraging all of the L3 work already done by the nova-network service and just plugging it into a L2 quantum network.  Brad sent an example of this out.
22:39:19 <danwent> salv:  agreed, but I think this is a pretty key point for the community :)
22:39:28 <salv-orlando> danwent: sure.
22:39:37 <danwent> salv: apologies that this has to happy late at night for you :)
22:40:28 <bhall_> also, now that dhcp is into quantummanager I think we have enough hooks to make leveraging the other features easier
22:40:35 <RamD> danwent: I see for DHCP..Apologies if there is something on subnet and other things then atleast its worth look at the flow model
22:41:02 <danwent> yeah, a lot of the work will be quantummanager work that will just apply across any plugin that implements vif-plugging on the nova network node.
22:41:10 <RamD> How about for 1 hour conf call tomorrow on nova parity and L3 discussions?
22:41:47 <danwent> RamD: I think it would be good to give folks a better understanding of the short-term vs. long-term plan with respect to all nova-network capabilties.
22:42:23 <danwent> Perhaps brad could provide more info on how his proposal for short-term parity works… I think there is still a lot of confusion around this.
22:43:01 <bhall_> here or on the mailing list?  maybe clearer if I type it up and send mail
22:43:08 <danwent> if things are unclear after brad sends an email, we can try a webex or a face-to-face meeting + webex
22:43:13 <carlp> bhall_: I think that's a great idea
22:43:14 <bhall_> k
22:43:18 <cdub> would be nice to see the mapping of current nova L3 to quantum in the least
22:43:20 <salv-orlando> #agree
22:43:23 <danwent> (sorry, to remote folks, but whiteboard is probably a huge win there)
22:43:37 <danwent> though I guess webex has virtual whiteboard, right?
22:43:41 <RamD> danwent: yes my confusion is also there...nothing like we jump on to a conf call or hit whiteboard, probably this week itself.
22:44:05 <RamD> danwent: yes webex has whiteboard :-)
22:44:14 <danwent> #action brad sent detailed email on short-term nova-network integration
22:44:15 <bhall_> #action bhall send mail regarding short-term parity
22:44:17 <danwent> :)
22:44:25 <danwent> now you have to do it twice brad
22:44:40 <danwent> if needed, we can follow-up with a webex
22:44:44 <bhall_> sounds good
22:44:53 <danwent> is everyone ok with that plan?
22:45:01 <carlp> yes
22:45:05 <salv-orlando> yes
22:45:08 <edgarmagana> sounds good!
22:45:10 <jmeredit> yes
22:45:12 <zykes-> how can i subscribe to the team mails ?
22:45:31 <danwent> netstack list
22:45:37 <somik> you can join the netstack team to and choose subscribe to mailing list
22:45:41 <zykes-> and that is where ? :)
22:45:49 <danwent> looking it up....
22:45:51 <somik> sykes: on launchpad
22:45:52 <zykes-> quantum core developers or ?
22:46:02 <danwent> https://launchpad.net/~netstack
22:46:12 <salv-orlando> or https://launchpad.net/~<your-name-here>/+editemails
22:46:38 <bhall_> wow, 129 people on the list now.. guess its growing :)
22:46:50 <danwent> Ok, in deference to salv, let's keep moving
22:46:59 <danwent> Salv, any updates you need to provide on API work?
22:47:07 <salv-orlando> Just a progress update
22:47:28 <salv-orlando> I'm in the middle of a little bit of wsgi framework refactoring
22:48:03 <salv-orlando> for splitting route paths for v1.0 and v1.1, even though the only thing that will change is the 'operational status' in responses
22:48:34 <danwent> ok, nice.  that will payoff in the future as well i'm sure
22:48:39 <zykes-> hmm
22:48:39 <salv-orlando> also, I'm removing unused bits of code (see code coverage emails), and improving serialization/deserialization
22:48:58 <salv-orlando> reusing code from nova
22:49:10 <zykes-> just as a general question there, why isn't there an overall "version handling api" middleware that goes across all projects ?
22:49:22 <salv-orlando> Said that, I hope we will be able to can all this code before Essex, and use openstack-commons
22:49:37 <salv-orlando> zykes-: the answer would be openstack-commons
22:49:45 <danwent> salv: do we have a detailed spec yet on exactly how operation status will work?  i.e., is the field a string, a boolean "up" vs. "down", etc?
22:50:22 <salv-orlando> danwent: working on that. Will publish wiki page by end of the week. My opinion is to go for an enum
22:50:43 <danwent> ok, great.  looking forward to reading it.
22:50:49 <salv-orlando> #action Salvatore to publish detailed spec for operational status by end of the week
22:51:10 <danwent> thx, anything else on API salv?
22:51:24 <salv-orlando> I have targeted blueprints and bugs for API work to Essex milestones. that's all.
22:51:37 <danwent> great, thx.
22:51:54 <danwent> somik, mark, are you two around to talk about the user flow + dashboard work?
22:52:32 <somik> danwent: I have high level discussions from summit summarized
22:52:34 <danwent> I don't see mark in the room…  anyone from the cisco dashboard team here?
22:52:48 <somik> I beleive Arvind was working on some ideas as well
22:53:03 <danwent> ok, would be great to see blueprints sent to the list, even if they are rough.
22:53:10 <somik> although unsure if Arvind is back in the country yet.
22:53:31 <somik> After I document all summit discussions, I'll send it out everybody.
22:53:37 <danwent> ok, sounds good.
22:53:48 <danwent> #action somik send out document describing summit user flow
22:54:01 <danwent> Brad, what is the status of the issues with the data extensions?
22:54:20 <bhall_> danwent: create port/net is proposed for merge and reviewed
22:54:25 <bhall_> (and approved I think)
22:54:33 <danwent> you had mentioned a need to change the plugin python API though?
22:54:34 <bhall_> update port/net .. I just sent that out today
22:55:02 <bhall_> ah, yeah.. well, I sent mail to the list about this but I want to get rid of rename_net and change_port_state
22:55:07 <bhall_> and make htem just update_network and update_port
22:55:18 <bhall_> which changes the cli, plugins, everything
22:55:46 <danwent> Ok, probably warrants more discussion on list, but I wanted to make sure it was at least raised in the meeting.
22:55:54 <bhall_> (I guess we don't have to get rid of rename_net/set_port_state .. they could just make to update_network, update_port)
22:56:02 <bhall_> yeah, I'm hoping for some ML feedback on that one
22:56:12 <danwent> Ok, thx.
22:56:48 <danwent> #action somik will check with salvatore about re-enabling keystone middleware
22:57:01 <danwent> Ok, aything else on quantum?
22:57:19 <bhall_> oh, thanks for the reviews to everyone who reviewed the stuf I sent out the other day
22:57:27 <danwent> #topic open discussion
22:57:39 <danwent> apologies to salvatore for keeping him up so late....
22:57:49 <danwent> anything else?
22:58:18 <danwent> Ok, thanks folks
22:58:22 <danwent> #endmeeting