17:02:31 #startmeeting Designate 17:02:32 Meeting started Wed Oct 15 17:02:31 2014 UTC and is due to finish in 60 minutes. The chair is Kiall. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:33 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:35 The meeting name has been set to 'designate' 17:02:39 Hey folks - Who's about today? 17:02:40 \o 17:02:41 bye 17:02:50 o/ 17:02:52 o/ 17:03:06 o/ 17:03:08 o/ 17:03:11 #topic Action Items from last week 17:04:32 So - 2 actions last week, both around v2 stability and for me - I did a review of the v2 API as it is today, and the only thing that concerned me is the missing validations.. Beyond possible changes for pools, I see no other blockers from calling it stable (stable as in code written today will work against v2 in a year) 17:05:18 Did anyone else give it a once over? 17:05:22 Some of the other v2 usabilty that I had were 17:05:25 previous link 17:05:26 designate client support 17:05:26 server support (until pools) needs v1 17:05:26 Extensions/apis missing (but present in v1) - diagnostics, sync, touch, tsigkeys 17:05:26 schema validation in v2. 17:05:26 update documentation for v2 (counts,reports,tenants,floatingips,limits,nameservers, recordsets) 17:05:48 actually, that is a good point 17:06:01 the pools change will change how the servers end point works 17:06:22 (and that should be implemented before we call it stable) 17:06:34 mugsie: yep, as I said - pools will likely have a change or two ;) 17:06:42 well, would those changes break the api? 17:06:48 yes 17:07:05 The v2 api? 17:07:10 for the admin /servers endpoint - the code writen against it now wont work in a year 17:07:22 if we call an API stable it would need to be feature complete 17:07:25 re previous link, client support, docs - I don't see those as blockers from calling the API stable 17:07:34 (aka no switching between v1 and v2 to do things 17:07:35 mugsie: I disagree.. V2 will grow over time... 17:07:39 Oh 17:07:47 That.. Sure, that does make sense 17:08:14 so, until we merge the pools API layer it will not be... that is the main blocker I see right now 17:08:37 That makes sense, until you can manage servers from the v2 API, it's not stable. 17:08:47 Yep - The two I had were validation and any changes that might come about for the existing resources to make pools work.. 17:09:46 vinod1: re client/docs - I think those are separate from the API stability, but are certainly needed before anyone would want to put it into production :) 17:10:11 ok 17:10:32 how about the missing apis - would that case switching between v1 and v2? 17:10:39 yeah 17:10:49 what APIs are we currently missing 17:10:53 i know servers 17:10:56 vinod1: Yea, I hadn't considered that, and agree.. functions that make sense to port should be ported 17:11:04 Extensions/apis missing (but present in v1) - diagnostics, sync, touch, tsigkeys 17:11:09 ping? 17:11:31 oh, thats in diags i thinks 17:11:33 sync - I don't think that makes much sense in a pools/mDNS world.. 17:12:27 tsigs? 17:12:43 Ah, vinod1 had that. 17:12:44 sync - it might if you want to force a zone to re-sync 17:13:12 mugsie: the only way to do that with mDNS etc is to increment the serial (i.e. "touch") 17:13:26 Yep - tsig's is a requirement for getting pools 100%, but it's changing a little so won't be a 1:1 port 17:13:41 (the notion of tsigkey's being scoped to a set of domains / a pool / a tenant etc) 17:14:54 #action kiall to write each of the missing v2 pieces mentioned into a wiki page, with links to bug # / blueprints for each. 17:15:02 If we find more, we can add them to it 17:15:21 Let's move on, fairly full agenda today 17:15:40 #topic Release Status (recurring) 17:16:08 So - Juno is out tomorrow, if you have any release critical bugs, raise your hand right now! ;) 17:16:36 Assuming none, rc2 will be our Juno release and ttx will cut it for us tomorrow 17:16:49 yay! 17:17:07 :) 17:17:31 So, I'm taking silence as no known last minute issues.. Moving on :) 17:17:58 If you have any, and only if they are truly release critical, ping ttx 17:18:09 (I'm away from now -> Monday) 17:18:10 #topic Launchpad Blueprint Cleanup (kiall) 17:18:53 So, I started trying to cleanup our BP list a few days ago, and mugsie tried again today.. We have lots of stuff in there.. Some of which no longer make sense etc 17:19:11 #link https://blueprints.launchpad.net/designate/+assignments is a good overview 17:19:18 #link https://blueprints.launchpad.net/designate 17:19:31 lol - I've never seen that assignments page 17:20:11 Anyway - Can we spent 2 mins giving them a look over, then make some suggetions for BP's to "Mark as Obsolete" ;) 17:20:22 sounds good 17:20:31 yes 17:22:46 What about https://blueprints.launchpad.net/designate/+spec/recordsets-records-tables-redesign? I’m not sure that will ever get done now that the other code’s been done 17:23:48 betsy: really? I think that one is still going to be valuable to anyone running at scale.. 17:23:59 That’s true 17:24:02 never mind 17:24:02 I think it should happen - we will need to split that DB table out 17:24:09 mine are: 17:24:14 #link https://blueprints.launchpad.net/designate/+spec/ptr-sink-creation 17:24:15 #link https://blueprints.launchpad.net/designate/+spec/second-tier-slave-deploy 17:24:15 #link https://blueprints.launchpad.net/designate/+spec/fixed-ip-ptrs 17:24:15 #link https://blueprints.launchpad.net/designate/+spec/fqdn-name-auto-registration 17:24:15 #link https://blueprints.launchpad.net/designate/+spec/dynamic-dns-update-backend 17:24:15 #link https://blueprints.launchpad.net/designate/+spec/bulk-modify-delete-records 17:24:22 before we get too far down the rabbit hole of discussion though.. Let's just drop the links and what we think should be done here.. then discuss 17:24:59 agreed on https://blueprints.launchpad.net/designate/+spec/fixed-ip-ptrs 17:25:02 https://blueprints.launchpad.net/designate/+spec/plugable-serial-number-format <-- Drop 17:25:02 https://blueprints.launchpad.net/designate/+spec/dynamic-dns-update-backend <-- Drop - mDNS "kinda" covers this, and DNS UPDATE can't create/delete zones 17:25:17 https://blueprints.launchpad.net/designate/+spec/fqdn-name-auto-registration and https://blueprints.launchpad.net/designate/+spec/ptr-sink-creation <-- Combine into "Make sink useful out of the box" 17:25:58 i think the 2 sink ones will be better done via the neutron integration 17:26:07 https://blueprints.launchpad.net/designate/+spec/mdns-designate-mdns-region-awareness could probably be accomplished outside of minidns 17:26:41 Anyone else have more coming before we go through ^? :) 17:27:24 I'm good 17:27:30 vinod1? timsim ? richm ? 17:27:47 no 17:27:48 I'm good. 17:28:05 Okay.. Let's start at the top so .. 17:28:33 https://blueprints.launchpad.net/designate/+spec/ptr-sink-creation and https://blueprints.launchpad.net/designate/+spec/fqdn-name-auto-registration 17:29:01 Both are sink related tasks, I think we merge them.. mugsie things we drop them... Anyone have opinions either way? 17:29:07 thinks* 17:29:19 Are these things manageable with a custom handler? 17:29:34 timsim: yes, I believe they are.. 17:29:47 Kiall, the fqdn one is not sink related 17:29:57 i think users are looking for an example that includes PTRs. 17:30:02 ah it is 17:30:05 just at the bottom 17:30:29 but, I dont like the idea of doing the fqdn one in any case 17:30:36 I say we drop them for now and if they come back up later, we add them 17:30:45 especially with sub / super domain stuff that we have now 17:30:50 betsy, +1 17:30:55 mugsie: with neutron integration happening at some point, I think I agree on that one. 17:31:01 I think it'd be good to have an example for people to use so that they didn't have to write it themselves. But I'd think the first person to write this type of thing would contribute it back and it'd be there. I don't think they're valid BPs really. 17:31:12 i think a bug for "sink examples are bad" would be better 17:31:21 mugsie: +1 17:31:36 Sounds like consensus is drop the BPs, file a bug? 17:31:50 Sounds good to me. 17:31:53 agreed 17:31:54 +1 17:31:54 bug would expand what do today in the samples to include examples for PTR etc 17:31:54 sure. 17:32:02 Okay 17:32:32 Next one from mugsie was https://blueprints.launchpad.net/designate/+spec/second-tier-slave-deploy .. 17:33:13 we can't really do this, based on most dns servers not being able to be a master and a slave 17:33:21 agreed. 17:33:30 so, with mdns being master, 2nd tier is out 17:33:32 mugsie: yea, I've never seen one that can do that.. (I could be wrong..) 17:33:42 turns out MS DNS can 17:33:48 lol 17:33:53 but, thats a whole different can of worms 17:33:59 :) 17:34:00 Okay - consensus is drop? 17:34:03 holdup 17:34:08 (things can always be filed again) 17:34:29 timsim: holding ;) 17:34:47 If it was something someone wanted, this would probably be done in the form of a pool manager and some custom code. 17:34:59 That being said, there probably doesn't need to be a BP done for it :) 17:35:06 Yet, anyway. 17:35:20 yeah - i dont think it is something that we should worry about for the time being 17:35:31 I think the said bp is obsolete 17:35:39 timsim: This was a BP filed by Joe in Feb - I'm think that pre-dates mDNS, and I'm not sure it makes much sense anymore (I could easily be wrong!) 17:36:34 Fair enough 17:36:55 kill it with fire 17:36:59 ;) 17:37:27 next .. https://blueprints.launchpad.net/designate/+spec/fixed-ip-ptrs 17:37:39 (let's try get through these quicker ;)) 17:37:59 we don't need it anymore. have another solution instead. 17:38:01 Thoughts? I see neutron integration as likely obsoleting the current purpose build PTR apis 17:38:10 Also.. ^ v2 API gap. 17:38:34 Anyone object? Will move on otherwise 17:38:46 No objections here. 17:38:48 nope 17:38:53 https://blueprints.launchpad.net/designate/+spec/dynamic-dns-update-backend 17:39:05 I think mDNS solve the spirit of ^ 17:39:07 solves* 17:39:17 yup - I say close alright 17:39:32 close 17:39:33 And - DNS UPDATE limitations prevent it being useful with mDNS / Pools anyway 17:39:46 Going once... Twice... 17:40:02 Next .. https://blueprints.launchpad.net/designate/+spec/bulk-modify-delete-records 17:40:12 is there a BP to handle using nsupdate? 17:40:23 with mdns? 17:40:45 Within one RRset you can do this now right? But not between multiple RRsets? 17:40:48 I think there's really 2 parts to ^ .. 1) Updating of records in a single RRSet - Solved with V2, and 2) Updating a whole slew of records cross different recordsets in 1 call, not solved by V2 17:40:53 rjrjr_, yeah - somewhere 17:40:56 timsim: correct 17:41:09 timsim, i added this as there is https://blueprints.launchpad.net/designate/+spec/bulk-resource-change-transaction 17:41:37 Yeah I'm good with moving the second part of that work over to the bp mugsie linked. 17:41:44 I think what we implent for all resources should work for records 17:41:48 mugsie: that one makes the first one obsolete then 17:41:54 yep. So close this one 17:42:07 Okay - So - bulk-modify-delete-records get's the close? going once.... 17:42:27 Gone.. Next was https://blueprints.launchpad.net/designate/+spec/plugable-serial-number-format 17:42:34 I have to admit, I've never undersood this one ;) 17:42:40 understood* 17:42:50 What other type would you want to use? 17:43:22 and why 17:43:31 But - From memory, we're relying on the serial number patterns and in pools, plus handling more than 99 updates a minute make "the other format" (date based) difficult 17:43:41 we're relying on the serial number patterns in pools* 17:44:11 mugsie is probably furiously typing. 17:44:37 nope - I can see the appeal, but we cant do it with pools 17:44:45 vinod1 / betsy / timsim - I think this one came from rackspace - I'm not sure if it was a "needed" or "would be cool if" BP? 17:45:06 (Joe filed too many BPs on behalf of others, hard to know which ones are from you guys or not ;)) 17:45:16 I remember the discussion early on, but can’t recall the details 17:45:18 I've never heard of it, or see the reason. I mean it'd be kind of cute, but I don't see a reason for it. Close. 17:45:22 ort 17:45:23 Silly joe. 17:45:23 oh* 17:45:27 mugsie: filed this one 17:45:37 So - Agreed on kill? 17:45:40 Kiall: That's why I thought he'd defend it, lol 17:45:44 I think it did come from a discussion Rackspace brought up, tho 17:46:00 it did 17:46:09 i say close 17:46:15 jbratton? 17:46:18 betsy: want to hold off on it so until you guys chat with joe etc? 17:46:25 kiall: ok 17:46:29 Yeah we can go figure it out 17:46:31 We’ll double check 17:46:47 Okay.. last one was from timsim https://blueprints.launchpad.net/designate/+spec/mdns-designate-mdns-region-awareness 17:47:02 timsim: we need serial numbers in epoch format to handle updates of more than 100/hour 17:47:17 that's our only requirement with respect to serial numbers 17:47:24 jbratton: yea, that's my big thing with it too :) 17:47:36 I swear, you summon that guy and he'll always appear. So you can close that bp Kiall. 17:47:43 So can we handle more than 100/hour now? 17:47:46 Okay.. Done 17:47:50 betsy: yes, using epoch we can 17:47:55 timsim: it's magic :) 17:48:27 re https://blueprints.launchpad.net/designate/+spec/mdns-designate-mdns-region-awareness - timsim any reason you say close? 17:48:29 So for the region awareness, would this not be done by configuring minidns' slaves to just the ones in whatever region you wanted, and making sure minidns only got the messages for that region? 17:48:37 (I know jbratton will argue against you :P) 17:49:05 I reckon it's basically a config option that would already work. 17:49:53 timsim: ah, so you're arguing it just becomes a piece of pools to work out as against it's own BP? 17:50:01 That makes more sense than dropping it ;) 17:50:05 yeah - that sounds right to me 17:50:07 Yep. 17:50:18 I think you basically get that for free. 17:50:31 Okay - I think we leave it for today, since we have 10 mins left and more topics ;) 17:51:00 cool 17:51:08 #topic Paris designate session - preparations AND Things to talk about in Paris (Combined for the sake of time ;)) 17:51:47 First up - we have 3x 40 minute design session slots early in the week, and either a half or full day "contributers session" towards the end of the week 17:51:58 Plus the talk a few of you are giving ;) 17:52:37 Considering we have like 6 mins left, I suggest we leave the sessions as homework to get suggestions together. 17:52:56 vinod1: you had something on the talk? 17:53:13 No just wanted to get some discussions started on this 17:53:27 Did we want to do a hangout to chat about the talk? Practices, topics, recyle last years, etc? 17:53:33 Also for the talk, I assume mugsie was scheduling a hangout 17:53:45 mugsie loves scheduling hangouts ;) 17:54:05 yup, I will email ye in a few mins to get a time together 17:54:23 Okay - Let's continue ^ in email so.. Moving on very very quickly ;) 17:54:24 #topic Some clarifications on server pools 17:54:27 vinod1: over to you 17:54:54 name servers in storage for v2 - would this go as pool attributes - format - list, dict or should each name server be in a separate item? 17:54:54 pool_servers in storage in v2 - would each server be 17:54:54 if name_servers and pool_servers go into the pool_atrributes, should the api also be modified to specify them as pool_attributes? 17:55:31 1st item name servers in storage for v2 - would this go as pool attributes - format - list, dict or should each name server be in a separate item? 17:55:57 they would be a separate line in the attrib table 17:56:21 the powerdns "domainmetadata" is effectively ^, and it seems to work pretty well.. 17:56:41 I think we should keep the API as is, and translate them - it seems a better UX 17:57:10 they are required items, and i think they warrant a item in the pools object 17:57:13 by a separate line, do you mean each nameserver gets a separate entry - so it they are 3 name servers in a given pool - that would be 3 entries? 17:57:18 yup 17:57:19 mugsie: Yea, API they just form a list .. in the DB we have to either store CSV/JSON/or a row for each.. I'd love to avoid CSV/JSON in our DB 17:58:23 Makes sense to have a row for each imo. 17:58:58 Would it be the same for pool_servers too? 17:59:01 yup 17:59:25 pool servers would I think want it own table? 17:59:39 (there's lots of details to store about those.. unless I'm getting mixed up) 17:59:46 servers are in the config file. 18:00:03 rjrjr_, yup 18:00:06 you are right 18:00:13 I was thinking of the old design 18:00:21 so what is the point of having the pool_servers in the api? 18:00:23 Times up folks, Let's finish this in #openstack-dns.. and.. yep.. rjrjr_ is right! 18:00:24 excuse me ... trove meeting time. 18:00:28 we dont store servers in the DB at all 18:00:35 Thanks all.. 18:00:36 #endmeeting