21:01:28 <danwent> #startmeeting
21:01:29 <openstack> Meeting started Mon Jun 25 21:01:28 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:48 <danwent> ok, looks like we have a good crowd to get started.
21:01:56 <danwent> #link agenda: http://wiki.openstack.org/Network/Meetings
21:01:59 <gongys> helo
21:02:10 <danwent> gongys: hi!
21:02:17 <danwent> #topic folsom-2 status
21:02:33 <danwent> #link https://launchpad.net/quantum/+milestone/folsom-2
21:02:43 <ncode> o/
21:02:52 <danwent> so, we've had a lot of great effort from folks over the past week on key F-2 issues
21:02:54 <rkukura> o/
21:03:03 <s0mik> o/
21:03:26 <danwent> its still going to be a tight squeeze, but I think we at least stand a good chance at getting a first cut at all of the key v2 functionality in by F-2, which would be fantastic
21:04:05 <danwent> #info all F-2 blueprints should have at least an initial review pushed by tomorrow (even if its someone incomplete)
21:04:29 <danwent> #info if you're not ready for pushing a review by tuesday, please ping me to keep me up to date on the status of your blueprint
21:04:39 <danwent> as we'll have to monitor such work items very closely
21:05:19 <danwent> We will have a F-2 branch point a week from tomorrow, at which point all non-bug fixes must be merged
21:05:43 <danwent> Ok, want to run down key F-2 items and get a status update.
21:05:46 <danwent> garyk: https://review.openstack.org/#/c/8794/
21:05:56 <danwent> seems like we're close on the IP allocation stuff?
21:06:05 <garyk> yup.
21:06:21 <danwent> garyk: great.  I will rereview tonight and hopefully we can get it in by tomorrow.
21:06:25 <garyk> all done - just waiting for review.
21:06:32 <danwent> gongys: https://review.openstack.org/#/c/8916/
21:06:34 <salv-orlando> I'm reviewing the code as well. Will complete either before sleep or tomorrow morning
21:06:47 <danwent> gongys: thanks so much for taking a crack at this.  Will be reviewing this right after the meeting.
21:07:18 <danwent> gongys: I had one question on this:  is this new code covered by existing unit tests, or do we need to create new ones?
21:07:21 <gongys> Yes. it is not a perfect work, but we can go further after your reviews.
21:07:38 <gongys> I had to create more unit tests.
21:07:46 <gongys> no tests for now.
21:07:53 <gongys> new ones.
21:08:01 <danwent> gongys: yes, makes sense.
21:08:07 <danwent> looks like a great start though
21:08:29 <PotHix> agree
21:08:50 <danwent> markmcclain: update on DHCP?  Sounds like you've been making progress?
21:09:14 <markmcclain> I'm on track to push code that covers most of items from the blueprint for F2 into review tomorrow morning (or possibly this evening).
21:09:39 <markmcclain> The lone exception is ISC support, but I think that Pothix can help with it
21:09:56 <danwent> markmcclain: is ISC support being targeted for F-2, or later?
21:10:16 <gongys> markmcclain: what is ISC?
21:10:16 <danwent> Either way, if we're splitting it out, it probably makes sense to create a separate bug or blueprint to track it, and assign it to PotHix
21:10:30 <markmcclain> nice to have to F2, but if it slides to F3 I don't see it as a problem
21:10:37 <ncode> gongys, one implementation of dhcp server
21:10:45 <PotHix> markmcclain: I agree
21:10:57 <danwent> PotHix: can you create a new issue to track this separate work?
21:11:06 <PotHix> danwent: sure
21:11:24 <danwent> #todo PotHix create separeate launchpad bp/bug to track ISC dhcp work
21:11:35 <gongys> So we don't use dnsmasq?
21:11:45 <markmcclain> for F2 we will use dnsmasq
21:12:06 <PotHix> gongys: yes, but we'll support isc dhcp as well
21:12:32 <PotHix> gongys: we have some work done for it
21:12:39 <danwent> arosen: not fair to ask you for an update on https://blueprints.launchpad.net/quantum/+spec/ovs-api-v2-support, since I just assigned it to you a few minutes ago.  But a note that you should coordinate with rkukura, who will be landing some changes in the OVS plugin as well.
21:13:01 <arosen> danwent:  Sounds good will do
21:13:11 <danwent> rkukura: speaking of, how are thinkings going with provider networks?
21:13:31 <danwent> when do you expect to propose an initial review (even if some parts are still TODO?)
21:13:44 <rkukura> Not much progress last week, but should have initial patch tomorrow
21:13:45 <danwent> thinkings -> things
21:13:53 <danwent> you can tell I didn't sleep last night… damn jet lag
21:14:42 <danwent> rkukura: ok, great.  definitely best to get something up early, as this helps identify any major concerns, and helps spread the reviewing load (rather than slamming people with review days at the very end of the week)
21:15:10 <danwent> rkukura: I believe we decided that the OVS plugin v2 work would go on top of your change, is that correct?
21:15:37 <rkukura> As long as I get it in tomorrow
21:15:53 <danwent> :)
21:16:07 <rkukura> I could hold off on the OVS side if that made more sense
21:16:31 <danwent> sounds like a plan.  if you aren't able to propose something by tomorrow, please sync with arosen, so you two can figure out how best to procede.
21:16:38 <rkukura> OK
21:17:14 <danwent> I don't think arvind is around to comment about Horizon + Quantum integration.  I sent him an email asking for an update though.  Anyone know status there?
21:17:15 <rkukura> Is V2 for linuxbridge planned?
21:17:26 <danwent> rkukura: most plugins will do v2 in F-3
21:17:31 <rkukura> OK
21:17:42 <danwent> we should file an issue for it and assign it to F-3, if there isn't one already though.
21:18:04 <danwent> debo-os: here?
21:18:19 <danwent> is Hua here?
21:18:29 <danwent> (forgot irc handle for Hua)
21:19:26 <debo-os> I am here
21:19:26 <danwent> Well, on the topic of devstack gating, it looks like our devstack reviews to fix gating with Quantum aren't getting any love: https://review.openstack.org/#/c/8642/
21:19:46 <debo-os> I renewed my patch and am pining Dean immediately after this
21:19:50 <debo-os> pinging
21:19:52 <danwent> debo-os: and I noticed that your devstack review expired, as no devstack core devs reviewed it.
21:19:58 <danwent> debo-os: great, thanks.
21:20:28 <danwent> This has made me wonder if it would make sense for Quantum to have one of its team members become a devstack core devs specializing in Quantum-related devstack reviews.
21:20:34 <debo-os> +1
21:20:43 <danwent> I may take on that role, but if anyone else is interested as well, let me know
21:20:48 <debo-os> we should ... this isn't the 1st time. Folks are busy there
21:20:51 <danwent> we spend a lot of time waiting for devstack reviews.
21:21:01 <danwent> yeah, definitely a regular occurence
21:21:12 <garyk> +1
21:21:29 <danwent> #todo danwent contact dtroyer about quantum team member(s) becoming devstack core reviewers
21:21:35 <mestery> +1 on having a Quantum dev as a devstack core
21:21:35 <arosen> I agree too +1
21:21:58 <danwent> garyk: sorry, looks like I missing your last config review in the agenda
21:22:22 <danwent> https://review.openstack.org/#/c/8800/
21:22:34 <danwent> garyk: is there one more config patch after this, or is this the last one?
21:22:55 <garyk> this is the last one. after that we need to dicuss the plagin ini files
21:23:12 <danwent> garyk: but that plugin.ini stuff would be F3?
21:23:21 <garyk> correct.
21:23:27 <danwent> k, makes sense.
21:23:52 <danwent> We covered a lot of ground here… anything else we think we need to discuss for F-2?
21:24:24 <ijw> Sorry, I missed the devstack bit, but can I suggest also https://review.openstack.org/#/c/8726/ - a bug, not a feature, but it stops devstack/OVS installs working in a very quiet way and won't help anyone who's testing.
21:24:27 <danwent> Obviously, if you're not someone finishing up a high priority feature, please make sure you are devoting plenty of cycles to reviews, as we'll have a lot of new code coming through in the next few days
21:25:06 <danwent> ijw: thanks for highlighting that.
21:25:27 <danwent> another example of why we need a quantum core reviewer on devstack :)
21:25:45 <danwent> #topic community topics
21:26:13 <danwent> So review days, any comments or concerns?
21:26:38 <danwent> the overall number of reviews seems to be a bit lower as a result, so I'm optimistic so far, though the real test will be keeping it up over time.
21:27:29 <danwent> #info location of next design summit has been chosen: http://www.openstack.org/blog/2012/06/openstack-summit-coming-october-15th-19th-to-san-diego-ca/
21:27:32 <salv-orlando> it has also to be said that we are dealing with larger patches, so a review can easily take more than 2 hours
21:27:53 <danwent> salv-orlando: indeed :)
21:28:23 <garyk> when will it be in europe?
21:28:37 <danwent> garyk: ping ttx
21:28:42 <salv-orlando> One day I wish...
21:28:44 <ijw> garyk: given the weather at the moment you *really* don't want it in Europe ;)
21:28:55 <salv-orlando> well it depends
21:28:59 <danwent> garyk: will you not be able to attend in san diego, or is it just that you'll be insanely jet-lagged?
21:29:12 <garyk> danwent: :)
21:29:19 <danwent> ijw: haha, yeah, europe is probably better for the spring summit
21:29:29 <danwent> I know they've been promising it for a while, so hopefully next spring
21:29:48 <danwent> #topic open discussion
21:29:53 <danwent> anything?
21:30:18 <gongys> how do we do ovs plugin v2?
21:30:37 <gongys> It will have new tables or just based on the current models?
21:30:41 <danwent> gongys: should be a pretty simple sub-class of the ovs_db_base_v2
21:30:58 <arosen> gongys: https://blueprints.launchpad.net/quantum/+spec/ovs-api-v2-support
21:31:07 <danwent> but on network creation it will also store a vlan/tunnel id
21:31:20 <danwent> and there will be some minor changes to the agent, due to the fact that we no longer use attachment-id
21:31:42 <gongys> we had better not create a sub package to contain new tables, which is the 1.0 way.
21:31:50 <danwent> but largely I think the agent will stay mostly the same, while the main plugin code will be simplified by the use of the db_plugin_base class.
21:32:02 <danwent> gongys: can you elaborate?
21:32:37 <danwent> are you talking about where the model class is placed in the codebase?
21:32:41 <gongys> Do we need db upgrade feature introduced in?
21:33:02 <gongys> Yes, the model class.
21:33:24 <gongys> all other projects support db upgrade feature.
21:33:44 <danwent> gongys: glad you mentioned this.  We'll want that capability moving forward, though I don't think we'll need to worry about it with respect to v1 plugins to v2 plugins, but that's up to the plugin in the end.
21:34:00 <danwent> gongys: want to create a launchpad issue for F-3 to look at this?
21:34:04 <salv-orlando> +1. It's part of the plugin capabilities
21:34:46 <danwent> there may well be code that can be shared across different plugins.
21:34:47 <gongys> ok, but Do we have  upgrade feature in any plugin implementation?
21:34:58 <danwent> gongys: not yet
21:35:16 <danwent> well, at least not in the OVS or linux bridge plugins, which I assume is what you're talking about.
21:35:31 <mestery> I think upgrade will become important post-Folsom for sure
21:36:04 <gongys> And about API versions,
21:36:29 <danwent> #todo #danwent create unassigned BP for exploring infrastructure required for sqlalchemy-based upgrades
21:36:30 <gongys> are we support one quantum server supporting two versions at the same time?
21:37:17 <salv-orlando> gongys. This another good point. I reckon we can support both for Folsom
21:37:43 <danwent> salv-orlando: this is a discussion I was planning on having in F-3, once we have the base v2 plugin stuff together
21:37:46 <salv-orlando> then maybe deprecate 1.x in "G" and remove it for "H". This could be a possilbe path IMHO.
21:37:57 <danwent> i'm actually hoping we can be pretty agressive about moving away from the v1.x stuff
21:38:22 <salv-orlando> Aggressive such as removing it by Folsom?
21:38:24 <danwent> but we'll have to discuss the trade-offs (I for once just really like deleting code :P)
21:38:33 <ncode> One think that I'd like to know, are we planning to move the agents queues to something like rabbit or we will keep using queues on mysql
21:38:51 <danwent> ncode: let's hold discussion on that for a sec
21:38:53 <garyk> ncode: yes. i have a version with linux bridge for this - f-3
21:39:04 <ncode> oks :D
21:39:10 <danwent> ncode: ah, misundestood your question
21:39:42 <danwent> salv-orlando: i'm concerned about confusion around documenting quantum, supporting two ways of nova working with quantum, etc.
21:39:46 <salv-orlando> I recall a pair of devs were trying to improve agent communication on OVS plugin as well (maru?)
21:40:14 <danwent> I think there's a fair amount of overhead to keeping v1.x around, but I think we can have a more structured discussion of pros and cons in F-3
21:40:18 <garyk> https://blueprints.launchpad.net/quantum/+spec/scalable-agent-comms
21:40:26 <salv-orlando> danwent: agree. I'm all for doing less work.
21:40:50 <danwent> salv-orlando: cool.  let's table a deeper discussion until early F-3
21:41:16 <danwent> #todo #danwent create BP bug to discussion possible removal of V1 code in folsom.  Still up for debate.
21:41:28 <danwent> ok, ncode was your question addressed?
21:41:46 <ncode> danwent, yeap
21:41:52 <salv-orlando> On a second though, since up to Essex Quantum has only been used in "admin" mode its API never went really public, is that right?
21:41:53 <ncode> thanks
21:42:18 <danwent> salv-orlando: yes, that is part of why I think we may be able to ditch v1
21:42:32 <danwent> since you HAD to use it with quantum-manager in nova as the only real client
21:42:46 <ijw> Perhaps the best thing to do is ask around at the summit, see if you can get a feel for who's been using it in production if anyone.
21:42:46 <ncode> garyk, awesome :D
21:42:49 <danwent> but we'll see, perhaps people used it in some other way.
21:43:00 <salv-orlando> ijw: that would be too late :)
21:43:00 <PotHix> scalable-agent-comms FTW
21:43:49 <ncode> garyk, most of our internal agents are following this idea
21:43:50 <danwent> ijw: there definitely are people using it, but the question is whether they have written external code against the APIs, or whether they can simply upgrade Nova + Quantum to folsom and be fine (my hypothesis), since the new version of Nova would have the new quantum client.
21:44:03 <garyk> ncode: great
21:44:05 <salv-orlando> IMHO bottom line is that if we manage to ensure users can easily transition from Quantum manager to direct calls to Quantum API, we can probably get rid of API v1 immediately
21:44:11 <danwent> salv-orlando: I agree.  I think this would be an email to the main list, sometime in F3
21:44:13 <ncode> if you need I'd glad to help
21:44:20 <PotHix> garyk: we'll have some code on this feature for isc-dhcp and generic-firewall
21:44:28 <PotHix> me too
21:44:55 <danwent> ok, sounds like that's about it
21:44:59 <garyk> PotHix: this requires the rpc code from openstack common
21:45:19 <danwent> I just wanted to say that I think we're making great progress with Quantum in the past month and am really excited about all of the new contributors.
21:45:47 <danwent> let's keep focused on finishing up blueprints (initial review by tuesday, tomorrow), and if you don't have a big blueprint you're working on, please dive in and help with reviews
21:46:00 <danwent> see you all on gerrit :)
21:46:06 <danwent> #endmeeting