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