22:02:27 <danwent> #startmeeting
22:02:28 <openstack> Meeting started Tue Feb 28 22:02:27 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:02:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:02:44 <danwent> ok, who's here from netstack team?
22:02:48 <davlap> o/
22:02:55 <mestery> o/
22:02:56 * bhall is here
22:03:02 * rkukura is here
22:03:02 <danwent> #link  Agenda: http://wiki.openstack.org/Network/Meetings
22:03:07 <cdub> o/
22:03:11 <salv-orlando> HELLO
22:03:12 <edgarmagana> Hi!
22:03:21 <danwent> hello all… good crowd :)
22:03:36 <wwkeyboard> here
22:03:36 <bhall> salv-orlando: don't need to yell ..
22:03:37 <edgarmagana> short agenda, I love it!
22:03:37 <bhall> :)
22:03:46 <danwent> #info  today is the last day to use an invite code to get a seat at the developer summit.  Use it or lose it!
22:04:03 <SumitNaiksatam> hi
22:04:06 <danwent> #info after today, will be general registration open to all until it fills up
22:04:35 <danwent> Ok, main focus today is E-4: https://launchpad.net/quantum/+milestone/essex-4
22:04:45 <danwent> please pull up page so we can walk through issues
22:04:49 <danwent> debo-os here?
22:05:08 <danwent> https://blueprints.launchpad.net/quantum/+spec/quantum-system-functional-tests
22:05:36 <danwent> this doesn't have to do into quantum or nova, so its not subject to milestone-proposed, but we'd like to get this merged into devstack soon
22:05:55 <danwent> will be important to avoid breakage as we get very close to essex release.
22:06:23 <danwent> all other blueprints are already in and merged…. good work reviewing all.  Nice to have a more relaxed release (fingers crossed)
22:06:31 <danwent> There are a few bugs we need to talk about
22:06:42 <debo-os> hi
22:06:55 <danwent> ah, debo. any update on the exercise.sh script + devstack?
22:07:42 <debo-os> my devstack scripts are running into some issues with teh latest pull .... keystone again ... other than that
22:07:58 <debo-os> I think I should send out the review tonight (crosses fingers)
22:08:04 <danwent> ok… is this a known issue for keystone?
22:08:09 <debo-os> htey have the stuff suggested by DaveL
22:08:14 <danwent> or do we need to contact them?
22:08:41 <debo-os> I think they changed the cli (and we are using the cli)
22:08:49 <davlap> debo-os: i ran into the same thing..
22:08:54 <davlap> fix wasn't too bad..
22:09:01 <danwent> debo-os:  me too.  I think they actually changed it twice :)
22:09:28 <anotherjesse> danwent: at least
22:09:32 <anotherjesse> (we did)
22:09:37 <danwent> :)
22:09:44 <debo-os> cool, then we will figure it out by today and do a review
22:09:45 <anotherjesse> feel free to email any questions though
22:09:51 <danwent> ok, so debo-os will try to get devstack stuff in tonight.  Dave can help work around keystone issue if needed.
22:10:01 <danwent> anotherjesse:  thanks, debo may take you up on that
22:10:28 <danwent> Ok, next topic is bug 942713
22:10:29 <uvirtbot`> Launchpad bug 942713 in quantum "some plugins don't check tenant ownership" [Critical,In progress] https://launchpad.net/bugs/942713
22:10:39 <danwent> two things here
22:11:12 <danwent> 1) we need reviews on this patch.  changes are pretty simple, and covered by unit tests, so I don't expect problems there, we just need eyeballs
22:11:14 <debo-os> dan,davel:thx for the help
22:11:22 <debo-os> anotherjesse: here i come to bug
22:11:37 <danwent> 2) someone from the cisco team should look into whether changes are needed for the cisco plugin
22:11:51 <SumitNaiksatam> dan: reg cisco, thats a different db
22:11:52 <danwent> as that uses a different database module, based on a very quick inspection
22:12:00 <SumitNaiksatam> yeah
22:12:11 <danwent> Sumit: Ok, just wanted to give you a heads up.
22:12:20 <SumitNaiksatam> dan: were you able to test this end-to-end, i.e. alongwith QuantumManager?
22:12:23 <SumitNaiksatam> dan: thanks
22:12:30 <salv-orlando> danwent: what about the authorization work? I was expecting that to cover ownership
22:12:42 <danwent> Sumit: not yet.
22:12:55 <SumitNaiksatam> i had problems earlier when I was trying to do something similar
22:13:07 <SumitNaiksatam> while doing the Linux bridge plugin
22:13:15 <SumitNaiksatam> QM was sending some different tenant ids
22:13:35 <SumitNaiksatam> as to what was in the Quantum DB
22:14:00 <SumitNaiksatam> may or may not be as issue still (unless it was by design)
22:14:03 <danwent> salv-orlando: tenant-id is passed into the plugin, so it seems odd that the plugin would not at least check the tenant-id
22:14:06 <SumitNaiksatam> thought i did just mention it
22:14:31 <danwent> Sumit: thanks.
22:15:21 <salv-orlando> danwent: I'm fine with that. We just need to keep in mind that we have to document it.
22:15:50 <danwent> Salv-orlando: can you clarify?
22:16:21 <danwent> salv-orlando: current bug is that if I create a network using tenant X with UUID Z, and then query using a URL with tenant Y and UUID Z, I get a response
22:16:26 <danwent> that this network exists.
22:16:37 <salv-orlando> People that want to write a Quantum plugin need to know that they have to check that the tenant-id invoking the call must own the network for which the call is concerned
22:17:01 <salv-orlando> otherwise they will commit code without this check... as it was for the plugins we have now in our repository! :)
22:17:13 <salv-orlando> that what I meant by 'documenting'
22:17:16 <danwent> salv-orlando:  sure.  I also added a unit test, so they won't be able to pass unit tests
22:17:27 <salv-orlando> danwent: cool, that counts as documentation
22:17:55 <danwent> salv-orlando: perhaps we should also update the quantum_plugin_base class documentation to make it more clear what the meaning of the "tenant" being passed in is.
22:18:06 <salv-orlando> make sense
22:18:33 <danwent> #TODO: #danwent look into updating quantum_plugin_base.py to document that tenant-id should be checked.
22:18:44 <salv-orlando> are we then going to abort the authorization work assigned to Somik? Or are we still doing it for Folsom?
22:19:03 <danwent> salv-orlando: still worth doing for Folsom, I believe.
22:19:11 <salv-orlando> ok
22:19:12 <danwent> Deepak was actually planning on working on it
22:20:16 <danwent> Another fairly urgent issue reported on this list is that floating IPs aren't working, at least in some scenarios: 942896
22:20:20 <danwent> bug 942896
22:20:20 <uvirtbot`> Launchpad bug 942896 in quantum "QuantumManager should set network['host'] when creating the network entry in the database" [High,In progress] https://launchpad.net/bugs/942896
22:20:39 <danwent> This will be a nova change, I think brad will propose it today.
22:21:04 <danwent> sumit, you have: bug 922356 and bug 941794
22:21:05 <uvirtbot`> Launchpad bug 922356 in quantum "QuantumManager does not invoke unplug on the linux_net driver" [Medium,New] https://launchpad.net/bugs/922356
22:21:06 <uvirtbot`> Launchpad bug 941794 in quantum "VIF and Interface drivers for Quantum Linux Bridge plugin need to be added to linux_net library" [Undecided,In progress] https://launchpad.net/bugs/941794
22:21:22 <danwent> one is in review, right?
22:21:30 <danwent> what is status on other?
22:22:28 <SumitNaiksatam> the former one, I am working on it
22:22:50 <SumitNaiksatam> the later one has one review, but I guess need two core reviews on the nova side
22:23:17 <danwent> ok, sounds good.
22:23:27 <SumitNaiksatam> had some discussion with Vish yesterday, and he seems to be in favor of getting it it (i am referring to 941794)
22:23:53 <danwent> salv-orlando: bug 921743
22:23:53 <uvirtbot`> Launchpad bug 921743 in quantum "Quantum API 1.0 does not conform with spec for creates" [High,In progress] https://launchpad.net/bugs/921743
22:24:04 <SumitNaiksatam> it -> in
22:24:04 <salv-orlando> Gerrit hates me
22:24:10 <danwent> I think that was proposed a while back, but never reviewed.  Planning on proposing for review again?
22:24:41 <salv-orlando> I am trying to resubmit it but everytime gerrit rejects the change. I also ensured another change-id was generated.
22:25:01 <salv-orlando> If nothing works, I will do a completely new branch with the same changes and see what happens
22:25:45 <danwent> very strange...
22:26:11 <danwent> given time constraints, creating a new branch is probably best, but might be good to ping mtaylor or jeblair
22:26:24 <danwent> as it could be a bug in the infrastructure itself.
22:26:48 <edgarmagana> Salv: I had an issue with gerrit because of having two IDs
22:26:50 <salv-orlando> It worked fine with another bug. I must be doing somehting wrong with this but I can't understand what.
22:27:30 <danwent> salv-orlando: yeah, i'd just generate a patch, create a new branch from master, and apply patch
22:28:03 <danwent> We also have the lxml requirement change patch: https://review.openstack.org/#change,4235
22:28:06 <salv-orlando> you will not believe me, but I did a cherry-pick from that branch to a new branch and it still did not work :) but the patch is something different and might work
22:28:12 <danwent> that needs some love from two core reviewers
22:28:22 <salv-orlando> didn't I loved it already :)
22:28:24 <salv-orlando> ?
22:28:40 <danwent> perhaps in a former life (i.e., former patch-set)
22:28:50 <danwent> its a needy lover
22:29:06 <salv-orlando> I just gave her a kiss
22:29:15 <danwent> thx.  I will review as well, so we should be good there
22:29:50 <danwent> also: https://review.openstack.org/#change,4580
22:30:01 <danwent> adds support for detail actions to the client-lib and CLI
22:30:16 <danwent> would be nice to have that… was an oversight that this functionality wasn't there in the first place
22:30:47 <danwent> https://review.openstack.org/#change,3808 - mtaylor's patch to freeze requirements
22:30:52 <danwent> also in the client repo
22:31:15 <danwent> i'm not sure about the status of this one, or whether anyone has tested it.
22:31:18 <danwent> any comments?
22:31:41 <danwent> seems mainly developer relevant, so there's probably no need to rush it before a release
22:31:47 <salv-orlando> 4580 also adds run_tests to python-quantumclient, which is good
22:32:20 <danwent> salv-orlando:  ah… I actually thought that we were moving away from that toward tox.. or at least that is what mtaylor said.
22:32:28 <danwent> (I may be misremembering though)
22:32:50 <danwent> I agree that the lack of a run_tests.sh is a bit confusing, so I'm ok with adding it unless someone else objects
22:32:55 <salv-orlando> danwent: you're right
22:33:23 <salv-orlando> but is tox integrated with jenkins on gerrit?
22:34:05 <danwent> right now jenkins doesn't run our unit tests for quantum or python-quantumclient.  I already contacted the openstack-ci team to try and get that running, now that we're going to be core
22:34:12 <danwent> haven't heard back yet.
22:34:31 <danwent> #TODO: #danwent ping openstack CI team again about gating quantum repos on unit tests
22:35:17 <danwent> Ok, any other E-4 items to discuss?
22:35:18 <salv-orlando> ok, so I think we should probably ash Madhav to split bhis changeset in two: one for the cli improvement, and one for the run_tests bit
22:35:39 <danwent> salv-orlando:  I would agree with that approach (haven't looked at the patch itself yet)
22:36:06 <danwent> in general, seems like two entirely different changes
22:36:24 <salv-orlando> they are :)
22:36:36 <danwent> Ok, open discussion
22:36:50 <danwent> one topic we wanted to touch on briefly was related to a patch from Isaku Yamahata
22:37:08 <carlp> Is everyone who is a steakholder in Layer 3 services going to the design summit and/or conference?
22:37:10 <danwent> he was proposing adding plugin-specific dependencies to the main pip-requires
22:37:21 <danwent> carlp: one sec please
22:37:56 <danwent> so far our model has been that pip-requires only include plugin agnostic dependencies
22:38:01 <salv-orlando> I agree with you r-1
22:38:07 <salv-orlando> your minus 1
22:38:18 <danwent> though we violate that a bit for the SamplePlugin, since that is needed to run tests and the dependencies are pretty similar
22:38:32 <danwent> if anyone disagrees, please speak up, otherwise we'll keep the -1.
22:38:51 <salv-orlando> I don't see any reason for installing dependencies for plugins that one is not going to use
22:38:58 <danwent> for a while we had plugin-specific pip-requires files, but I believe someone from the openstack ci team didn't like that?
22:39:16 <danwent> anyone remember anything more about that?
22:39:41 <danwent> ok, carlp, please proceed
22:39:43 <cdub> it's nice to record the dependencies, and esp. if they go into their own repos later, pip-requires makes sense then (obviously ;)
22:40:15 <carlp> danwent: didn't mean to talk over you, my typing not so fast today :)
22:40:18 <danwent> cdub:  yes, i'd like a standard way for plugins to describe their dependencies, but in a way that doesn't require everyone to install dependencies for all plugins
22:40:26 <SumitNaiksatam> the current mechanism of documenting in the README is does not seem to be ideal
22:40:31 <danwent> carlp: no worries.
22:40:39 <cdub> danwent: agreed there
22:40:45 <danwent> Sumit: agreed.  something more standardized, like plugin specific pip-requires would be nice
22:41:04 <carlp> I'd like to have an in-person discussion about Layer 3 stuff at the summit, I was just wondering if everyone who is a current stakeholder is going to be there?
22:41:05 <SumitNaiksatam> dan: agreed
22:41:18 <danwent> #TODO  #danwent explore why we got rid of plugin-specific pip-requires files.
22:41:34 <bhall> danwent: I think plugin pip-requires got removed because of this: https://bugs.launchpad.net/quantum/+bug/906636
22:41:35 <uvirtbot`> Launchpad bug 906636 in openstack-ci "quantum virtualenv doesn't build" [Critical,Fix released]
22:41:40 <danwent> carlp:  they should be, and if not, they should contact me today about getting an invite
22:42:14 <danwent> as design summit is open to general registration tomorrow, meaning it will fil up fast
22:42:30 <carlp> I won't be there for the summit (overlaps with a planned vacation), but I will be there for the conference and maybe the last day of the conference.
22:43:06 <danwent> bhall:  thanks.  need to read in more detail, but doesn't seem like that required the pip-requires files to be removed
22:43:13 <carlp> I wasn't sure what the schedule would be like, and networking was all on day one last year.  I didn't want to rock the boat, just have a BoF on the last day or during one of the conference days.
22:43:14 <danwent> but perhaps I didn't make it that far down the page
22:43:53 <danwent> carlp: if you will be at the summit on the last day, we could try and schedule the L3 discussions on that day.
22:44:06 <danwent> I can have things rescheduled
22:44:29 <danwent> we can have informal discussions at the conference, but they won't be a replacment for a full design session at the summit.
22:45:04 <danwent> so please ping me once you know your exact schedule
22:45:12 <carlp> danwent: I can be there on the last day, no problem
22:45:18 <mestery> Not sure about other folks, but given travel, I'm planning to take off on Thursday during the conference.
22:45:24 <carlp> danwent: I will need an invite however :)
22:45:32 <danwent> calrp: ok, will send you one
22:45:45 <carlp> danwent: thanks!
22:45:58 <danwent> mestery:  ok, but wed is not a problem for anyone?
22:46:25 <mestery> wed works for me just fine
22:46:29 <danwent> ok, sounds good.  L3 at least will be discussed on wed.
22:46:37 <danwent> Ok, any other quantum discussion?
22:46:47 <danwent> other than keep the good testing, and please help the last few reviews get through
22:47:13 <danwent> ok, have a good week folks!
22:47:17 <danwent> #endmeeting