#openstack-meeting-alt log

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