17:00:22 <kiall> #startmeeting Designate
17:00:27 <rkukura> Thanks everyone!
17:00:27 <openstack> Meeting started Wed Mar 12 17:00:22 2014 UTC and is due to finish in 60 minutes.  The chair is kiall. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:31 <openstack> The meeting name has been set to 'designate'
17:00:35 <kiall> Hey Guys - Who's around today?
17:00:37 <eankutse> here
17:00:41 <tsimmons> o/
17:00:47 <kiall> #link https://wiki.openstack.org/wiki/Meetings/Designate agenda
17:01:03 <vinod> here
17:01:27 <kiall> Cool - I believe mugsie is on his way
17:01:31 <kiall> #topic Review action items from last week
17:01:50 <mugsie> o/
17:02:06 <richm> present
17:02:08 <kiall> all to file any remaining known bugs and target anything important to i3 - I believe we managed this, getting a couple of last minute bugs ironed out.. So - Calling it done
17:02:08 <rjrjr__> here
17:02:28 <kiall> Next was: betsy to write up BP for table per record-type change
17:02:43 <kiall> Did you find the time betsy? :)
17:02:49 <eankutse> betsy running late
17:02:50 <tsimmons> She's not here right now…I think she did that though...
17:03:18 <kiall> tsimmons: ok - cool, I didn't notice the BP. Do we have a link handy?
17:03:28 <tsimmons> looking now...
17:04:31 <tsimmons> Well maybe not...
17:04:33 <kiall> A quick look at the wiki+blueprints lists don't show it. No worries, we'll come back next week (or at the end if someone finds it!)
17:04:39 <tsimmons> Alright.
17:04:57 <kiall> Next up, from the previous meet, was MiniDNS - kiall to refresh the spec, split blueprints, and get that POC code together.
17:05:11 <kiall> I'm going to have to apologize again - this still isn't done.
17:05:30 <kiall> Suffice to say HP has been keeping myself / mugsie / ekarlso busier than usual.
17:06:31 <kiall> So - I'll have to look at this again over the weekend, there's literally no chance I'll be able to this week :(
17:07:11 <kiall> And - That was the last un-closed action. Moving on before anyone has time to beat me ;)
17:07:21 <kiall> #topic Icehouse 3 Release
17:07:30 <eankutse> kiall: are we still going to be able to sync up tho?
17:07:36 <eankutse> before the weekend on the POC
17:07:38 <eankutse> ?
17:07:58 <eankutse> the Central-API stub ?
17:08:20 <kiall> eankutse: yes - we can grab an hour somewhere - let me get back to you at the end and we can find a spot that works for both of us!
17:08:30 <eankutse> cool:-)
17:08:45 <kiall> Re i3: A final couple of fixes landed earlier today, has anyone got any final blockers before I `git push` the i3 tag? :)
17:09:21 <kiall> After this, we'll have 1+ RC's before the final Icehouse release.
17:09:37 <vinod> i need to investigate one
17:09:51 <mugsie> there was one issue with postgres and PowerDNS
17:09:53 <vinod> it appears that we can set the id while doing a post
17:10:01 <mugsie> not sure if we should count it as a blocker
17:10:05 <vinod> is this desirable?
17:10:18 <kiall> vinod: Oh - Humm. That's not desirable at all. Only with V2?
17:10:35 <vinod> i tested it out with v2
17:10:40 <vinod> i did not yet try it out with v1
17:11:10 <kiall> vinod: Okay, I'll hold off the tag until tomorrow - Hopefully we can get a fix before then?
17:11:14 <mugsie> #link https://bugs.launchpad.net/designate/+bug/1289444 <- effectivly blocks anyone from using PowerDNS and postgres
17:11:32 <mugsie> should we prioritise that as well?
17:11:36 <vinod> i will work on it right after this meeting
17:11:37 <tsimmons> I tried just now (on v1), got a 400 bad request, but I just changed one of the UUID characters, so it may have been invalid.
17:11:52 <kiall> mugsie: I think we can fix that after i3 - We're not testing the PowerDNS migrations etc against Postgres automatically
17:12:17 <mugsie> ok, cool
17:12:18 <kiall> tsimmons: so long as it was changed to something in [a-f0-9], it would still be valid
17:12:35 <kiall> vinod: is there a Bug # for the issue you found?
17:12:42 <tsimmons> yeah I just changed an "a" to a "b"
17:12:58 <vinod> not yet - i wanted to make sure it was an issue - before filing it
17:13:12 <kiall> Makes sense :)
17:13:16 <vinod> i.e. not just an issue in my environment
17:13:22 <kiall> It's def an issue! Setting the ID is asking for issues
17:13:37 <kiall> Allowing the user to set the ID that is
17:13:50 <mugsie> there is currently 4 other bugs targeted for i3
17:13:53 <mugsie> #link https://launchpad.net/designate/+milestone/icehouse-3
17:14:19 <mugsie> we going to say these are all pushed to RC1?
17:14:25 <kiall> 3 now ;)
17:14:52 <kiall> prev links aren't included at all right now (same as with nova's etc APIs). Pushed to Juno as it's too late for more features!
17:15:15 <vinod> How about bugs #1281837 and #1288190?
17:15:33 <kiall> https://bugs.launchpad.net/designate/+bug/1281837 should technically be pushed too - But it would be an API change (a change it what gets returned). I'd LOVE to get that out before we release v2 into the wild
17:15:47 <kiall> a change in what gets returned*
17:15:48 <mugsie> we can push it to RC1 though
17:16:15 <kiall> mugsie: yea - exactly, even if it's technically a feature addition ;)
17:16:39 <mugsie> 1288190 - has this been confirmed by anyone?
17:16:48 <kiall> and 1288190 is def a bug, but it's a really rarely used feature. So - I don't think it blocks rc3
17:16:53 <kiall> mugsie: I've eyeballed the code, and it's a bug
17:17:14 <mugsie> rc3? or i3?
17:17:24 <kiall> sorry - i3
17:17:29 <mugsie> cool
17:19:04 <mugsie> #link https://blueprints.launchpad.net/designate/+spec/api-version-2
17:19:09 <kiall> Okay - Any others we think need to be addressed in i3?
17:19:13 <mugsie> is ^ in a place to mark as complete?
17:20:00 <kiall> Yea - We have all the required pieces in now, some planned new additions are the only things left which don't break the API conpat
17:20:02 <kiall> compat*
17:20:05 <mugsie> bugs wise, only the one vinod found
17:20:44 <kiall> Okay - So - Just 1 blocking i3 then
17:20:59 <mugsie> yup
17:21:10 <kiall> Moving on then
17:21:27 <kiall> #topic Server Pools (Status, Getting Started) (from tsimmons)
17:21:37 <tsimmons> Basically I wanted to get a feeling for where Server Pools are right now, what the next steps are, and how we can help.
17:22:24 <mugsie> I need to complete the bp (even make them basic high level info)
17:22:33 <mugsie> I am planing on having some time this evening
17:22:51 <mugsie> then whoever is interested, we can split up the work
17:23:01 <kiall> I expect we can get started on actually writing code for it + minidns pretty soon, once i3 is out and the BP's have been refreshed there should be components we can start splitting out
17:23:31 <mugsie> i know Rackspace have some bandwidth coming up...whats the time scales for you guys?
17:24:56 <tsimmons> Depending on how much work is available, we should be able to get some resources on it over the next few weeks. Personally I'm ready to go right now, I think some of the other devs will have some time in the next couple of weeks.
17:26:15 <kiall> tsimmons: cool! I know at HP we're pretty tight on available time right now between a couple of internal things
17:26:32 <kiall> Once those clear up, we should have MUCH more time to actually write code again
17:26:45 <jmcbride> We are particularly interested in pools+miniDNS as it gets us to the robustified Bind deploy.
17:27:08 <eankutse> I am available for miniDNS now
17:27:15 <kiall> jmcbride: Yea - I guessed as much :) I also think they both go hand in hand in terms of dev work
17:27:35 <tsimmons> It's definitely important work that we'd love to be a part of :)
17:27:44 <kiall> I was going to leave this comment for next week's week - but - since we're kinda on it now anyway...
17:27:55 <jmcbride> so getting mugsie's vision in a BP will be the seed we look forward to in knocking it out.
17:27:59 <mugsie> yup
17:28:14 <kiall> I'd like to Juno all about getting BIND9 working 1000x better, Pools, MiniDNS, and virtually nothing else
17:28:44 <kiall> Those are all big chunks of interrelated work that will go a long way towards fixing up lots of our issues!
17:29:03 <eankutse> yep
17:29:05 <tsimmons> We're all for that.
17:29:07 <betsy> agreed
17:29:14 <richm> I'd like to get the IPA backend working by Juno as well
17:29:31 <richm> but I don't think that will affect any of bind9/pools/minidns
17:29:50 <kiall> richm: Depending on how that works, it'll most likely benefit from the same stuff :)
17:29:57 <richm> yes, most likely
17:31:14 <kiall> Okay - Well, mugsie, why don't you try and get the pools BP's updated before Monday? (which is about the soonest I can have my MiniDNS ones ready)
17:31:23 <mugsie> yup
17:31:29 <mugsie> action me on that ;)
17:31:35 <kiall> That leaves 2 days for people to read + comment, and we discussed them at next weeks meet?
17:31:50 <kiall> #action mugsie to refresh Pools BP's before Monday
17:31:56 <eankutse> good goals
17:32:01 <kiall> #action kiall to refresh MiniDNS BP's/Specs before Monday
17:32:10 <jmcbride> mugsie: please don't sacrifice your evenings and any beer drinking time ;)
17:32:29 <mugsie> jmcbride: theres not much chance of that ;)
17:32:35 <kiall> jmcbride: So, don't do it during working hours then? ;)
17:32:44 <betsy> ;)
17:33:11 <kiall> #action add agenda item for Pool/MDNS BP/spec discussions
17:33:54 <kiall> Okay ..
17:33:58 <kiall> #topic Open Discussion
17:34:15 <kiall> eankutse: checking my calendar now.. 2 mins
17:34:20 <eankutse> k
17:34:21 <rjrjr__> still want to talk to you about fixed IP PTRs at some point.
17:34:24 <kiall> anyone have anything else while I'm doing that?
17:34:48 <eankutse> kiall: you can email me
17:34:54 <betsy> I have my updated on the Records table
17:35:00 <kiall> Gah - 9 new emails since the beginning of this meet. Never ending :'(
17:35:17 <betsy> I did make a placeholder blueprint to separate the records table into multiple tables
17:35:29 <betsy> Still trying to meet up with our DBA to ask him questions about it
17:35:37 <betsy> That's all I've got right now
17:36:50 <kiall> eankutse: Sure - I'll email you in the next few mins then
17:37:04 <kiall> betsy: cool - I didn't see anything that sounded like it, what did you call it?
17:37:04 <eankutse> k
17:37:32 <betsy> I think the short name was record-table-change
17:37:45 <betsy> Should have been something like records-table-redesign
17:38:09 <kiall> aha - https://blueprints.launchpad.net/designate/+spec/records-table-change
17:38:41 <betsy> yep. Mostly just a place holder at this time until I meet up with the DBA to discuss in more detail
17:38:56 <kiall> Cool - Hopefully we can figure out if there's a terrible flaw in the plan before next week.. But I expect there won't be ;)
17:39:03 <betsy> Then I'll write up a spec and we can discuss
17:39:14 <kiall> Cool
17:39:33 <tsimmons> Just FYI, it looks like you can set an ID in v1.
17:39:58 <tsimmons> and a created_at and updated_at too.
17:40:05 <kiall> tsimmons: Humm - OK. That's a bug, one that was hopefully introduced not too long ago!
17:40:07 <vinod> and created_at and updated_at fields too depending on the database
17:40:30 <vinod> filing a bug now
17:40:41 <betsy> Yeah. I just verified that bug
17:40:45 <kiall> Could you guys include that in the bug? We'll have to figure out exactly why that's happening.
17:40:48 <betsy> … in v1
17:41:05 <vinod> will do
17:41:11 <kiall> Thanks
17:41:27 <betsy> So it's a bug in v1 and v2
17:41:34 <betsy> Do they need separate bugs or just one bug?
17:41:43 <kiall> 1 should do
17:41:43 <betsy> I'm assuming one
17:42:00 <kiall> betsy: without looking, I would hazard a guess the bug was introduced as part of the V2 additions
17:42:14 <kiall> But.. We'll find out soon enough
17:42:54 <betsy> I don't think I ever thought to test that before
17:43:06 <betsy> But makes sense it was introduced in v2
17:43:25 <kiall> betsy: I'm pretty confident HP has tested for that in the past during security reviews etc.
17:43:43 <betsy> Kiall: Oh, that's right. Y'all are actually running it in production
17:44:04 <kiall> betsy: right - Hence I'll be digging into this the moment we're done ;)
17:44:28 <kiall> Okay - So anyone have any other topics to discuss?
17:44:32 <mugsie> nope
17:44:37 <richm> question about backends - is create_tsigkey/update_tsigkey supposed to do anything other than create/update a TSIG RR?
17:44:38 <tsimmons> Not from me.
17:45:50 <kiall> richm: the TSIG key support today is intended to create the tsig key config (not record) in the backend, and allow that key to AXFR all zones
17:46:25 <kiall> It's primarily there to allow Akamai to AXFR from our PowerDNS instances without leaving it open for anyone to AXFR (or constantly updating IP allow lists)
17:47:01 <kiall> It should be extended to cover off other use cases for TSIG keys, e.g. a user should be able to create a key that allows AXFR of just their zones etc
17:47:56 <rjrjr__> i have code written for https://wiki.openstack.org/wiki/Designate/Blueprints/ReverseFixedIP.  i'm testing it out.  still would like to discuss the implementation.
17:48:41 <kiall> Cool - is it up for review?
17:49:09 <rjrjr__> we looked at it last week.  i'd still like to review the BP and make any changes we want.
17:49:25 <rjrjr__> we were suppose to meet on Friday, but you were busy.
17:49:56 <rjrjr__> would it be better for me to submit the code before the BP is approved?
17:50:04 <kiall> Apologies :( Busy would be an understatement..
17:50:15 <tsimmons> rjrjr__: You could submit it as a WIP
17:50:35 <kiall> Sure - the code can often clear up any questions that might come from the BP anyway :)
17:51:00 <rjrjr__> okay.  is there something i need to put in the comment section to link it to the BP?
17:52:05 <kiall> Was the BP updated recently BTW? Looks different to what I remember looking at last night!
17:53:07 <rjrjr__> yes.  it is more reflective of the implementation.  i went with a call to the Neutron list ports.
17:53:13 <kiall> rjrjr__: in the commit message, include "blueprint fixed-ip-ptrs" and it should link things together
17:53:21 <kiall> (on it's own line at the end)
17:53:54 <tsimmons> rjrjr__: And prefix the commit with "WIP" if you'd like to submit it as a work in progress.
17:54:13 <rjrjr__> originally, i was going to use the Nova API, but i think there is an ORM bug in it that prevents me from getting the VM instance for an IP address.  since the Neutron "plumbing" was in place, i decided to use the list ports call.
17:54:46 <kiall> rjrjr__: I think that's probably the best way anyway, as Nova's network APIs will (eventually) be removed..
17:55:15 <rjrjr__> my concern is not having an ID to key off of.  i'm using the region and address itself.
17:55:32 <rjrjr__> the code will make this clearer. :)
17:55:54 <kiall> rjrjr__: yea, agreed. I'm just unsure how we handle overlapping networks in that case :(
17:56:17 <kiall> Anyway rjrjr__ I know I'll have time to eyeball the change tonight if it's up .. Hopefully others will too
17:56:33 <kiall> 3 mins before the Trove folks arrive with pitchforks, any final topics?
17:56:41 <rjrjr__> well, my testing is promising, so in a couple of hours i'll submit the code for review.
17:56:50 <vinod> Opened bug 1291518 to track the id issue.
17:56:54 <vinod> #link https://bugs.launchpad.net/designate/+bug/1291518
17:57:04 <betsy> rjrjr__:awesome
17:57:20 <kiall> cool :)
17:57:40 <kiall> Okay - Thanks all
17:58:04 <kiall> vinod: I'll ping you in a few re that bug - looking into it now.
17:58:05 <kiall> #endmeeting