21:01:05 <danwent> #startmeeting
21:01:06 <openstack> Meeting started Mon Jun 18 21:01:05 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:01:07 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:01:17 <danwent> #link agenda: http://wiki.openstack.org/Network/Meetings
21:01:44 <danwent> we have a lot of different items to cover, so hopefully we can keep things moving forward and move any long discussions to the list
21:01:50 <gongys> hello
21:01:56 <danwent> gongys: hey
21:01:58 <ExxonValdeez> hi! i am an intern at nicira and started today, just wanted to introduce myself before we get going. My name is josh
21:02:17 <danwent> ExxonValdeez: hi josh, nice nick :)
21:02:24 <ExxonValdeez> haha, thanks :)
21:02:32 <gongys> josh, welcome
21:02:52 <SumitNaiksatam> hi all!
21:02:54 <danwent> #topic: Folsom-2 milestone
21:03:31 <danwent> #info we have one week until until folsom features should be proposed for review, 2 weeks until the branch for release is created
21:03:59 <danwent> we'll spend a big chunk of the meeting today reviewing status of items priority high and above.
21:04:07 <garyk> hi
21:04:13 <danwent> First off, two reviews central to F-2 that I'd like to highlight
21:04:27 <danwent> agenda for those joining late: http://wiki.openstack.org/Network/Meetings
21:04:38 <ncode> hi
21:04:56 <danwent> #help please help revew the clientlib and CLI code changes: https://review.openstack.org/#/c/7596/
21:05:17 <danwent> gongys: is only outstanding issue the interactive mode issues garyk is seeing, or are there others?
21:05:20 <PotHix> hi
21:05:47 <danwent> I'd really like to at least get the client lib merged in, so other features can use it asap
21:05:59 <gongys> garyk, is there still interactive issue?
21:06:11 <gongys> I think it should be fixed.
21:06:29 <gongys> Please also see the doc at https://docs.google.com/document/d/1e_4UtnhFfgtnsB8EVB31BZKldaVzl_BlsGnGBrKmcDk/edit
21:06:47 <garyk> i posted on gerrit - not sure fi you saw it
21:07:05 <danwent> ok, unfortunately, looks like gongys is the only dev signed up for review day tomorrow.
21:07:08 <garyk> there are just a few odd error messages
21:07:22 <garyk> i am able to help out
21:08:41 <danwent> garyk and I both have already been reviewing the code, so that's two core devs, but we could definitely use more reviews as well.  I'd really like to see this go in tomorrow.
21:09:02 <danwent> (or later today… see, this whole european timezone thing is getting me :P)
21:09:14 <danwent> gongys: ok, so no major blockers here?
21:09:35 <danwent> if so, pending any major issues, let's get this branch in, and file any minor issues as additional bugs.
21:09:37 <gongys> I will online to help fix the issues during review
21:09:55 <rkukura> I'll try to take a look. I'm hoping it will support the provider extension without too much work.
21:10:14 <danwent> #help other major review that needs attention is common config: https://review.openstack.org/#/c/8650/
21:10:16 <gongys> rkukura, you can see the doc
21:10:58 <danwent> its been threw many many rounds of reviews.  garyk, any known blocker issues we need to clear up?  you mentioned the issue of the plugins.ini file in email?
21:10:59 <garyk> gongys: would it be possible to move the doc to the wiki?
21:11:04 <rkukura> gongys: will do
21:11:54 <danwent> garyk ?
21:11:56 <garyk> danwent: as i see it there are no blocking issues - would be nice if we can have concensus to merge conf files
21:12:25 <danwent> are you talking just about getting rid of plugin.ini, or also about getting rid of plugin-specific config files?
21:12:38 <danwent> I think there's consensus on the former, less sure about the latter.
21:13:03 <garyk> the current patch set merges the plugin.ini into quantum.conf. i am talking about the nest stage => moving the plugin configuration files into quantum.conf
21:13:08 <danwent> I personally like the latter as well, just not sure its been discuss as widely
21:13:14 <SumitNaiksatam> yeah, I am not sure about merging all plugin-specific conf files either
21:13:36 <danwent> SumitNaiksatam: yes, the ucs plugin was my main concern, as I know you have multiple config files
21:13:43 <SumitNaiksatam> yeah
21:13:51 <danwent> others plugins have one, and probably would have less issue with merge.
21:14:13 <SumitNaiksatam> whats the motivation for proposing to merge plugin-specific conf files?
21:14:41 <garyk> in order to use the RPC code we need common config global data structure.
21:14:44 <danwent> Ok, let's see if we can quickly resolve this, otherwise, let's move it to ML.
21:15:00 <danwent> garyk: this issue is not a blocker for the current patch-set correct?
21:15:26 <garyk> can i prodpose that we push the patch so othgers can start to use the global conf. i can start to work on the paste config and we can discuss the future developmenst on ML
21:15:54 <garyk> current patch set is ok - little issue with plugin paths which can be fixed at a later stage (in my opinion)
21:15:56 <danwent> garyk: you mean push the current patch, which does touch plugin config?
21:16:14 <garyk> sorry. it has been a long day.
21:16:18 <danwent> garyk: assume plugin path issue does not cause breakage?
21:16:43 <garyk> the current pacth is ok and all plugin unit tests pass (except cisco - but this s another issue)
21:16:53 <danwent> #info: devstack review associated with common config change: https://review.openstack.org/#/c/8176/
21:17:34 <danwent> garyk: not just unit tests, but devstack as well, i assume? What changes about the plugin paths?
21:17:40 <garyk> i need to make a minor change in the devstack - to take care of the merged plugin.ini - i'll update it tomorrow
21:18:01 <danwent> ok.  please make sure the devstack folks don't approve that change until the corresponding change is in quantum.
21:18:10 <danwent> we don't yet have quantum gating, so its not guaranteed.
21:18:19 <danwent> one way would be to -1 your own patch until its ready to go in.
21:18:51 <danwent> Ok, now to review the High priority and above issues for F-2
21:19:12 <garyk> ok
21:19:22 <danwent> I tried to order them according to how limited our F-2 milestone will be if they aren't implemented, but its just a rough estimate.
21:19:32 <danwent> IP allocation in db_plugin_base: https://bugs.launchpad.net/bugs/1008029
21:19:33 <uvirtbot> Launchpad bug 1008029 in quantum "implement mac & IP allocate in v2 db plugin base" [High,In progress]
21:20:00 <danwent> garyk: this is coupled with a bug you're working on, but I wasn't sure if you were biting off the ip allocation part as well.  can you comment?
21:20:14 <danwent> If not, we should have someone else grab this asap.
21:20:28 <garyk> 1008029 - mac code is pending review. need to start ip allocation unless someelse want to take it
21:20:52 <danwent> (for everyone else, we've brainstormed a design, but no code has been written)
21:21:00 <gongys> Do we have api in quantumv v2.0 to allocate ip?
21:21:15 <danwent> gongys: yes, it occurs as part of port creation.
21:21:32 <edgarmagana> sorry.. I'm late!!
21:21:41 <danwent> gongys: check out: http://wiki.openstack.org/QuantumV2APIIntro
21:21:41 <gongys> but we have no independent api method for it, right?
21:21:53 <danwent> gongys: correct.
21:22:06 <danwent> edgarmagana: ten pushups for being late!
21:22:52 <danwent> ok garyk, I'll assume this is on your plate, unless someone else steps up for it.  thanks for taking this.
21:23:07 <danwent> if you get buried and find you're not getting around to it, please re-raise on ML
21:23:09 <garyk> danent: cool.
21:23:17 <danwent> you have a lot on your plate already
21:23:30 <danwent> second issue: nova-quantum integration: https://blueprints.launchpad.net/quantum/+spec/improved-nova-quantum-integration
21:23:45 <garyk> -1 + -1 + -1 + ...... + -1 == +2
21:24:15 <danwent> I talked to tr3buchet about this.  He has a lot of code written, but its probably still a ways from being mergable into nova, plus needs a refresh for v2 API (using the v2 clientlib)
21:24:30 <danwent> I'm going to jump in and help try to get something into nova for Folsome-2
21:24:44 <danwent> if anyone else wants to help, that would be awesome, let me know.
21:24:58 <gongys> Don't we wait for the melange moved into quantumv2?
21:25:27 <danwent> gongys: melange is moved into quantumv2 (or at least the core parts of melange)
21:25:59 <danwent> the main difference between quantum v1 and v2 are subnets + ip-related info, which is what melange tracked.
21:26:22 <gongys> wow, I don't know yet.  which change? I cannot see the melange code in quantum project.
21:26:42 <danwent> for F-2 we will also need at least one v2 aware plugin.  Me, or someone from nicira will be working on that: https://blueprints.launchpad.net/quantum/+spec/ovs-api-v2-support
21:27:00 <danwent> much of the work here should apply to the linux br plugin as well, since they both will use db_plugin_base_v2.py
21:27:44 <danwent> gongys: we didn' pull in melange code wholesale, we just created datamodels to store the relevant info (e.g., subnets) and extended existing data models (e.g., ports)
21:28:29 <danwent> if anyone wants to help out on open source plugin implemenations, please speak up :)
21:28:49 <danwent> Another big item is DHCP: https://blueprints.launchpad.net/quantum/+spec/quantum-dhcp
21:28:59 <gongys> So we need ip and mac allocation features like melange implemented, these are on gary's plate?
21:29:01 <danwent> markmcclain: saw you updated the bp, any comments to add?
21:29:28 <danwent> gongys: yes, garyk already did mac allocation.
21:30:07 <danwent> for F-2 we will target at least basic IP allocation.  But perhaps not full polciies with excluded_ranges (up to garyk as to whether he wants to try and do that in F-2, but it doesn't seem essential)
21:30:33 <danwent> gongys: make sense?
21:30:48 <markmcclain> nothng real big to add other than a ?
21:31:02 <danwent> markmcclain: go for it.
21:31:05 <gongys> ok, I can have the nova-quamtum integration if you have no time for it.
21:31:33 <markmcclain> current nova binds DHCP to the gateway interface… do we want to keep that model for F2 or create an interface specifically for DHCP?
21:31:48 <danwent> gongys: would be great if you could help on that.  I'll connect you with trey on this.  He has a branch on his public github that is a good starting point.
21:32:09 <gongys> ok
21:32:14 <danwent> markmcclain: that's a good question.
21:32:33 <danwent> I think its important to be able to have a gateway that is implemented separately
21:32:43 <PotHix> danwent: I agree
21:32:46 <danwent> so I think having it be another IP makes sense.
21:33:32 <PotHix> We need it to have generic implementations IMHO
21:33:39 <danwent> markmcclain:  you have to have to add a dnsmasq option to explicitly set the gateway IP when it is different from the dnsmasq ip, but its quite simple.
21:33:56 <markmcclain> separate interfaces is what I've assumed from the begining
21:34:00 <markmcclain> just wanted to check
21:34:04 <danwent> ok, great.
21:34:24 <danwent> BP write-up looks ambitious for F-2.  Hope you have a lot of caffeine handy :)
21:34:29 <PotHix> cool!
21:34:43 <danwent> anything else on DHCP?
21:34:55 <danwent> Ok, next up: https://blueprints.launchpad.net/quantum/+spec/provider-networks
21:35:02 <danwent> rkukura: sounds like you're comfortable with progress?
21:35:23 <rkukura> Should have patch with provider VLANs for linuxbridge and openvswitch in next couple days
21:35:43 <danwent> do you plan on getting this in on the v1 version of plugin I assume?  then v2 plugin update will be based on that work?
21:35:51 <rkukura> yes
21:35:57 <PotHix> markmcclain: are you working on the core code already? We can talk about it later.
21:36:14 <rkukura> the 2nd phase will add multiple interfaces and flat networks next week
21:36:16 <danwent> rkukura: good, makes sense
21:36:49 <markmcclain> PotHix: yes got some toy stuff, but I'll chat with out later abot it
21:36:50 <danwent> rkukura: ok, would be great to get phase 1 up for initial review soon, even if its just a RFC.
21:37:02 <rkukura> I'll do my best
21:37:23 <danwent> want to make sure we keep our review pipeline full, rather than having a lull, then everything at the end, if possible :)
21:37:33 <danwent> ok, anything else on provider networks
21:37:57 <danwent> next issue: getting devstack gating running with quantum enabled: https://blueprints.launchpad.net/quantum/+spec/quantum-gate
21:37:59 <rkukura> haven't sent email about xml issues with extensions yet, but will do that tomorrow
21:38:25 <danwent> zhhuabj did some great work exploring these issues
21:38:39 <gongys> review: https://review.openstack.org/#/c/8642/
21:39:18 <gongys> It will help quantum.sh to work and help q-srv enable.
21:39:21 <danwent> gongys: thanks.  I believe there's also another issue that needs to be fixed regarding the floating IPs.  devstack seems to assume that floating IPs will use interface br100, which is not the case with Quantum.
21:39:40 <danwent> instead, we probably want to use the primary network interface (e.g., eth0).
21:39:58 <danwent> but I think we need to explore this in more detail, its been a while since I've looked at it.
21:40:28 <danwent> debo isn't around, but I think he already merged a fix that handled the issues with quantum.sh
21:40:48 <zhhuabj> hi, I have used the eth0 to instead br100 in stack.sh
21:41:16 <danwent> zhhuabj: ah, that's in the same patchset?
21:41:22 <danwent> great, didn't realize that.
21:41:24 <zhhuabj> yes
21:41:36 <danwent> that's great news, can't wait to have these working
21:41:51 <danwent> #help please review devstack fixes: https://review.openstack.org/#/c/8642/
21:42:11 <zhhuabj> this can fix all float-ips related issues, like euca, float-ips
21:42:23 <danwent> zhhuabj: cool, so you were able to get a clean run?
21:42:30 <gongys> after this change get in, we have to push https://review.openstack.org/#/c/8443/
21:42:52 <gongys> hua, please update these two changes.
21:43:00 <danwent> gongys: yup, mtaylor and jeblair will help with that.
21:43:11 <mtaylor> what did I do?
21:43:32 <danwent> mtaylor: hehe, zhhuabj has a devstack review to get quantum passing the devstack gate
21:43:39 <zhhuabj> gonys:ok
21:43:41 <danwent> https://review.openstack.org/#/c/8642/
21:43:49 <mtaylor> danwent: awesome
21:44:09 <danwent> indeed :)
21:44:27 <gongys> mtaylor: and then https://review.openstack.org/#/c/8443/
21:44:36 <danwent> Ok, and final F-2 High issue is Quantum + Horizon integration: https://blueprints.launchpad.net/quantum/+spec/quantum-horizon
21:44:45 * mtaylor has a docs change someone in here could approve: https://review.openstack.org/#/c/8498/
21:44:46 <mtaylor> :)
21:45:07 <danwent> mtaylor: yup, i'm already +2, so we just need one more
21:45:19 <danwent> (unless there's been a rebase)
21:45:30 <danwent> one more core that is
21:45:50 <danwent> on the topic of quantum + horizon, arvind said he couldn't make this meeting, but he'll send an update to the ML tomorrow
21:46:15 <danwent> this work is obviously very dependent on the v2 clientlib, which is why i'd like to focus review energies on getting that in
21:46:34 <danwent> (link again: https://review.openstack.org/#/c/7596/)
21:46:54 <danwent> Oh, and one high priority issue that I missed was quantum api authz:
21:47:05 <danwent> https://blueprints.launchpad.net/quantum/+spec/authorization-support-for-quantum
21:47:24 <danwent> kevin mitchell from rackspace has ported the authz framework over from nova.
21:48:05 <danwent> however, that framework isn't smart enough to handle the fact that we need to validate "foreign keys" in API requests (e.g., the 'network-id' in the subnet request must be owned by the same tenant-id that is creating the subnet)
21:48:35 <danwent> so I've asked kevin to file a bp or bug on this if he isn't going to handle it in this patch.
21:48:53 <danwent> phew… that's a lot of stuff for F-2…. did I miss any high or above issues?
21:49:47 <danwent> obviously, there's a lot of new code that will be landing in the next two weeks, so we'll need everyone to really up on their review hours.  This is crunch time, particularly if you're not working on a high-priority F-2 deliverable.
21:49:59 <danwent> Anything else to discuss for F-2 before we go to community topics?
21:50:19 <garyk> i think that we should move scalable clients to f-3
21:51:04 <danwent> garyk: yeah, i've already been bumping pretty much all of my stuff that isn't essentnial for a basic v2 setup.
21:51:49 <danwent> garyk: you should be able to change the milestone in launchpad yourself, otherwise, let me know
21:51:51 <garyk> danwent: linuxbridge is coded, but it would be cutting it fine with the rest of the stuff
21:52:00 <garyk> danwent: ok
21:52:20 <danwent> garyk: yes, especially with review cycles, which may be our limiting factor in the end.
21:52:35 <danwent> #topic community topics
21:52:41 <danwent> two items to bring up.
21:53:04 <danwent> #info core dev review days started today: http://wiki.openstack.org/Quantum/ReviewDays
21:53:21 <danwent> if you're a core dev and not signed up, please send me a note explaining why.
21:53:50 <danwent> hopefully this will help us keep responsive to our growing group of developers
21:54:08 <danwent> other community topic I wanted to bring up was pep8
21:54:39 <edgarmagana> danwent: review day means the whole day, right?  I usually book time after working hours to do that!
21:55:02 <danwent> edgarmagana: not necessarily the whole day, but a good chunk of it (e.g., 3 hours)
21:55:19 <danwent> the idea is that we can guarantee that a developer will be looking at key stuff in a timely manner
21:55:42 <danwent> edgarmagana: if your review time is at night (i know the feeling) perhaps signing up for a different region would make sense.
21:56:10 <danwent> I assume salvatore's use of Americas, EMEA, and APAC was intended to mean the work hours there.
21:56:40 <danwent> so your non-standard american hours might better correspond to another region's work hours
21:57:05 <danwent> any other concerns around review days?
21:57:24 <danwent> salv-orlando: how do you manage to join right after I mentioned review days again? :P
21:57:35 <salv-orlando> actually I joined wrong
21:57:36 <danwent> salv-orlando: anything to add?  we need to wrap up soon.
21:57:44 <salv-orlando> No nothing from me.
21:58:23 <danwent> ok, finally, just wanted to see if people were still happy with our decision to have the pep8 version floating
21:58:35 <gongys> but pep8 1.3 is gorgeous.
21:58:46 <danwent> the version seems to update more frequently than I would have guessed, but I do say I like the results
21:58:57 <ncode> yeap… this give us some surprises
21:59:04 <PotHix> Ok for me! :)
21:59:06 <ncode> but the code will be good at end
21:59:12 <danwent> i tend to think that future changes will not be as massive as the pep 1.3 change was, and that we can keep it this way, but wanted to confirm.
21:59:32 <edgarmagana> I'm back!!
21:59:40 <danwent> ok, so hearing no complaints, let's keep with our existing policy.  we'll have the shiniest code in all of openstack :)
21:59:48 <gongys> it can filter out many styled (how to say) fault.
21:59:59 <danwent> #topic open disccusion
22:00:04 <danwent> any open discussion items?
22:00:27 <gongys> we will not use melange any more in v2.0
22:00:28 <gongys> ?
22:00:34 <salv-orlando> Did you already discuss the python24 issue in the ovs plugin?
22:00:37 <danwent> gongys: correct
22:00:48 <ncode> salv-orlando: great I almost missed that
22:00:52 <gongys> ok.
22:00:54 <danwent> salv-orlando: thanks for mentioning that.
22:01:13 <danwent> I think people are exploring a couple directions:
22:01:26 <danwent> - installing v2.6 in dom0 (likely not officially supported)
22:01:47 <danwent> - using something like rootwrap to allow running agent in service VM, but execute commands on dom0
22:01:50 <salv-orlando> I reckon you can replace likely with certainly :)
22:02:01 <danwent> - implementing new version of plugin all together (mnewby mentioned this)
22:02:15 <danwent> salv-orlando: :)
22:02:35 <danwent> mnewby has been the biggest person pushing for a new approach, and he's on vacation this week.
22:03:02 <ncode> the bad thing about the 2.4
22:03:06 <gongys> Haha, biggest person. :)
22:03:06 <jkoelker> what's wrong with a parralel install of 2.6? just curious
22:03:09 <danwent> another option is getting openstack-common to be v2.4 clean (i forget where we stand on that)
22:03:10 <ncode> will be the openstack.common
22:03:38 <ncode> jkoelker: you could lose you support
22:03:43 <ncode> from citrix
22:03:55 <jkoelker> os-common will not be 2.4 clean
22:04:12 <ncode> I've checked that here, we are using the XS with license but without support
22:04:33 <jkoelker> ncode: I don't see how, installing 2.6 on RHEL didn't preclude support on RHEL supported items
22:04:46 <jkoelker> its a parallel install, completely separate from the main interpreter
22:04:55 <ncode> jkoelker: they have cryied one time about a vim installed inside the box
22:05:03 <ncode> jkoelker: yeap
22:05:45 <ncode> It doesn't bring any problems
22:06:06 <danwent> ok, so to wrap up.  we wan't going to limit use of openstack-common in quantum, so we will need to find a way for XenServer to deal with that.
22:06:13 <salv-orlando> I second Maru's approach as well, but I do realize some user would be happy with having python26 in dom0 too.
22:06:13 <salv-orlando> jkoelker: nothing  wrong as long as you don't try to replace python24 with python26. Main issues are support and the fact that you need to carefully manage the dual python environemnt as well as updates from EPEL.
22:06:15 <salv-orlando> Anyway, it seems we need to continue this discussion on the mailing list as we're already 5 minutes late
22:06:23 <danwent> wan't -> aren't
22:06:45 <danwent> salv-orlando: agreed.
22:06:53 <jkoelker> salv-orlando: right, replacing the stock interpreter is just asking for trouble
22:07:08 <danwent> ok, please continue this discussion on the ML.
22:07:17 <danwent> ok, to wrap up (already 7 minutes late)
22:07:19 <danwent> ?
22:07:24 <ncode> salv-orlando: for sure, the ideia is keep both
22:07:33 <ncode> oks
22:07:41 <PotHix> ok
22:07:52 <danwent> thanks folks!  keep coding, and reviewing (especially the clientlib/cli and common config patches)
22:07:55 <danwent> #endmeeting