22:00:53 <danwent> #startmeeting
22:00:53 <openstack> Meeting started Tue Jan 10 22:00:53 2012 UTC.  The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:54 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:01:00 <salv-orlando> hi!
22:01:09 <danwent> #info agenda http://wiki.openstack.org/Network/Meetings
22:01:16 <edgarmagana> hello!
22:01:22 <danwent> hello!
22:01:32 <somik> hi folks!
22:01:42 <danwent> #topic Quantum Status
22:01:55 <danwent> We are now a short two weeks out from code freeze for Essex-3
22:02:10 <danwent> https://launchpad.net/quantum/+milestone/essex-3
22:02:36 <danwent> still have a couple of things in 'unkown'
22:02:50 <danwent> so let's get that cleaned up ASAP
22:03:28 <danwent> hopefully all of the 'started' items won't change to 'code review' at the last minute.
22:03:33 <danwent> any general comments on E-3?
22:03:40 <cdub> have a prioritizied list?
22:04:11 <danwent> cdub: you mean in terms of reviews?
22:04:37 <cdub> yeah
22:04:54 <cdub> i suppose launchpad has some priority already
22:04:59 <danwent> we usually go roughly by the 'priority' field of the bp or bug
22:05:20 <danwent> with a bias toward things that got in "on time"
22:05:30 <danwent> or (heaven forbid) early
22:05:49 <danwent> Ok, on to reviews.
22:06:05 <danwent> #link: reviews are already piling up: https://review.openstack.org/#q,status:open+project:openstack/quantum,n,z
22:06:37 <danwent> would be good if every core dev could do one or two reviews this week, to make sure that we clean the pipeline for the new reviews that will come at the end of the cycle.
22:06:54 <danwent> most current reviews are pretty small, and if you act quickly, you can pick the easiest ones :P
22:07:13 <salv-orlando> Can you guys remind me how the new approval process works? can the same reviewer do +2 and then approve, or do we need 2 distinct reviewers for that?
22:07:28 <danwent> +2 indicates a core reviewer
22:07:37 <danwent> you can nown +2 even if you are the first core dev to review
22:07:44 <danwent> as +2 no longer automatically submits
22:08:16 <danwent> there is a separate 'approve' action.  if you are the second core dev to review, there is no dissent, and you are happy with the patch, you can just approve it.
22:08:17 <salv-orlando> cool. But I guess that if I do +2 than somebody else must come and approve the changeset.
22:08:31 <salv-orlando> Ok, thanks.
22:08:36 <danwent> yes, a second core dev
22:09:06 <salv-orlando> so, more or less now the process is the same thing as it was with launchpad
22:09:18 <danwent> Ok, so as promised, there was a flurry of ML discussions, which is great.
22:09:37 <danwent> some are still ongoing, but I wanted to see if we had consensus on a couple of them that seem to have wrapped up.
22:09:49 <danwent> is anyone opposed to splitting client repo out?
22:10:08 * mtaylor holds breath
22:10:28 <danwent> not sure how much of the work mtaylor will do, but i'm assuming he'll need a core dev to help out.
22:10:30 <salv-orlando> I don't have any major reason against that.
22:10:41 <danwent> Ok, sold!
22:10:51 <salv-orlando> Just a bit disappointed about code duplication, though :(
22:11:06 <danwent> #todo #danwent create blueprint on splitting client repo out.
22:11:20 <cdub> yeah, that and changes spanning repos, but given the rest of OS workflow, seems reasonable
22:11:26 <danwent> salv-orlando: agreed, but I think its the right call.
22:11:35 <salv-orlando> danwent: I agree too.
22:11:56 <danwent> Ok, next issue may not be ready to close, but debo wanted me to bring it up, as the clock is ticking
22:11:59 <danwent> VPN thread
22:12:25 <danwent> question is whether to modify Nova to make cloudpipe work with quantum, or do separate service.
22:12:37 <cdub> how realistic is new api?
22:12:42 <danwent> won't rehash the discussion, but please respond on this quickly, as if we decide to do it in nova, we need to act VERY quickly.
22:13:02 <danwent> cdub:  to be honest I think having this by essex is risky
22:13:16 <cdub> danwent: by separate service you mean quantum l3, not new foobar service, right?
22:13:25 <cdub> i do too, but you'd have better idea ;)
22:13:42 <danwent> cdub:  perhaps "sub-service" of quantum is a better term.
22:13:50 <cdub> *nod*
22:13:53 <danwent> I think vpn would be separate from L3 though
22:14:04 <cdub> as in, quantum vpn api
22:14:24 <danwent> but as this highlights, tackling our first sub-service is a non-trivial task with a lot of questions to tackle… not something that will happen quickly.
22:14:29 <danwent> cdub: yup
22:14:46 <cdub> certainly makes sense to me long term, i suspect it will put essex at risk of not having vpn though
22:14:51 <salv-orlando> Still, whether VPN APIs are fit to be in Quantum or not, is something that needs to be discussed. Hence, recalling how fierce our discussions typycally are, getting it for Essex sounds really risky!
22:15:46 <danwent> Ok, so as the output of this discussion, I'll take there there is no consensus on this, at least for #2.  I'd like to hear a bit more from the nova folks as to why simply tweaks can't make cloudpipe work with Quantum manager.
22:16:02 <danwent> I think debo knows more about this, which will help us make an informed decision.
22:16:22 <danwent> #todo #debo email netstack about cost of doing nova cloupipe + quantum work.
22:16:33 <danwent> Ok, next topic:  API error codes
22:16:44 <danwent> salv + wwkeyboard where leading discussion here
22:16:54 <salv-orlando> Is wwkeyboard around?
22:17:06 <danwent> was there for the f-naming dicussion
22:17:25 <salv-orlando> Ok. Please give your feedback on the ML. In a nutshell,
22:17:35 <danwent> my general thought is that we need to quickly decide what will and will not happen for API v1.1, as I would prefer not to have API changes late in essex-4
22:17:46 <wwkeyboard> I'm here
22:18:06 <salv-orlando> we are using HTTP error codes for application-level messages.
22:18:29 <salv-orlando> altough this is convenient for some reasons it has three big downsides:
22:18:38 <salv-orlando> 1) client using standard libraries do not expect this codes
22:19:11 <salv-orlando> 2) we are kind of polluting a namespace which is using by somebody else - IEFT I guess
22:19:38 <salv-orlando> and 3) Openstack, Keystone, Glance, and probably even Swift API only use standard HTTP codes
22:19:44 <salv-orlando> Point 3 IMHO is enough
22:19:51 <cdub> i think so too
22:19:53 <salv-orlando> to vote for restructuring error codes
22:20:05 <danwent> salv: plus, there are the kind of issues we ran into today with brad's review
22:20:07 <mestery> +1 for standard HTTP codes
22:20:13 <salv-orlando> danwent: right
22:20:16 <cdub> and cost of client change (esp. now) is still cheap
22:20:45 <danwent> Ok, sounds like consensus.
22:20:46 <salv-orlando> So, if you all agree I can set some time aside for getting this by E-3. I just need your feedback on how to revert to standard HTTP codes. Thanks!
22:21:02 <cdub> sed?
22:21:04 * cdub ducks
22:21:08 <danwent> sweet.  salv: I think i had suggestions in the thread
22:21:12 <danwent> haha
22:21:47 <danwent> #todo #salv-orlando create BP on standardizing HTTP error codes
22:21:58 <danwent> Ok, final issue is not really a discussion
22:22:22 <danwent> I pushed a write-up on code I think is more/less borrowed from other openstack projects and is a candidate for openstack-common
22:22:32 <danwent> #link openstack-common candidates in quantum code: http://wiki.openstack.org/QuantumOpenstackCommon
22:22:58 <danwent> please take a look though and add comments
22:23:04 <danwent> Ok, anything else on Quantum?
22:23:12 <rkukura> quick question
22:23:36 <rkukura> Are  https://blueprints.launchpad.net/quantum/+spec/quantum-linux-bridge-plugin and https://blueprints.launchpad.net/quantum/+spec/basic-vlan-plugin related, and are either likely to make Essex?
22:24:07 <danwent> sumit says they are close to done, i think.
22:24:10 <danwent> is sumit here?
22:24:26 <salv-orlando> rkukura: yes they are. I will talk with Sumit, and we will probably merge them.
22:24:28 <SumitNaiksatam> yeah, I am trying to target the former  for e3
22:24:36 <rkukura> Read through linux-bridge-plugin today, and it looks close
22:24:37 <salv-orlando> In the meanwhile I have untargeted basic-vlan-plugin
22:25:06 <rkukura> thanks!
22:25:47 <danwent> Ok, sumit, if you are targeting e-3, please set the milestone on the BP, otherwise it is hard to track.
22:25:58 <danwent> other questions?
22:26:20 <SumitNaiksatam> yeah, I was just waiting for your feedback in terms of going forward
22:26:39 <SumitNaiksatam> including Salv
22:26:47 <danwent> fair enough :)
22:26:56 <cdub> danwent: when do you plan to target the client repo split bp?
22:27:16 <danwent> cdub:  I think we need to do it pretty urgently, as distros need to be able to incorporate the new packaging
22:27:29 <danwent> well, i guess packages stay the same, but the back-end process will change
22:27:31 <cdub> danwent: rkukura will probably be interested in packaing impact (he was going to do some this week iirc)
22:28:01 <cdub> heh, ok...(you type faster ;)
22:28:09 <rkukura> definitely interested
22:28:11 <danwent> Ok.  mtaylor seems pretty eager.  If we can get someone to help him out in terms of the minor splitting of common code, it will probably move more quickly.
22:28:17 <danwent> any volunteers?
22:28:22 <danwent> and testing a well.
22:28:44 <danwent> mtaylor: you around?
22:29:05 <danwent> Ok, I will respond to the thread and try to get a timeline
22:29:36 <danwent> i know mtaylor has the process of setting up a new openstack repo down to a science, so that should be quick
22:29:45 <danwent> #topic open discussion
22:29:48 <danwent> any open discussion?
22:30:22 <danwent> ok, thanks folks.  have a good week!
22:30:26 <danwent> #endmeeting