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