17:02:45 #startmeeting Designate 17:02:45 Meeting started Wed Aug 5 17:02:45 2015 UTC and is due to finish in 60 minutes. The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:46 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:48 The meeting name has been set to 'designate' 17:02:51 Hey folks - Who's about? 17:02:56 hi 17:03:00 o? 17:03:06 o/ 17:03:15 * Kiall remebers something.. Quickly edits agenda 17:03:26 o/ 17:03:28 o/ 17:03:53 lol - You do not have permission to edit this page, for the following reason: 17:03:56 Oh well 17:04:02 hahaha 17:04:31 #topic Announcements 17:04:31 Figured a new start of meet item would be handy for general "announcements" 17:04:54 We've now got a non-voting py34 gate on the client, it'll change to voting ASAP. 17:05:07 #topic Action Items from last week 17:05:19 2 actions, both stable backports, all done + merged 17:05:30 and into the meat :) 17:05:31 #topic Bug Triage (timsim - recurring) 17:05:55 Nothing new this week! 17:06:18 hah, that can't be good - OK fair enough so ;) 17:06:20 I think people have been doing small triage during the week. 17:06:24 Which is great 17:06:44 Yep :) Okay, moving on so! 17:06:48 #topic Stable Backport Triage (kiall - recurring) 17:06:51 #link http://paste.openstack.org/show/408985/ 17:06:51 o/ 17:07:08 Please take a minute or two to review, and nominate anything we need to backport.. 17:07:45 db6a6b6 Wildcard records 17:07:47 db6a6b6 Wildcard records 17:07:57 db6a6b6 Wildcard records - If it affects Kilo 17:07:57 2c7c03f Enable filter on get pools 17:08:22 Any others? 17:08:45 Don't think so 17:09:01 nope 17:09:07 #action kiall to BP db6a6b6 + 2c7c03f 17:09:09 K 17:09:23 #topic Designate/Neutron Integration Update (mlavalle) 17:09:30 mlavalle: over to you :) 17:09:52 Kiall: i've continued sending reviews to https://review.openstack.org/#/c/20095 17:10:28 it is now passing the jenkins tests (except last night that I added some unit tests and broke some exu=isting ones) 17:10:52 I got a good review from carl_baldwin . he gave me a -1 but it is mostly minor stuff 17:11:00 #link https://review.openstack.org/#/c/200952 17:11:07 (missing the last digit ;) ) 17:11:21 Dooh, oh well. I've been generally following along with it, looks like it's *nearly* there :) 17:11:26 mlavalle: A much improved -1. :) 17:11:38 so I'll fixx thiose issues and after that I expect this to merge soon 17:11:56 (FYI - I've held off reviewing, as it just only be a token +1.. No clue about Neutron's internals!) 17:12:05 it would just be a * 17:12:07 so starting later this week, i'll be focued on the xternal side 17:12:43 so that's where we are right now 17:13:01 Cool, happy to see that - Do we suspect there's much more to do on the internal review before the neutron-core folks are happy? 17:13:18 Kiall: no i think is is close to merge 17:13:38 that is why i will focus myself to the external side later this week 17:13:48 Okay - Excellent! 17:14:11 Thanks for update, and the relentless work fixing carl_baldwin's nitpick's :P 17:14:39 carl_baldwin is a very insightful reviewer 17:14:43 :P 17:14:48 Anything else / Q's from folks etc before we move on? 17:15:15 nope, just glad to see progress :D 17:15:25 Silnce == "Nope" in this meet :) 17:15:28 #topic Zone Export in /v2 (timsim) 17:15:50 * mlavalle going to another meeting 17:15:54 o/ 17:15:56 mlavalle: enjoy :) 17:16:12 So some people (jmcbride) would like to see this land soon. So I just wanted to talk about a possible implementation a little bit 17:16:50 Thinking about it yesterday, we came up with using the same basic method that we're doing for axfrs, and keeping it synchronous. Rather than implementing some async thing where we've got to persist big blobs of text. 17:16:52 timsim: ++, I'd like to see it land soon (in L at a min) 17:17:31 timsim: where do we persist it? 17:17:35 so, I think that would work for the 90% 17:17:44 So, if we do it sync - Don't we just fall over with large zone? I know we have zones with more records that I would have thought possible ;) 17:18:05 Well, we figured if it was good enough for axfrs, it was good enough for exports :P 17:18:07 but, do we just have a max zone size, and if your zone is over that, we say "tough" 17:18:20 james_li: it could be dropped into memcahe (assuming under 1MB) or into Swift 17:18:30 timsim: axfrs are not limited by HTTP / AMQP timeouts ;) 17:18:42 ic 17:18:54 I suppose :P but if they're taking 30/60 seconds, that's baaddd 17:19:00 yup 17:19:17 Yea, but there also out of the "critical path" for end user inteactions 17:19:26 i suppose we just need to generate a big ass zone and see how long it takes 17:19:34 we could be worried about nothing 17:19:43 e.g. locking up a mDNS to serve that 5 million RRSet zone won't affect the API responsivness etc 17:19:50 Agreed. 17:20:08 I could test it out and see what it looks like. 17:20:27 But if that's not a possibility (doing it sync), do we have any ideas for doing it async? 17:20:35 Big zone files will be well over 1MB 17:20:53 Swift is a possiblity 17:20:57 or if you are ebay tens or hundreds of MB 17:21:20 i think swift is the best idea, with a fall back to memcached ? 17:21:42 but memcached still locks the API actually serving the data 17:21:42 timsim: So .. Let's say we do this.. create an export resource, during the create, it sends a message over to zone-manager to have it, in the background, pull the zone, render, and save *somewhere* 17:21:46 but less than rendering 17:22:42 once it's done, status moves to COMPLETE or similar, and the user is supplied with a URL to fetch from.. That could be a proxy though our API, or a swift time boxed URL etc? 17:22:47 the problem is the API, and how we show it, and the location to d/l from 17:23:58 thoughts? 17:24:08 so, create a swift bucket with the user credentials, and upload it there? 17:24:14 I don't see a problem with that. 17:24:21 whatever the soplution, we have to have ACLs on it 17:24:25 If you've got a configurable "storage" for that. 17:24:34 mugsie: well, that's another option.. 17:25:00 I'm guessing our folks wouldn't want to have things go to swift. 17:25:19 Yea, we shouldn't add a hard dep on swift 17:26:00 But, imposing some limits if swift isn't enabled (like zones over 1MB once rendered will be an expected failure 17:26:09 seems OK to me.. thoughts? 17:26:19 nope. (the expoected failure) 17:26:37 So - What's the alternative? 17:27:05 and I am guessing it wont fit with what jmcbride will want either ... 17:27:14 You ought to be able to get something bigger than 1MB through mq/http right? 17:27:32 timsim: as I said at the beginning - I have no idea 17:27:37 we could be fine :)( 17:27:44 Well, I'm mostly interested in making sure the API interactions are "correct" and can handle stupidly large zones 17:27:45 all they way up to 100's of MB 17:28:03 Right, as long as that limit is configurable, I don't see an issue. 17:28:23 So - If the No Swift? solution is, auto move to "COMPLETE" and do the render "live" as part of the "fetch exported zonefile" call, that works too 17:28:48 but, we should test the sync load. and circle back 17:28:59 But, if the no swift solution is everything happens in 1 call, sync, then I don't like that :) 17:29:10 the import was really bad, due to the multiple calls per record from API -> Central 17:29:32 The no swift solution would be, go and put it in something else (some other storage) and go and retrieve via the API, I think 17:29:42 mugsie: Yea, we should test.. But.. 99% sure there is always going to be zones that are just too large to render sync .. 17:30:06 We can action me/some racker to test that. 17:30:21 some racker .... :) 17:30:26 #action timsim test out rendering times for stupidly large zones 17:30:30 ;) 17:30:35 * mugsie sees timsim wants to handout work :P 17:30:50 * timsim has other things he has to do :( 17:30:57 I really want to try that though. 17:31:18 everyone knows that feeling! 17:31:41 Okay - Shall we table this till next week? or just whenever during the week in #openstack-dns? 17:31:52 Fer sure 17:31:57 K 17:32:00 Moving on so :) 17:32:07 #topic Python 3 (kiall) 17:32:20 So - This really just a general call to make sure you know about it ;) 17:32:39 pksingh has been spending piles of time getting things up-to-par to run on Python 3.. 17:33:00 The client (bindings) seem good to go.. and Designate itself is "real close" .. 17:33:31 If we can pay attention during reviews, trying to avoid adding py3 incompatible stuff while we wait to get a gate going, that would help :) 17:33:32 Nice! 17:33:52 (I know I'm guiltey of several reviews adding back problems pksingh already fixed..) 17:34:00 guilty* 17:34:39 Anyway - Just a call to "keep your eyes out" and pay attention to the py3 reviews to know what sort of things to -1 (or just to not write in the first place) 17:34:52 Any Q's before we move on? 17:35:09 Nope :) 17:35:12 also, when revieing py3 code - 17:35:13 (pk is based in .. ehh.. ages away, he's usually online EU morning for an hour or two, so he's not here now!) 17:35:23 Japan maybe?> 17:35:34 remeber that not all people seem to agree on str(e) == e.message 17:35:43 (i have been bitten a few times by that) 17:36:00 (for exceptions_ 17:36:02 )* 17:36:21 Yea, handling of those sort of things has got much harder to do "right" :( 17:36:48 Any code that relies on a exception message should be avoided if at all possible, or heavily tested! 17:36:52 ++ 17:37:01 Okay.. Moving on so .. 17:37:07 #topic Open Discussion 17:37:14 Anyone else have anything else? 17:37:40 Nope 17:37:46 Wanted to check in on https://review.openstack.org/#/c/133676/ (jmcbride is thirsty for it) 17:37:55 (V2 CLI support) 17:38:11 timsim: ah, right.. ekarlso - about? 17:38:48 Guess not! It's 7:30pm for him :) 17:39:06 I think he was here earlier... 17:39:30 I'll ask ekarlso to give it a refresh this week, I still wonder if it needs to land in the openstackclient repo rather than ours though :) 17:39:57 Sounds good. 17:40:20 https://review.openstack.org/#/c/142218/ - small review, that will allow logs to be improved as we go on 17:40:24 I'mn lurking.. 17:40:26 :P 17:40:28 what ? 17:40:36 will see if dtroyer is about tomorrow to see if py-osc repo is the right place or not 17:40:46 ekarlso: not lurking very well 17:40:48 :D 17:40:54 :p 17:41:18 mugsie: oh, you updated that? 17:41:46 mugsie: ++, will review tomorrow. Let's not let it die again ;) 17:42:13 I have a coupe ancient reviews that are somehow not in need of rebase. https://review.openstack.org/#/c/170612/ https://review.openstack.org/#/c/188189/ 17:42:41 wow - that is impressive that they don't need a rebase 17:43:09 #link https://review.openstack.org/#/c/142218/ 17:43:09 #link https://review.openstack.org/#/c/170612/ 17:43:09 #link https://review.openstack.org/#/c/188189/ 17:43:19 so they show in the meet overview log for me tomorrow ;) 17:43:38 That's all I've got :) 17:44:02 Okay - Anything else before we call it a day? 17:44:10 Nope 17:44:34 Okay - Thanks folks, have the remaining 15 mins off ;) 17:44:43 o/ 17:44:45 o/ 17:44:45 #endmeeting