21:00:29 <danwent> #startmeeting quantum 21:00:29 <openstack> Meeting started Mon Dec 3 21:00:29 2012 UTC. The chair is danwent. Information about MeetBot at http://wiki.debian.org/MeetBot. 21:00:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 21:00:32 <emagana> hello all! 21:00:33 <openstack> The meeting name has been set to 'quantum' 21:00:34 <danwent> #info agenda: http://wiki.openstack.org/Network/Meetings 21:01:05 <mestery> o/ 21:01:09 <danwent> garyk, can you confirm that stable/folsom was released on 11/29 as planned? 21:01:25 <garyk> danwent: yes, it has been released. 21:01:39 <danwent> #info stable/folsom was dropped on schedule on 11/29 21:04:01 <danwent> many, many thanks to garyk for his incredible dedication to stable/folsom :) 21:04:01 <emagana> garyk: congratulations! and also to the entire team! 21:04:01 <garyk> danwent: :). started working on the next one... 21:04:01 <danwent> moving forward in grizzly, we will need to decide what we still deam worth backporting to folsom. likely the bar should rise to cover just "high" or "critical" bugs. 21:04:01 <danwent> as we move further with grizzly and merge more features, backports will get harder. 21:04:01 <danwent> ok, as promised, I want to use the meetings to do a better job of highlighting work that needs to be done on quantum docs 21:04:01 <danwent> #topic quantum docs 21:04:01 <danwent> gongysh wins the award as our doc champioin this week. 21:04:01 <gongysh> how much? 21:04:01 <danwent> he's beeing doing a lot of really valuable work there 21:04:01 <danwent> gongysh: very large amounts of .... 21:04:01 <danwent> gratitude :P 21:04:03 <danwent> https://bugs.launchpad.net/openstack-manuals/+bugs?field.tag=quantum 21:04:26 <danwent> now we really need review cycles to help get these doc changes merged 21:04:46 <danwent> even if you're not a core dev for openstack-manuals, the docs team looks for core team members to +1 changes on their projects 21:04:53 <danwent> so a +1 with a comment that you are a quantum core helps a lot 21:05:04 <danwent> (or just that you're knowledgeable about quantum, even if you're not a core :P) 21:05:06 <danwent> https://bugs.launchpad.net/openstack-manuals/+bug/1064643 21:05:07 <uvirtbot> Launchpad bug 1064643 in openstack-manuals "add example of basic "flat" scenario for quantum" [Critical,In progress] 21:05:21 <danwent> this is the review for yong's example of using flat networks and single networks use case 21:05:39 <danwent> err… that's the bug, this is the review https://review.openstack.org/#/c/17184/ 21:05:59 <danwent> there's also another really important docs review, improving our metadata-related docs: https://review.openstack.org/#/c/16669/ 21:06:09 <danwent> this has been a major stumbling point for users 21:06:49 <danwent> one very KEY point, is that if a doc change also applies to folsom (as both fo the above do, we need to make sure the person submits it to the stable/folsom branch after its merged into master) 21:06:55 <danwent> otherwise, current folsom users will not benefit. 21:07:13 <danwent> there are also two open doc bugs of high priority that someone could grab: https://bugs.launchpad.net/openstack-manuals/+bug/1078588 21:07:19 <danwent> and https://bugs.launchpad.net/openstack-manuals/+bug/1082990 21:07:24 <uvirtbot> Launchpad bug 1078588 in openstack-manuals "provide details for tenant routers use case" [High,Confirmed] 21:07:25 <uvirtbot> Launchpad bug 1082990 in openstack-manuals "quantum docs should point out that security groups must be open to reach vms" [High,Confirmed] 21:07:40 <danwent> we also have two key reviews on the api docs: https://bugs.launchpad.net/openstack-manuals/+bugs?field.tag=netconn-api 21:07:49 <danwent> https://review.openstack.org/#/c/13759/ 21:07:54 <danwent> https://review.openstack.org/#/c/15719/ 21:08:09 <danwent> I'm going to spend the majority of my review cycles this week on docs reviews 21:08:37 <danwent> it would be great if anyone else wanted to do something similar, to help make sure these changes get in soon. 21:09:02 <garyk> danwent: i'll try and chime in a bit 21:09:24 <gongysh> I think I am already there. 21:09:25 <danwent> also, as some new features are arriving in G-2, we should try to make sure code changes aren't merged in until there is at least a doc bug filed, with a pointer to the spec. 21:09:30 <danwent> gongysh: :) 21:09:52 <danwent> ok, anything else on docs? 21:10:09 <salv-orlando> danwent: do you think plugin-specific doc should be in main admin guide? 21:10:09 <danwent> gongysh: thanks again for all your work there! 21:10:18 <salv-orlando> like how to configure a specific plugin in quantum? 21:10:32 <salv-orlando> (or documentation about plugin-specific extensions) 21:10:50 <danwent> salv-orlando: i've gone back and forth on this. My current thinking is that everyone needs to pick a plugin to make quantum useful at all, so it makes sense to have it integrated into the main admin guide. 21:11:18 <danwent> for the API guide, so far we haven't required API docs for extensions that are only implemented by some extensions... 21:11:26 <danwent> we've left it up to the extension author. 21:11:36 <emagana> salv-orlando: I think we could add an apendix section for plugins config 21:11:45 <danwent> (of course, having API docs is a good way to make sure your extension is usable and adopted by other plugins) 21:12:28 <danwent> emagana: well, you definitely need plugin specific stuff in install.... 21:12:29 <danwent> emagana: well, you definitely need plugin specific stuff in install…. 21:12:52 <salv-orlando> danwent: agreed. Multiple sources for documentation is painful. 21:12:55 <danwent> currently, there are sub-sections of various sections, including install that cover per-plugin config. 21:13:19 <emagana> danwent: of course! 21:13:55 <danwent> emagana: ah, were you talking about API guide? 21:14:13 <danwent> ok, then nevermind my comment. i was focused on admin guide. 21:14:16 <emagana> danwent: actually, both! 21:14:23 <danwent> ok, moving on :) 21:14:31 <danwent> #topic reviews + review days 21:14:46 <danwent> so its with some hesitation that I send out this link, but: http://173.203.107.207/~soren/stats/quantum-30days.json 21:15:05 <danwent> this is a script from soren used to calculate reviews across all projects. 21:15:28 <danwent> i'm hesitant because I don't want people to soley focus on the review count, since some reviews take a lot of effort, and some are trivia 21:15:31 <danwent> trivial 21:16:17 <danwent> but look at the numbers does seem to confirm what i would have guessed, that some cores are doing a lot more reviews than others :) 21:16:39 <danwent> in some cases, its hard to imagine that everyone is actualy doing a review day, as they should if they are a core dev. 21:17:16 <rkukura> Looks like I'm the worst offender - point taken 21:17:26 <danwent> so at this point this is just a note that you should look at your number there, and either feel comfortable that you are doing enough, or take it as a sign that you need to be more vigilent about really doing your several hours of reviews per week, ideally as part of a dedicated review day/half-day 21:17:44 <danwent> on that note… http://wiki.openstack.org/Quantum/ReviewDays 21:18:06 <danwent> i had thought we were going to be rolling over people's days, but it looks like the slate was wiped clean (I noticed that today, and had to re-sign up) 21:18:26 <danwent> salv-orlando: can you comment on whether people's review days are being rolled over by default? 21:18:43 <salv-orlando> hard to roll over. Some people don't always pick the same days :) 21:18:56 <salv-orlando> If I had some preferences, I'd enter names automagically 21:19:14 <salv-orlando> I know garyk favourite day is sunday for instance 21:19:21 <danwent> Ok… what about something like people can put a * by their entry, in which case it should be rolled-over? 21:19:27 <gongysh> I have: Tuesday and Thursday. 21:19:37 <danwent> and if they want to pick a one-time day, don't put a * by your name? 21:19:56 <mnewby> I intend to start in again, but I can't commit to a whole day yet. Need to work myself up. 21:20:00 <garyk> salv-orlando: :) 21:20:02 <salv-orlando> danwent: that would sound good to me. For instance I always pick a friday. The "*" will also help me script the stuff 21:20:37 <salv-orlando> mnewby: doesn't have to be a whole day in the literal sense. Just a day when devs knows you're doing reviews and are available for discussion on IRC 21:20:40 <danwent> #info when signing up for a review day, include a * by your name if you want that entry automatically rolled over to the next week. 21:21:15 <mestery> danwent: Is that webpage only for core devs? 21:21:23 <danwent> salv-orlando: yes, agreed. more just a day where you have a few hour to make sure any major new reviews are getting attention 21:21:47 <mnewby> salv-orlando: fair enough. so long as everybody doesn't mind me leaning on them - I've felt pretty lost in the past and ended up doing purely mechanical reviews, and I think that is of limited utility. 21:22:03 <danwent> mestery: up to salv-orlando . to some degree, we want to make sure there is core dev coverage, since that is what can actually get stuff merged. 21:22:26 <mestery> danwent: Makes sense. I'll continue reviewing outside the scope of the webpage for now. 21:22:27 <danwent> but it would also be good to just encourage general review responsiveness, and being a core isn't required for that 21:22:41 <mestery> danwent: Got it 21:23:02 <danwent> ok, any other comments on reviews + review days? 21:23:23 <danwent> #topic grizzly-2 21:23:31 <danwent> grizzly-2 is scheduled for Jan 10th: https://launchpad.net/quantum/+milestone/grizzly-2 21:23:35 <salv-orlando> mestery: feel free to sign up 21:23:52 <danwent> that includes one "off" week during the holiday/new year season 21:24:07 <danwent> its still early in G-2, so what I want to do in this meeting are 21:24:17 <danwent> identify blockers for any reviews that have been through many revisions. 21:24:24 <danwent> identify newer reviews that are missing two core dev reviewers 21:24:30 <danwent> make sure we have specs for any high-priority items by end of this week for review. 21:24:44 <danwent> so, with that, let's take a deep breath and dive in :) 21:24:49 <danwent> https://blueprints.launchpad.net/quantum/+spec/quantum-gate 21:24:50 <mnewby> danwent: I don't see the xs/xcp blueprint in the list. Can it be included? I have a strategy in mind to get it reviewed. 21:25:46 <danwent> mnewby: its targeted for g-2 (https://launchpad.net/quantum/+milestone/grizzly-2), its just not priority high or above, and those are the items we automatically track in meetings 21:26:05 <danwent> we can discuss that BP as well though, at the end of the G-2 section 21:26:21 <mnewby> danwent: sounds good 21:26:27 <danwent> nati_ueno: gate status? 21:26:32 <danwent> https://review.openstack.org/#/c/16506/ 21:26:38 <danwent> garyk and i are reviewing that 21:27:03 <nati_ueno> danwent: It looks start failing again. So I'm trying to fix it now. But glance-api didn't start yet. 21:27:09 <garyk> danwent: nati_ueno my setup is finally up and running so tomorrow i'll have free cycles for it 21:27:11 <nati_ueno> danwent: I'll try to fix it ASAP 21:27:41 <danwent> nati_ueno: ok… ping us when its ready for another review. devstack is kind of a mess lately with all of the project changes :-/ 21:27:44 <nati_ueno> garyk: Ah really? OK I'll push rebased version, so could you try new one? 21:28:06 <danwent> https://blueprints.launchpad.net/quantum/+spec/quantum-db-upgrades 21:28:10 <danwent> markmcclain: 21:28:10 <nati_ueno> danwent: Thanks 21:28:14 <garyk> nati_ueno: first thing tomorrow (my time) 21:28:18 <danwent> https://docs.google.com/a/nicira.com/document/d/1YzKDf9IzfsmlhPvtNLv9d-luap25YlihBTqtcnEjrQo/edit 21:28:30 <danwent> #info spec for db upgrade migration https://docs.google.com/a/nicira.com/document/d/1YzKDf9IzfsmlhPvtNLv9d-luap25YlihBTqtcnEjrQo/edit 21:28:31 <nati_ueno> garyk: Thanks 21:28:44 <danwent> markmcclain: i think you said you expect to post a review soon? 21:28:52 <markmcclain> was hoping for today, but should be pushed tomorrow 21:29:05 <danwent> ok, can we quickly ID two core devs for this? 21:29:10 <garyk> nati_ueno: glance - check out https://answers.launchpad.net/nova/+question/163369 21:29:19 <danwent> this is an essential BP, so i'd like to get it reviewed ASAP 21:29:27 <nati_ueno> garyk: Thanks 21:29:35 <gongysh> I want. 21:29:56 <garyk> nati_ueno: look at #6 21:30:16 <danwent> ok, i will step in as second core if no one else wants to 21:30:24 <danwent> markmcclain: please ping us when its available 21:30:25 <nati_ueno> garyk: oh, clean up rabbitmq fixes the problem! Thanks 21:30:28 <markmcclain> will do 21:30:52 <danwent> gongysh: https://blueprints.launchpad.net/quantum/+spec/rpc-for-l3-agent 21:31:02 <danwent> this was one of the items we were targeted to already be merged 21:31:23 <garyk> danwent: it is looking good. just needs on extra core dev 21:31:27 <danwent> https://review.openstack.org/#/c/15619/ 21:31:42 <markmcclain> I'm close to a +2 21:31:50 <danwent> markmcclain: ok, great. 21:32:05 <danwent> markmcclain: https://blueprints.launchpad.net/quantum/+spec/metadata-overlapping-networks 21:32:14 <danwent> main quantum, nova + devstack reviews are in 21:32:16 <salv-orlando> danwent: I was the 2nd core, and it's a +2 for me, but I moved it to +1 to let markmcclain review too 21:32:36 <danwent> markmcclain: are we keeping this BP for one additional quantum commit 21:32:38 <danwent> ? 21:32:46 <danwent> or using a separate BP for that? 21:32:49 <markmcclain> isolated nets 21:32:56 <markmcclain> we can file a separate one if that's easier 21:33:09 <danwent> yeah, let's do that 21:33:13 <danwent> so mark this one as implemented 21:33:24 <markmcclain> done 21:33:30 <danwent> markmcclain: thx 21:33:32 <danwent> nati_ueno: https://blueprints.launchpad.net/quantum/+spec/quantum-security-groups-iptables 21:33:42 <danwent> we're close on this one too, i believe? 21:33:50 <danwent> https://review.openstack.org/#/c/16210/ 21:33:53 <nati_ueno> Yes. But we need to agree the spec 21:34:02 <nati_ueno> source_ip_prefix for egress 21:34:07 <danwent> nati_ueno: ah, was there another email to the ML? 21:34:11 <danwent> i'm a bit behind there 21:34:12 <nati_ueno> danwent: Yes 21:34:21 <gongysh> nati_ueno: does it have the ability to do anti-spoofing? 21:34:34 <nati_ueno> gongysh: Yes I added the implementation 21:34:50 <danwent> #todo danwent amotoki_ arosen respond to ML email about security groups spec 21:35:00 <gongysh> thanks. 21:35:03 <danwent> nati_ueno: and do we still have at least two active core devs on it? 21:35:24 <nati_ueno> danwent: Aaron and Gary and Akihiro is working on the patch. Thanks 21:35:29 <danwent> nati_ueno: great 21:35:30 <garyk> danwent: it is only my list 21:35:35 <arosen> ditto 21:35:42 <amotoki_> ditto 21:35:44 <danwent> garyk: https://blueprints.launchpad.net/quantum/+spec/vif-plugging-improvements 21:36:02 <danwent> garyk: i saw https://review.openstack.org/#/c/16439/, are there other reviews I should be linking to? 21:36:18 <garyk> danwent: not yet. tomorrow i'll start on the nova side of things. 21:36:36 <danwent> garyk: looks like we need two more core devs. since we talked a bit about this, i'll be one. but we need another volunteer 21:36:51 <garyk> great 21:37:04 <danwent> any one interested? 21:37:05 <rkukura> I'll look at this. 21:37:10 <danwent> rkukura: thanks 21:37:16 <danwent> enikanorov: https://blueprints.launchpad.net/quantum/+spec/lbaas-restapi-tenant 21:37:26 <danwent> https://review.openstack.org/#/c/15954/ 21:37:39 <enikanorov> discussion continues on health monitor 21:37:48 <danwent> ah, that explains it :) 21:37:51 <enikanorov> i think some core dev shoult step in and say his weighty word 21:38:04 <enikanorov> salv-orlando may be? 21:38:08 <danwent> is there a specific thread on the ML? salv-orlando have you been commenting on this? 21:38:17 <danwent> hehe, my thought as well. poor salv-orlando :P 21:38:28 <salv-orlando> poor me indeed. 21:38:34 <salv-orlando> The work is actually very good. 21:38:35 <enikanorov> i think he has been commenting on this in review 21:38:52 <danwent> ah, i think enikanorov was talking specifically about the health monitor issues on the ML 21:39:07 <salv-orlando> I am not sure about the use of operational status, but at the end of day as long as it is documented is fine. 21:39:11 <enikanorov> afaik, it's the blocker right now 21:39:11 <danwent> can we get some API guru love on that? 21:39:17 <salv-orlando> I'm also sorting the other stuff with Oleg. 21:39:36 <salv-orlando> Actually probably most of you are not aware of this discussion because it was on a gerrit patch 21:39:42 <salv-orlando> and not the main ML. 21:39:52 <salv-orlando> I think Oleg today moved the discussion to the mailing list. 21:39:54 <danwent> ah 21:40:06 <danwent> not that is it so much easier to noticed something on the ML these days :P 21:40:12 <danwent> but yes, the right move. 21:40:35 <danwent> Ok, salv-orlando, as API team lead, please do what you can to break the log-jam :) 21:40:39 <salv-orlando> For some weird reason, I'm starting to find easier to discuss on gerrit. 21:40:52 <danwent> salv-orlando: more focused on concrete code? 21:40:59 <salv-orlando> yep 21:41:11 <danwent> sachin: https://blueprints.launchpad.net/quantum/+spec/lbaas-plugin-api-crud 21:41:32 <danwent> i thought i saw him online earlier in the mtg... 21:41:41 <danwent> i forget his handle though. 21:41:49 <danwent> https://review.openstack.org/16919 21:42:43 <danwent> ah, it looks like we need core dev attention on this patch. 21:42:45 <markmcclain> I'll reivew since it's lots of db changes 21:43:04 <danwent> markmcclain: awesome, thanks. its a beast :P 21:43:16 <danwent> i'm planning on tackling it mid-week as well. 21:43:20 <salv-orlando> yeah I can be the 2nd core if no other core is on it. 21:43:28 <danwent> salv-orlando: by all means 21:43:46 <danwent> salv-orlando: https://blueprints.launchpad.net/quantum/+spec/quantum-service-type 21:43:56 <salv-orlando> danwent: but if you want ti review that it would be a pleasure for me to step down 21:44:16 <salv-orlando> it was pointed out that the spec link points to a fairly generic page on service insertion 21:44:28 <danwent> salv-orlando: if i don't get to it by end of day wed, you can take a crack at it 21:44:49 <danwent> salv-orlando: yes, i think the proposed work is pretty simple, and we should have a spec that reflects that 21:45:25 <salv-orlando> which is totally correct, as this work is pretty much focused on API extension and DB support 21:45:37 <danwent> as I said, i'd like to see specs for anything high or above by end of week, so there is time for discussion, impl, and review 21:45:42 <salv-orlando> I have unfortunately lost last week due to other commitments, and I'm now back to work on this 21:45:57 <danwent> salv-orlando: ok, do you think having a spec by end of week is reasonable? 21:46:30 <danwent> ok, got to keep moving.... 21:46:35 <emagana> salv-orlando: let me know how i can help 21:46:41 <danwent> last one on the list (then mnewby) 21:46:47 <danwent> gongysh: https://blueprints.launchpad.net/quantum/+spec/quantum-multihost 21:46:59 <danwent> I assume this is still tied up in the raging ML thread? 21:47:00 <salv-orlando> dawent: I am writing the spec as we talk 21:47:13 <danwent> salv-orlando: no wonder you're taking so long to respond :P 21:47:25 <gongysh> danwent: I think most of us don't like it 21:47:38 <danwent> gongysh: don't like what specifically? 21:47:50 <gongysh> danwent: multi-host 21:47:51 <danwent> multi-host model? 21:47:57 <gongysh> yes 21:47:57 <danwent> yeah, i don't like it either to be frank 21:48:10 <gongysh> do we still need it? 21:48:32 <salv-orlando> We need the use case for nova parity 21:48:34 <gongysh> how about canceling it? 21:48:39 <salv-orlando> Not sure we need all the rest around it 21:48:58 <emagana> danwent: what is the alternative for HA? active/standby model? 21:48:59 <danwent> salv-orlando: well, we at least need something that people feel provides similar HA + perf properties 21:49:16 <salv-orlando> (see host management, and 'scheduling') 21:49:39 <mnewby> danwent: isn't HA an implemention issue? All services have this same problem, and solutions are available outside of the openstack ecosystem. 21:49:44 <salv-orlando> I've not following the discussion very closely but gongysh's point is that scheduling and host management are necessary for doing the nova use case 21:50:12 <salv-orlando> at least this is what I gathered 21:50:22 <emagana> This is not just an HA solution, i think this is also a Performance issue 21:50:31 <danwent> mnewby: multi-host, for all its failures, has a very compelling HA model that isn't currently possible with Quantum 21:50:37 <emagana> Having Network Node driving all DHCP request is not a good design 21:50:59 <danwent> i.e., L3 + DHCP services are only lost if the hypervisor running the associated VMs are lost (in which case you probably don't care too much) 21:51:02 <mnewby> Please, let me know which cloud providers choose multi-host as their implementation stragegy. 21:51:16 <mnewby> I'll be sure to short their stock. :p 21:51:28 * mnewby runs and hides 21:51:33 <danwent> mnewby: unfortunately, i've been told by many openstack implemetors that they do 21:51:44 <danwent> mnewby: so even though my person feelings match yours 21:51:47 <haleyb> mnewby: HP cloud does, for both performance and HA 21:52:15 <danwent> mnewby: i think the quantum community needs to be very clear about how you achieve something similar, or why we think it does not deserve to be implemented. 21:52:22 <gongysh> Yes. HP guys told me at design summit. 21:52:28 <mnewby> that's just sad 21:52:32 <haleyb> yes, i'm one of them :) 21:52:33 <danwent> its much more than HP though 21:52:34 <mnewby> but i digress 21:53:19 <danwent> ok, we're going to run out of time. I will follow-up on ML about this. 21:53:32 <zykes-> what's bad with multihost ? 21:53:35 <danwent> #todo danwent lead team discussion on multi-host 21:53:50 <danwent> zykes-: not enough time to explain in this meeting…. 21:53:55 <danwent> ok, mnewby 21:53:57 <zykes-> ok. 21:54:16 <danwent> mnewby: you wanted to talk about xenserver/ovs stuff? 21:54:25 <danwent> https://blueprints.launchpad.net/quantum/+spec/xenapi-ovs 21:54:35 <mnewby> danwent: The reviews haven't seen any love, and that's understandable. 21:54:42 <mnewby> danwent: Hard to replicate a test environment. 21:54:54 <danwent> true 21:55:03 <mnewby> danwent: So I have an idea… First, I'm going to get the tempest tests done (truly). 21:55:10 <mnewby> danwent: Then I'll need 2 reviewers. 21:55:28 <mnewby> danwent: One will verify that kvm behaviour is unmodified by the xs/xcp supporting changes. 21:55:30 <danwent> mnewby: if you get the tempest stuff done, i'll do whatever you need as a reviewer in quantum :) 21:55:44 <garyk> mnewby: i'll volunteer - any chance of giving me remote access to be able to test? 21:55:48 <mnewby> danwent: The other I will assist in getting an xs/xcp devstack environment for them to run the tests against. 21:56:13 <danwent> mnewby: ok, i can definitely help 21:56:15 <mnewby> garyk: No remote access, I'm afraid, but it will be possible to bring up xcp under a vm. 21:56:23 <gongysh> tell me how to set up an Xen env, I will chime in. 21:56:31 <garyk> mnewby: ok. i'll just bug you for the details 21:56:39 <danwent> ok, sorry, got to keep moving. but looks like danwent, garyk, and gongysh are available to help 21:56:50 <mnewby> good stuff 21:56:54 <danwent> #topic open work items 21:57:19 <danwent> often i'm asked for open blueprints or tasks, so I just wanted to highlight a few here before we wrap up 21:57:19 <salv-orlando> so… what about multi-host? 21:57:25 <salv-orlando> :) sorry that was troll me 21:57:29 <danwent> salv-orlando: i'm going to follow-up on ML 21:57:32 <danwent> https://blueprints.launchpad.net/quantum/+spec/quantum-v2-euca-compat 21:57:40 <danwent> this is a very useful task that it would be useful for someone to own. 21:58:01 <danwent> though it may depend on work from arosen or someone else on a security group proxy. arosen, is there a BP tracking that? 21:58:19 <danwent> https://blueprints.launchpad.net/quantum/+spec/db-profiling-at-scale 21:58:24 <salv-orlando> danwent: I know, I just could not resist trolling a bit. Sorry about that. 21:58:37 <salv-orlando> danwent: we first want to define what euca compatibility means 21:58:45 <danwent> this is another very valuable item. markmcclain is going to be working on this later, but i'm sure other people could jump in and work on it as well. 21:59:27 <salv-orlando> danwent: as it is related to API too, it probably makes sense mark and I work together on this. emagana also had done some work, so his contribution would be valuable too 21:59:31 <danwent> salv-orlando: basically, run nova + quantum, and audit what portions of euca-networking commands may have issues, and fix them. 21:59:35 <gongysh> Do we have a BP for API v2.1? 21:59:58 <salv-orlando> danwent: ok - so it's not about having a EC2 endpoint on Quantum? 22:00:08 <danwent> there is also mnewby's tempest review (https://review.openstack.org/#/c/12485/), which would use additional review + testing. 22:00:09 <gongysh> I am wondering the pagination BP which is postponed to G2. 22:00:17 <danwent> and then people can expand on it to add new tests. 22:00:30 <gongysh> I think horizon is wanting it. 22:00:37 <mnewby> danwent: will be submitting a revised version this week… reviews can wait until it gets updated. 22:00:43 <salv-orlando> gongysh: Is there any API change that cannot be supported by 2.0 clients? 22:01:08 <danwent> mnewby: ok, maybe make a note of that on the reivew so others don't waste cycles (if the changes are going to be substantial) 22:01:12 <danwent> #topic open discussion 22:01:13 <mnewby> ok, will do 22:01:15 <danwent> ok, one minute over time 22:01:18 <salv-orlando> pagination was backward compatible too (has to be - otherwise it won't be worth bumping up API version for it) 22:01:25 <danwent> garyk is probably falling asleep :P 22:01:31 <danwent> any open discussion? 22:01:46 <garyk> danwent: yup. i'm toast. good night all 22:01:47 <nati_ueno> I faced the problem with transaction and eventlet 22:01:50 <danwent> please remember to sign up for review days 22:02:00 <danwent> http://wiki.openstack.org/Quantum/ReviewDays 22:02:03 <salv-orlando> and don't forget the '*' 22:02:05 <danwent> and then to actually review :) 22:02:10 <nati_ueno> This looks fatal problem, so I'm happy if I can get response for my mail 22:02:16 <gongysh> yes. it is back compatible. 22:02:23 <mnewby> anybody up for helping me get devstack running after the meeting? I'm seeing amqp problems and don't know where to start :( 22:02:29 <gongysh> But we are forgetting this BP. 22:02:41 <danwent> mnewby: i think several other people mentioned this as well 22:02:43 <danwent> what is the error? 22:02:46 <nati_ueno> mnewby: uninstall rabbitmq and delete /var/lib/rabbitmq 22:02:55 <danwent> Ok, let's wrap up the official meeting, and anyone who wants can hang around to chat. 22:02:57 <mnewby> nati_ueno: will do, thank you. 22:03:00 <danwent> #endmeeting