17:02:26 <mugsie> #startmeeting Designate
17:02:26 <openstack> Meeting started Wed Nov 26 17:02:26 2014 UTC and is due to finish in 60 minutes.  The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:30 <openstack> The meeting name has been set to 'designate'
17:02:41 <mugsie> whos here?
17:02:42 <betsy> \o
17:02:45 <vinod> o/
17:02:46 <rjrjr> o/
17:02:46 <timsim> o/
17:02:47 <ekarlso-> i'm here :)
17:02:53 <johnbelamaric> hello
17:03:00 <Anand_> Anand from ebay/PayPal
17:03:08 <mugsie> cool
17:03:13 <jmcbride> o/
17:03:14 <pk_> prabhakhar from Anand's team
17:03:22 <mugsie> Kiall is stuck in another meeting, he should be along soon
17:03:36 <mugsie> #topci Action Items from last week
17:03:54 <mugsie> #topic Action Items from last week
17:03:56 <mugsie> all - check and confirm dates above
17:04:16 <mugsie> I think we can push this down a bit until Kiall can join
17:04:23 <Kiall> Heya
17:04:33 <mugsie> oh
17:04:48 <mugsie> ok, did everyone get to check the dates?
17:04:51 <Kiall> We've got a green light from HP, not sure exactly who yet, but we'll make it
17:05:22 <rjrjr> 01/19 - 01/22
17:05:22 <mugsie> (for the mid cycle)
17:05:32 <jmcbride> From Rackspace, the dates are OK, I just need to get approval on the funding.
17:05:41 <rjrjr> M - Th
17:06:05 <Kiall> jmcbride: any idea when you might have a yay or nay? :)
17:06:38 <jmcbride> It might be challenging for me to lock down within the next 2 weeks.
17:07:11 <Kiall> kk..
17:07:17 <jmcbride> Worse case (absolute worse) would be that we are only able to send 1 or 2 people (or we just attend remotely).
17:07:21 <mugsie> ok, so shall we call this as our confirmed mid cycle dates / location then ? I assume the funding issue will take time no matter where or when
17:07:32 <rjrjr> joe: think you can let us know by 12/10?
17:07:35 <jmcbride> mugsie: I'm good with that.
17:07:44 <mugsie> mon 19 - > thurs 21 in Pheonix.
17:08:05 <mugsie> ok. Great to have this done so soon.
17:08:14 <Kiall> :)
17:08:16 <rjrjr> i'll send out a formal invite with location information by Friday.
17:08:27 <mugsie> cool
17:08:37 <mugsie> when that is in I will put iot on the wiki
17:08:42 <Anand_> Ron, I will wok on the budget for the event. no worries
17:09:00 <mugsie> #topic Pools - Where are we? (kiall)
17:09:06 <mugsie> so, any updates for this?
17:09:15 <rjrjr> i pushed code friday and today.
17:09:33 <mugsie> rjrjr: I saw. Will look today / tomrrow morning hopefully
17:09:40 <rjrjr> fixing a few bugs with mdns and adding a 'delay'.
17:09:49 <mugsie> anything blocking anyone?
17:09:59 <betsy> Not for me
17:10:01 <rjrjr> have a few bugs with central, but they shouldn't hold up a review of the code.
17:10:07 <mugsie> k
17:10:15 <mugsie> anyother issues with pools?
17:10:17 <Kiall> rjrjr: I had a quick look an hour or so ago, it looks like were very nearly there.. If it merged as is, would you be upset? (i.e. should I give it a full review in the morning? :))
17:10:35 <rjrjr> kiall: that would be idea! 8^)
17:10:38 <Kiall> KK..
17:10:54 <mugsie> #topic Mid-Cycle Dates/Locations/Topics (kiall)
17:11:00 <mugsie> i think we can call this done ;)
17:11:02 <Kiall> I think we can skit this one ;)
17:11:04 <Kiall> sjip*
17:11:06 <Kiall> skip*
17:11:07 <Kiall> -_-
17:11:13 <mugsie> #topic Record Deletion/Recreation on a PUT - 2014-11-13T17:55:10 at http://bit.ly/1vxa6u3 (timsim)
17:11:17 <timsim> So we discovered in the course of some SQL testing, it seems that when you modify a recordset with multiple records, it deletes and recreates them. We talked about it in the IRC in that link there, I just wanted to circle back and make sure this is tracked :)
17:11:21 <mugsie> timsim: you have the floor
17:11:53 <Kiall> timsim: Have you looked into a possible fix?
17:12:20 <rjrjr> timsim: did you open a bug for it?
17:12:26 <mugsie> best fix (in my mind) JSON+Patch.
17:12:26 <Kiall> We do handle this in the storage layer, but the way the API layer works effectively breaks it and causes a full delete/create for all the records
17:12:50 <timsim> I haven't, I seem to remember you saying there was something needed at the API level, but I that's the extent of it. I just wanted to make sure we don't forget about it. I added this item to make sure we're agreed there's a bug, and I'd file a bug for it.
17:12:54 <mugsie> can we look at a way to do _obj_changed in the API layer?
17:13:06 <mugsie> I think that is definitly a bufg
17:13:08 <vinod> Complete disclosure: I borrowed the same piece of code for pool attributes - so pool attributes too has the same issue
17:13:09 <mugsie> bug*
17:13:10 <betsy> Also, wanted to add that vinod based the pool_attribute code on this, so they are treated in the same way — ie, any updated causes them to be deleted and recreated
17:13:11 <Kiall> mugsie: Well, the issue is we build "new" Record objects in the API layer
17:13:34 <Kiall> those don't have the "id" field, so the storage layer doesn't correlate the existing rows with the "new" Record objects
17:13:36 <betsy> ah - I was too slow
17:14:03 <Kiall> betsy: Dooh, sounds like my dodgy code is spreading ;)
17:14:08 <mugsie> :)
17:14:15 <timsim> So if we all agree (it seems like it) I'll file a bug, and we can talk more about it later.
17:14:16 <mugsie> ok, i think we are agreed
17:14:25 <timsim> Action me :P
17:14:25 <rjrjr> agree
17:14:26 <Kiall> #action kiall to file bug for delete/recreated issues
17:14:27 <mugsie> #action timsim file bug for PUT behavior in the API
17:14:31 <Kiall> lol
17:14:32 <timsim> hah.
17:14:36 <Kiall> timsim: you win ;)
17:14:48 <mugsie> #topic Totalcount metadata field, how/if to deal with the second query(timsim)
17:14:53 <mugsie> timsim again ;)
17:14:58 <timsim> mugsie and I talked about this yesterday
17:15:09 <timsim> Basically, the totalcount relies on the number of objects returned from storage
17:15:17 <timsim> and when you paginate, that number is not the *total* count.
17:15:25 <timsim> So there's going to need to be a second query.
17:16:02 <timsim> The discussion needed is a. Is that worth it? b. Where should the query happen (completely separate call to storage, somewhere in the SQLA plugin for building list objects) c. Should it be default behavior
17:16:28 <mugsie> a - yes b - in SQLA, c - yes
17:16:39 <mugsie> (IMHO)
17:16:44 <mugsie> :)
17:16:46 <betsy> mugsie: +1
17:16:49 <mugsie> any other thoughts?
17:16:49 <timsim> Personally, I'm of the opinion that a. Yes b. Separate call. c. configurable to the operator (or user) but I could be swayed easily :P
17:16:50 <Kiall> mugsie: +1
17:17:01 <Kiall> So - we could update the storage later to do both upon fetching, and attach the total_count to the *List objects
17:17:15 <mugsie> Kiall: yeah, thats what i think is best
17:17:17 <Kiall> I had a mockup of that I sent to jaycaz back when he first started that patch
17:17:19 <timsim> If we want to do all list objects, might as well.
17:17:22 <Kiall> I wonder if I can still find it
17:17:30 <timsim> Kiall: that'd be nice.
17:17:33 <vinod> Kiall: +1
17:17:33 <mugsie> timsim: yeah, i think that could be useful for listed objects
17:17:38 <timsim> Easy enough.
17:17:48 <mugsie> #action: Kiall give timsim mockup code
17:17:53 <timsim> Do we want it to be default, non-turn-offable behavior?
17:17:55 <mugsie> #action: Kiall give timsim mockup code for totalcount
17:18:00 <vinod> default
17:18:10 <Kiall> Not sure "#action:" works mugsie ;)
17:18:11 <timsim> With really large datasets, that might add time to API requests.
17:18:21 <mugsie> I woudld err on the side of default
17:18:24 <mugsie> #action Kiall give timsim mockup code for totalcount
17:18:40 <mugsie> just to make sure
17:18:53 <Kiall> vinod: so, with LARGE datasets, I think MySQL "solves" that by giving estimated numbers back..
17:19:31 <timsim> It also caches that value pretty effectively, so subsequent queries in a given timeframe are much faster.
17:19:49 <timsim> I'm fine with it being default behavior, if it becomes a problem, we can address it later.
17:19:58 <timsim> We can move on :)
17:19:59 <mugsie> ok. are we agreed then? a: we want it, b: SQLA Should do it, c: default, non removable funcxtionality
17:20:05 <mugsie> cool
17:20:09 <mugsie> #topic mdns poll_for_serial_number and notify_zone_changed - do we need a delay parameter? (ron)
17:20:17 <mugsie> rjrjr: the floor is yuours
17:20:40 <rjrjr> vinod and i discussed this an hour back on chat.  i'll add a delay and push it with the next code push for pool manager.
17:21:06 <rjrjr> so, we can move on. 8^)
17:21:09 <mugsie> sweet. any dissent?
17:21:14 <mugsie> if not..
17:21:23 <Kiall> Happy to move on if they have a solution :)
17:21:25 <mugsie> #topic Status of Designate Horizon GUI (ron/prabhakhar)
17:21:38 <rjrjr> pk is on as well as anand.
17:21:50 <mugsie> this is kinda me / rjrjr / Anand_
17:22:08 <Kiall> So.. We have a Horizon dashboard at HP, and even approval to OpenSource it, but getting a home for it has proved difficult :)
17:22:15 <mugsie> ok, we have a panel set, and we need to push out
17:22:20 <Anand_> Hi All, I have Prabhakhara dedicated to work on Horizon GUI for designate
17:22:29 <mugsie> I am going to suggest we create stackforge.designate-dashboard
17:22:35 <mugsie> stackforge/
17:22:42 <Kiall> Anand_: Interesting.. We really should push the one we have out so we're not re-inventing the week
17:22:45 <Kiall> wheel*
17:23:04 <mugsie> unless there is any dissent I will get that repo in the works tonight
17:23:05 <Anand_> Ron mentioned me that HP is already working on it. I would love to colloborate
17:23:22 <rjrjr> kiall, we want to evaluate the HP donated code and enhance it with the community's input.
17:23:28 <Kiall> rjrjr: absolutly :)
17:23:28 <mugsie> rjrjr: cool
17:23:30 <timsim> Seems like a stackforge repo would be a lovely place for it.
17:23:35 <Anand_> Please let me know if we could push the baseline code to stackforge and Prabhakhar could start from there
17:23:37 <Kiall> The code we haven't isn't amazing ;)
17:23:56 <mugsie> so, can we say we are agreed on stackforge/designate-dashboard for the timebeing
17:24:02 <Anand_> that's ok. we could make it better and fill the gaps
17:24:02 <rjrjr> agree on stackforge
17:24:03 <Kiall> mugsie: Maybe
17:24:17 <Kiall> The TC want us to put it in contrib/horizon
17:24:22 <Kiall> (in the designate repo)
17:24:29 <Anand_> In fact, Ron created a nice DNS Management app for PayPal
17:24:34 <Kiall> The reasoning was to avoid repos which won't last very long
17:24:36 <mugsie> and i think that is a terrible idea. they objectsed to the openstack/ repo
17:24:45 <Kiall> The objected to the short-lived repo
17:24:49 <Anand_> all PayPal Ops team and Product dev team are usign this today
17:24:50 <Kiall> Which still happens in stackforge/
17:25:05 <Anand_> for managing DNS infra for critical PayPal business
17:25:09 <mugsie> ok then. do we want to push the code into contrib then?
17:25:17 <mugsie> we need to decide.
17:25:19 <Kiall> mugsie: FYI - I also think contrib/horizon is a terrible idea, but it's what we've been asked to *at least try make work*
17:25:36 <Anand_> if we all agree, I could have Ron to demo the GUI and if everyone likes, we could start the GUI design from that point
17:25:42 <rjrjr> what are the drawbacks to contrib/horizon?
17:25:46 <timsim> It can probably work for the short term, someone can talk to the TC if/when there are difficulties?
17:25:55 <Kiall> rjrjr: reusing any of the Jenkins jobs for testing UI pieces
17:26:09 <Kiall> timsim: yes, I can if it proves too awkward.
17:26:20 <mugsie> potentially having the main project blocked when horizon chnages something
17:26:26 <mugsie> and breaks the tests
17:26:44 <rjrjr> mugsie: that would be extremely annoying.
17:26:47 <mugsie> yup
17:26:51 <Kiall> Yea, another issue.. non-voting can "solve" that if we respect the failures rather than ignoring them
17:26:54 <Anand_> unfortunately, we need to write OpenStack GUI in Horizon. is it true for all projects?
17:27:12 <Anand_> or pick & choose
17:27:13 <Kiall> Anand_: Yes, Horizon is the official UI framework
17:27:13 <mugsie> Anand_: nope. the TC decided (again) the make things different for us
17:27:18 <rjrjr> how do other projects do this?
17:27:24 <Kiall> rjrjr: another repo
17:27:25 <Kiall> -_-
17:27:29 <mugsie> they have *-dashboard
17:27:32 <timsim> ......
17:27:40 <rjrjr> and they objected to us doing the same?
17:27:44 <Anand_> Kiall: Is HP code built on top of Horizon FW?
17:27:45 <rjrjr> frustrating...
17:27:51 <mugsie> tbh, the TC should have no input, as we are a program, with full control over our own repos
17:27:53 <Kiall> Anyway, Let's try the contrib/horizon see if it works, and if not, push for openstack/designate-dashboard again
17:28:13 <mugsie> #action mugsie push horzion code upstream
17:28:24 <mugsie> anything else on this?
17:28:25 <Kiall> mugsie: can you do a quick dump of the code after this meet?
17:28:27 <rjrjr> appreciate it guys!
17:28:27 <Anand_> mugsie: Thanks
17:28:36 <mugsie> Kiall: see actionm ;)
17:28:38 <Kiall> (Ideally, getting it into the DevStack VM too so people can try it)
17:28:48 <mugsie> #topic Open Discussion
17:28:56 <Anand_> pk_: please co-ordinate with mugsie
17:28:58 <mugsie> anyone have anything else?
17:29:03 <pk_> sure
17:29:14 <rjrjr> what is december 8th date?
17:29:25 <timsim> I'd love to have an eye or two on http://docs-draft.openstack.org/30/131530/3/check/gate-designate-specs-docs/e0ad530/doc/build/html/specs/kilo/new-agent.html if anyone had a the time :)
17:29:28 <Anand_> Ron, do you have emails or contact number(s) for mugsie
17:29:28 <rjrjr> sorry, december 8th is looming, what needs to be done by then?
17:29:31 <Anand_> ?
17:29:39 <mugsie> pk_: I will give you a ping after this
17:29:42 <rjrjr> anand: i do.
17:29:44 <pk_> sure
17:29:46 <Kiall> rjrjr: maybe you mean dec 18th?
17:29:49 <Kiall> Thats kilo-1
17:29:52 <Anand_> rjrjr: thx
17:29:54 <Kiall> #link https://wiki.openstack.org/wiki/Kilo_Release_Schedule
17:29:59 <rjrjr> okay, december 18th.
17:30:10 <rjrjr> LOL - been working toward december 8th.
17:30:14 <mugsie> :)
17:30:30 <Kiall> timsim: I'll review along with rjrjr's poolmgr stuff in the morning
17:30:33 <rjrjr> what is the expectation with regards to pool manager.
17:30:34 <Kiall> rjrjr: hah :D
17:30:43 <timsim> Kiall: Appreciate it.
17:31:02 <mugsie> I would like to have it working on a single pool by k-1
17:31:04 <Kiall> rjrjr: expectation is it can be used, but might not be the default.. If it falls short, that's still OK
17:31:05 <mugsie> (pools)
17:31:32 <rjrjr> okay.  we will meet that date.  i'd like to be about wrapped up by then myself. 8^)
17:31:38 <mugsie> yup
17:31:42 <mugsie> any thing else?
17:31:54 <Kiall> Yep.. Everyones noticed the rally gate job?
17:32:02 <Kiall> (I may have brought it up before..)
17:32:05 <rjrjr> the job that fails...
17:32:10 <Kiall> Yes.. That one!
17:32:32 <rjrjr> it says it is a non-voting job!
17:32:34 <Kiall> It passes for me locally, but fails in the gate.. I believe it's because my PC is faster than the RAX/HP VMs ;)
17:33:02 <Kiall> Anyway.. Any help figuring our the perf/locking issues causing the fails would be appreciated!
17:33:21 <rjrjr> i might have time this weekend.  i'll let  you know.
17:33:30 <mugsie> cool. anything else before we finish?
17:33:39 <Kiall> Not from me
17:33:43 <timsim> I'm good.
17:33:44 <johnbelamaric> i had a question...
17:33:48 <mugsie> shoot
17:33:59 <johnbelamaric> we (Infoblox) have implemented a driver as we discussed at the summit
17:34:07 <ekarlso-> So, I have a question as well, I need lab rats for v2 client and secondary zones :)
17:34:08 <mugsie> yup
17:34:12 <johnbelamaric> we haven't upstreamed it yet but would like to - so I assume we just need a BP for that?
17:34:31 <mugsie> yeap, that would be the best route
17:34:32 <johnbelamaric> also, there are a lot of changes in Kilo - should we expect any major refactoring to get up to that code leevel
17:35:07 <Kiall> johnbelamaric: Yep, a BP would be good.. Ability to test would be *great*, that way we can know we're not breaking it :)
17:35:10 <rjrjr> johnbeamaric: i'm guessing this is a traditional backend driver?
17:35:11 <mugsie> yes, but it should be doable. there has been alot of code churn though.
17:35:38 <rjrjr> or maybe i'm missing what the driver is...
17:35:41 <johnbelamaric> ok, any pointers would be helpful or we can just start digging in
17:35:44 <johnbelamaric> yes
17:36:10 <mugsie> if you want to put in a bp / spec, you can put code up before anything is approved, and we can help guide you
17:36:20 <Kiall> johnbelamaric: simplest way to create a BP is to create a "stub" on https://blueprints.launchpad.net/designate/
17:36:21 <johnbelamaric> ok, great, that would help a lot
17:36:29 <johnbelamaric> will do
17:36:30 <Kiall> then create the detailed BP itself in the designate-specs repoi
17:36:32 <timsim> johnbelamaric: We're also in #openstack-dns normally if you have questions :)
17:36:34 <mugsie> just mark the review as WIP
17:36:41 <johnbelamaric> k
17:36:44 <Kiall> Something like this: https://github.com/openstack/designate-specs/blob/master/specs/kilo/secondary-zones.rst
17:37:17 <Kiall> Ideally, explaining what Infoblox's product does etc for those than don't know :)
17:37:28 <johnbelamaric> i saw a BP something about "moving PowerDNS backend to MiniDNS" what does that mean exactly? Do new drivers need to integrate with MiniDNS somehow?
17:37:29 <johnbelamaric> ok
17:37:42 <mugsie> and, any problems just shout in #openstack-dns ;)
17:37:54 <johnbelamaric> got it :)
17:38:24 <mugsie> johnbelamaric: yes, ideally. We talked about you replacing the current SQLA storage backend, as you need to t=be the sourdce of truth
17:38:47 <johnbelamaric> mugsie: yes, first BP will just be for a basic backend driver though
17:39:03 <johnbelamaric> mugsie: still need to study the storage-level one
17:39:08 <mugsie> ok :)
17:39:37 <mugsie> if you want to push up what you have we can help though for the basic one
17:39:50 <johnbelamaric> mugsie: great, thanks, we can do that
17:39:54 <mugsie> cool.
17:39:59 <mugsie> ekarlso-: you had a q?
17:40:11 <rjrjr> traditional backend drivers are going to be phased out for pool backend drivers.  but, not immediately.  mini-dns drivers were for testing mini-dns.
17:41:03 <johnbelamaric> rjrjr: ok, so we can move forward with current one and adapt later
17:41:10 <rjrjr> correct.
17:41:13 <johnbelamaric> thanks
17:41:21 <rjrjr> pool backend drivers are even simpler to code.
17:41:28 <rjrjr> <fingers crossed>
17:41:32 <mugsie> :)
17:41:43 <johnbelamaric> rjrjr: great!
17:41:52 <Kiall> rjrjr: well, not for infoblox's case sadly.. (they do some IPAM products, and can't quite fit into that model from memory)
17:42:06 <rjrjr> hence my <fingers crossed>
17:42:10 <mugsie> (hence the replace storage thing)
17:42:11 <Kiall> (I'm basing ^ on conversations from 2 summits ago ;))
17:42:16 <johnbelamaric> ah hah
17:42:38 <johnbelamaric> we'll start with the current driver and see where it goes
17:42:42 <rjrjr> okay, we'll worry about it at the appropriate time.  we should see what johnbelamaric has.
17:42:51 <Kiall> ++
17:42:59 <mugsie> ok. that sounds like a plan. ekarlso- you have the floor
17:43:21 <ekarlso-> I'd like some feedback on the v2 cli and secondary zones
17:43:44 <ekarlso-> https://review.openstack.org/133682 < api code, https://review.openstack.org/133683 central / mdns
17:44:00 <ekarlso-> https://review.openstack.org/133675 < v2 bindings and https://review.openstack.org/133676 < cli
17:44:27 <mugsie> ok,
17:44:28 <ekarlso-> There's a blog post on secondary zones https://cloudistic.net/blog/designate-secondary-zones.html < there and using v2 cli on transfers here: https://cloudistic.net/blog/designate-zone-transfers.html
17:44:52 <ekarlso-> i've added tests to it but some other peeps to test it is always better then oneself :)
17:44:54 <mugsie> #action people review ekarlso- 's secondary zones / v2 API bindings
17:45:18 <ekarlso-> kewl
17:45:24 <mugsie> any other issues / bugs / problems
17:45:25 <mugsie> ?
17:45:42 <rjrjr> i'm good.
17:45:47 <mugsie> ok.
17:45:56 <mugsie> thanks everyone for coming!
17:45:59 <mugsie> #endmeeting