17:00:11 <Kiall> #startmeeting designate
17:00:12 <openstack> Meeting started Wed May 21 17:00:11 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:13 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:16 <openstack> The meeting name has been set to 'designate'
17:00:25 <Kiall> Hey guys - Who's about?
17:00:28 <rjrjr_> here
17:00:40 <vinod2> here
17:00:41 <eankutse> here
17:01:13 <Kiall> Cool - and I know mugsie will be here in 2 mins
17:01:22 <Kiall> Ah.. there he is ;)
17:01:29 <mugsie> o/
17:01:36 <hvprash> hi, this is my first meeting and new to the project
17:01:48 <bbaby> me too.
17:01:50 <Kiall> So first off - for those people lurking who were not at the summit, welcome to our new core team member vinod2 :)
17:02:09 <eankutse> congrats vinod!
17:02:10 * mugsie tips his hat to vinod2
17:02:13 <jmcbride> welcome hvprash and bbaby!
17:02:15 <Kiall> Cool! Great to see new faces getting involved, we're you guys at the summit?
17:02:16 <jmcbride> congrats vinod!
17:02:22 <vinod2> Thanks everybody
17:02:23 <hvprash> thx
17:02:36 <betsy> here
17:02:47 <hvprash> me and bbaby work together in comcast
17:03:22 <richm> here
17:03:23 <Kiall> Excellent - I think we met some comcast folks at the summit, but IRC handles often don't map to real life :P
17:03:29 <Kiall> #topic Incubation / Program Docs
17:03:38 <Kiall> mugsie: you're up
17:04:03 <mugsie> cool - we did a fairly in depth run down at the summit
17:04:10 <Kiall> hvprash / bbaby - if you're not already aware, agenda is at https://wiki.openstack.org/wiki/Meetings/Designate and is open to everyone to add items to
17:04:14 <mugsie> #linkhttps://wiki.openstack.org/wiki/Designate/Incubation_Application
17:04:26 <mugsie> #link https://wiki.openstack.org/wiki/Designate/Incubation_Application
17:04:30 <mugsie> #link https://wiki.openstack.org/wiki/Designate/Program_Application
17:04:42 <mugsie> I think we are in a good place to get this done by friday
17:05:00 <mugsie> jmcbride: i saw you we editing the program page - we nearly done there?
17:05:04 <mugsie> were*
17:05:14 <jmcbride> I've sent this around to a couple of folks here at Rackspace…
17:05:23 <betsy> mugsie: awesome
17:05:33 <jmcbride> updating based on feedback from Anne Gentle, Adrian Otto and waiting to hear back from Troy Toman
17:05:56 <mugsie> cool  - we are going to do a run through in HP later today
17:05:57 <jmcbride> and Michael Still
17:06:06 <Kiall> jmcbride: great, mugsie and myself have a meet in about an hour with some of the HP folks we want input from
17:06:15 <jmcbride> sweet.
17:06:19 <Kiall> jmcbride: anything major?
17:06:22 <mugsie> I will email you and we can sync up with times to send the email :)
17:06:35 <jmcbride> not yet. I was hoping to find a way in the wiki to see my changes.
17:06:52 <mugsie> yeah, you can
17:07:06 <mugsie> If you #link https://wiki.openstack.org/w/index.php?title=Designate/Program_Application&action=history
17:07:08 <Kiall> https://wiki.openstack.org/w/index.php?title=Designate%2FProgram_Application&diff=52977&oldid=52714
17:07:40 <jmcbride> cool. I'm looking at #link https://wiki.openstack.org/w/index.php?title=Designate/Program_Application&diff=cur&oldid=52929
17:07:41 <Kiall> Looks like pretty minor edits, perfect :0
17:07:43 <Kiall> :)*
17:08:07 <jmcbride> First thing was Anne asked why not join Networking or Data Processing programs
17:08:08 <mugsie> cool. we call this item done for the time being? unless anyone else has any major objections
17:08:13 <mugsie> ah ^
17:08:14 <Kiall> Okay, so jmcbride - do you expect feedback from the remaining people before Friday is out?
17:08:15 <shakamunyi> hello
17:08:25 <mugsie> yeah, I liked your reasoning why not to
17:08:29 <shakamunyi> here
17:08:30 <Kiall> shakamunyi: heya :) New to designate? Welcome
17:08:37 <jmcbride> I don't know about Troy and Michael yet, but the doc has been updated to reflect others.
17:08:42 <shakamunyi> congrats vinod
17:09:36 <Kiall> Okay - Moving on so
17:09:37 <jmcbride> So I added a "Why a new program?" section
17:09:45 <jmcbride> That was the biggest edit.
17:09:48 <Kiall> #topic Discuss DNSupdate proposal/blueprint
17:10:03 <Kiall> Anyone wanting to take the lead on this one?
17:10:04 <shakamunyi> Kiall this is Alex B
17:10:13 <Kiall> shakamunyi: Oh .. lol.. what a nickname
17:10:18 <shakamunyi> :D
17:10:38 <shakamunyi> few incidents of name clashes with that one :)
17:10:46 <Kiall> richm: you able to table about this topic?
17:10:52 <richm> Kiall: yes
17:11:06 <richm> The problem is that many DNS administrators already use nsupdate
17:11:11 <Kiall> #link https://blueprints.launchpad.net/designate/+spec/dnsupdate
17:11:17 <richm> They want to be able to use nsupdate with designate
17:11:30 <richm> The bp outlines 3 approaches
17:11:54 <richm> 1) provide a tool called "dnsupdate" which works exactly like nsupdate
17:12:13 <richm> 2) change the designate client to have an "--nsupdate" mode which makes it work exactly like nsupdate
17:12:28 <richm> 3) have mini-DNS work with nsupdate
17:12:50 <richm> I think 3) would be the most preferable
17:12:51 <eankutse> Can we start with 3)?
17:12:54 <richm> yes
17:13:06 <eankutse> I don't think we should talk directly to miniDNS
17:13:13 <eankutse> Central will notify minidns
17:13:19 <eankutse> when updates happens
17:13:22 <shakamunyi> thanks richm
17:13:25 <eankutse> and miniDNS will go from there
17:13:28 <Kiall> So - I think 3 is the best option, since it allows the real nsupdate utility to speak with us, and any other code supporting the RFC Dynanic DNS
17:13:36 <Kiall> But.. It's also going to be blocked on mDNS
17:13:47 <rjrjr_> i'm not seeing 3 options in the blueprint, but I like option 3.
17:13:50 <richm> right - so support for 3) may take some time
17:13:51 <eankutse> Kiall: I was actually proposing the opposite
17:13:53 <eankutse> :-)
17:14:10 <betsy> rjrjr_: It’s down at the bottom in the whiteboard section
17:14:13 <Kiall> eankutse: not sure I follow?
17:14:15 <shakamunyi> rjrjr_ it's at the bottom of the whiteboard
17:14:16 <mugsie> I quite like 3 personally - It was one of the reasons that miniDNS was such a good idea
17:14:21 <rjrjr_> gotcha!
17:14:22 <richm> rjrjr_: They are called "Proposal 1, 2, 3" in the bp
17:14:38 <Kiall> Proposal 1 seems like a good compromise, and a good way to identify any gaps we might have
17:14:46 <eankutse> MiniDNS is hidden inside designate
17:14:55 <eankutse> It is activated by Central
17:15:03 <eankutse> So updates go to central
17:15:14 <richm> MiniDNS already "talks" to the outside world
17:15:16 <eankutse> and Central activates (as usual) MiniDNS
17:15:40 <Kiall> eankutse: yes, but once we have all the mDNS code in place, it should be "easy enough" to extend to have a service we can expose to customers that handles dynamic updates
17:15:51 <mugsie> yeah, that is part of the reason that we have the api separate to cnetral, to allow multiple input APIs
17:15:57 <Kiall> It may or may not be the same service as mDNS itself, but I'm betting 90% of the code can be reused
17:16:21 <eankutse> ok. Yes. We are talking about the "extended" miniDNS
17:16:21 <richm> so perhaps mDNS will be split into two parts?
17:16:30 <richm> mDNS XFR agent
17:16:37 <richm> and mDNS nsupdate agent
17:16:38 <rjrjr_> central won't really be central at that point. 8^)
17:16:47 <Kiall> eankutse: yea, it would be an extra that would re-use much of the code, but might be different service etc :)
17:17:08 <betsy> rjrjr_: It’s still authoritative, so why wouldn’t it still be central?
17:17:08 <eankutse> :-)
17:17:54 <Kiall> Anyway - richm RedHat obv has customers etc asking for this, so, IMO, I'd be happy to see #1 done "today" with with #3 done when mDNS is ready.. #1 will ensure we have all the central requirements etc in place to handle this.
17:18:06 <richm> Kiall: ok, sounds good
17:18:12 <shakamunyi> Kiall: I prefer option 3, option 1 as compromise measure
17:18:23 <shakamunyi> Kiall richm: agree
17:18:38 <richm> ok - so two action items for me
17:18:39 <vinod2> With the current server pools and mdns design, on any modifications, central sends an update to the pool manager, which would send a NOTIFY to the backends.  With proposal 3, we need to think about how to send NOTIFY
17:18:58 <mugsie> shakamunyi: when you say compramise - do you mean short term? or if we can't actually implement 3?
17:19:19 <Kiall> vinod2: I don't think we do need to change that, as the code for #3 would send the updates to central,a nd the standard logic for NOTIFY's etc would kick in
17:19:34 <shakamunyi> mugsie: short/near term + identify gaps
17:20:08 <mugsie> cool
17:20:17 <Kiall> BTW folks - for those who don't now .. Alex B / shakamunyi is the HP Cloud DNS dev manage.. jmcbride's counterpart in HP ;)
17:20:38 <shakamunyi> Kiall actually I'm at RH
17:20:43 <Kiall> OHH
17:20:48 <richm> a different Alex B
17:20:49 <rjrjr_> LOL
17:20:51 <Kiall> I though you said Alex B(arclay)
17:20:52 <mugsie> :D
17:20:56 <jmcbride> kiall, so you have a new manager?
17:20:58 <Kiall> I was wondering :D
17:20:59 <jmcbride> ;)
17:20:59 <richm> we have two Alex B's
17:21:04 <shakamunyi> Kiall sorry - Alex Baretto
17:21:07 <shakamunyi> :D
17:21:11 <Kiall> My mistake :D
17:21:15 <richm> We have to Alex Bar's
17:21:17 <richm> two
17:21:19 <shakamunyi> Kiall no worries
17:21:19 <Kiall> lol
17:21:44 <richm> so how do I do the meetingbot #action thing?
17:21:48 <vinod2> Kiall: So with proposal 3, would there be a separate layer (similar to api) that accepts the nsupdate requests and sends them on to central?
17:21:53 <richm> I need to give myself two actions
17:21:57 <Kiall> richm: #action <name> <action>
17:21:57 <mugsie> vinod2: yup
17:22:12 <vinod2> Also with proposals 1 and 2, would the requests go through the current api layer?
17:22:19 <richm> #action richm update dnsupdate blueprint with info from this meeting
17:22:37 <richm> #action richm add minidns blueprint for nsupdate support
17:22:40 <Kiall> vinod2: yes - there would, that layer *might* be the same thing we serve mDNS AXFR's from, but might be a different service sharing lots of code
17:23:01 <shakamunyi> vinod2 for mDNS AXFR
17:23:05 <jmcbride> recap
17:23:40 <Kiall> vinod2: with proposal 1 and 2, the modifications would go through the current API layer I believe
17:23:57 <Kiall> (after any gaps get closed)
17:23:59 <shakamunyi> Kiall vinod2 correct
17:24:22 <mugsie> richm: can you capture ^ in the bp for 1 and 2 ?
17:24:37 <richm> mugsie: yes
17:24:38 <richm> another problem with 1 is that it won't be an exact replacement for nsupdate
17:24:55 <richm> for example, doesn't nsupdate allow for constraints?  and tsigkeys?
17:25:07 <shakamunyi> richm correct
17:25:18 <richm> not sure how we will do that with the v1 or v2 api
17:25:27 <rjrjr_> also you can "batch" requests with nsupdate
17:25:35 <Kiall> Anyway - To recap as jmcbride suggests - 1) Identify gaps to support the functionality, 2) Close those gaps using the current APIs, 3) Create the dnsupdate util (optional, depending on if mDNS is ready), and 4) support RFC dynamic DNS using mDNS's code (may or may not be a separate service)
17:25:37 <RaginBajin> I'm sorry, but I can't find the blueprint that you guys are referencing.
17:25:44 <Kiall> RaginBajin: https://blueprints.launchpad.net/designate/+spec/dnsupdate
17:25:47 <RaginBajin> thx
17:26:02 <richm> Kiall: ok - I will update the blueprint
17:26:03 <vinod2> Would nsupdate or the equivalent run with admin privileges - so that they can make modifications to any tenant's data?
17:26:38 <mugsie> vinod2: Ideally no
17:26:53 <Kiall> vinod2: For #3, It would require the nsupdate call is TSIG signed, so we can identify the end user
17:27:09 <Kiall> which means it has a dep on https://blueprints.launchpad.net/designate/+spec/mdns-designate-scoped-tsig
17:27:15 <shakamunyi> richm dnsupdate allows for both constraints and tsigkeys (determining the latter through the parsing process)
17:27:58 <richm> shakamunyi: right, but I'm concerned with how we translate those into something that the designate api can consume
17:28:24 <Kiall> richm: concerned how we translate TSIG keys to user creds?
17:28:33 <richm> Kiall: yes
17:28:36 <rjrjr_> so, all we are really doing here is creating a new command called nsupdate, but isn't really nsupdate, correct?
17:28:47 <richm> rjrjr_: correct
17:29:05 <rjrjr_> doesn't make too much sense to me then. 8^(
17:29:06 <Kiall> rjrjr_: P1 and P2 do that, P3 uses the real nsupdate
17:29:10 <richm> a new command called "dnsupdate" so as not to conflict with the possibly already installed "nsupdate"
17:29:24 <Kiall> P1 would be considered a stop-gap while #3 is blocked
17:29:59 <Kiall> And, if RH have people asking and dev time to work on it, I don't see a reason to reject the P1 stopgap while P3 is blokced
17:30:00 <Kiall> blocked*
17:30:37 <Kiall> Building P1 will without a doubt make doing P3 easier, as gaps are closed in the API/Central layers
17:31:34 <shakamunyi> rjrjr_ dnsupdate just provides simplified command for nsupdate
17:31:49 <rjrjr_> what new functionality are we adding besides a different command line tool that does what designate command line tool does?
17:32:20 <shakamunyi> Kiall agree. I'm committed to that P1 stopgap
17:32:24 <Kiall> rjrjr_: well, it's not so much about having another tool, it's about compatibility with the standard (outside of designate) CLIs for managing DNS
17:33:00 <rjrjr_> so, the new dnsupate tool will be a shell like nsupdate is?
17:33:12 <richm> rjrjr_: a DNS admin who prefers to use nsupdate and has a lot of process/scripts built around using nsupdate will be reluctant to rewrite everything to use the designate command line tool
17:33:20 <Kiall> rjrjr_: yes, ideally a 100% compatible re-implementation
17:33:24 <richm> rjrjr_: yes - the goal is that it is a drop-in replacement
17:33:33 <Kiall> At least for the features it implements anyway
17:33:39 <richm> just sed -e s/nsupdate/dnsupdate/g
17:33:55 <rjrjr_> okay.
17:34:06 <shakamunyi> rjrjr_ and doing that with in an easy to use + script manner with some niceties (such as automatically creating PTRs for a given A or AAAA record)
17:34:32 <RaginBajin> but I guess anything written outside of the nsupdate tool is then kinda screwed right. (i.e. perl, etc)
17:34:35 <richm> so shakamunyi is also proposing some additional features that dnsupdate will have that nsupdate does not have
17:34:38 <Kiall> Or telling your DHCP server that nsupdate is at /usr/bin/*d*nsupdate etc
17:35:02 <richm> RaginBajin: not sure what you mean
17:35:11 <Kiall> RaginBajin: correct, Proposal 3, which we agree is the long term goal, solves working with code that doesn't shell out to nsupdate
17:35:13 <shakamunyi> richm all entirely ease-of-use
17:35:23 <richm> you mean, if someone has written something in Net::DNS?
17:35:31 <RaginBajin> richm yeah exactly
17:35:33 <richm> right, proposal 3
17:35:50 <Kiall> With P3 implemented, Net:DNS, dnspython, etc etc will all "just work" with Designate for updates etc
17:35:58 <RaginBajin> kiall: gotcha
17:37:01 <Kiall> Okay - I think we have consensus. shakamunyi / richm .. can we start by just identifying the gaps that will need to be fixed in API/Central - Once we have that we have a better idea of the work involved
17:37:16 <mugsie> +1
17:37:21 <richm> agreed
17:37:29 <eankutse> +1
17:37:35 <rjrjr_> +1
17:37:36 <Kiall> Okay - Let's move on so :)
17:37:42 <Kiall> #topic Server pool deployment question for multi-region/DC name servers
17:37:51 <Kiall> I'm not sure who added this item?
17:38:14 <mugsie> jmcbride: i think?
17:38:18 <Kiall> Looks like it was jmcbride - Anyone free to discuss?
17:38:34 <shakamunyi> Kiall agree
17:38:35 <shakamunyi> Kiall agreed
17:38:35 <jmcbride> yes, that was me, sorry guys
17:38:48 <jmcbride> so I brought along a friend
17:38:48 <Kiall> lol - sorry for what exactly? ;)
17:39:20 <jbratton> this goes back to what we started discussing at the summit about having multiple minidns servers with their own pools
17:39:36 <jbratton> so we need to define pools of pools for lack of a better way of saying it
17:39:58 <jbratton> and I don't care how it is implemented.. config files.. api.. etc.
17:40:04 <Kiall> Okay, so this was related to ensuring that DNS servers in Region A do AXFR's from, and get NOTIFY's from, Region A mDNS servers?
17:40:09 <jbratton> but each minidns needs to know who to send notifies to, and who to accept zone transfers from
17:40:13 <jbratton> yeah
17:40:30 <jbratton> we don't want a full mesh where every minidns is notifying every nameserver
17:40:41 <Kiall> ++
17:40:58 <jbratton> so I was thinking it could go in the api since that is where we define the nameservers at
17:41:01 <eankutse> +2
17:41:09 <jbratton> but that is just my thought.. you all are welcome to implement it however
17:41:16 <mugsie> yeah - so we define affinity to minidns installations at the servers level>
17:41:18 <eankutse> just like masters today have a list of slaves to send to
17:41:19 <mugsie> ?*
17:41:24 <Kiall> Okay, So, did anyone come up with a good way to handle this? My initial thought is around tagging mDNS servers (via a config option) and then tagging (via the API) the actual DNS servers with a matching attribute
17:41:45 <eankutse> I think a config file for miniDNS to read upon startup
17:41:52 <eankutse> will be one way to go
17:41:55 <mugsie> yeh, my initlal though was that it was another attrib on the hosts that we defined in the servers call
17:42:10 <Kiall> So.. an mDNS server with a tag of "region-a" would notify all servers with the "region-a" tag
17:42:18 <richm> p
17:42:31 <mugsie> which maps to a tag / something on a mDNS agent
17:42:48 <Kiall> But - that only solves NOTIFY's I think.. We still need to create the zone at the real DNS server with the correct list of mDNS's to AXFR from
17:43:08 <eankutse> mugsie: what is mDNS agen?
17:43:09 <mugsie> yeah, hense tagging the servers/hosts themselves as well
17:43:22 <mugsie> eankutse: agent - i cnat type
17:43:24 <Kiall> Maybe mDNS will, not unlike nova-compute, registers itself on startup as being part of a tag/region etc?
17:43:40 <Kiall> eankutse: mini-dns - just shorter ;)
17:43:58 <eankutse> I just wanted to clarify the "agent"
17:44:12 <eankutse> is that the service? or another thing?
17:44:27 <mugsie> a runnign instance of mDNS
17:44:31 <eankutse> k
17:45:04 <RaginBajin> and this would be use to handle load basically right
17:45:36 <jbratton> I envision multiple mdns agents for scale
17:45:42 <jbratton> to handle multiple geographic locations
17:46:04 <mugsie> RaginBajin: and to ensure a dns server in london doesnt AFXR from austin, when there is a mDNS server in london
17:46:10 <Kiall> So .. "designate-mdns" upon boot registers itself, like nova-compute does, with it's tag, and we "tag" servers in the pools API, we can then have knowledge of all the components involved, and make smart decisions around who to NOTIFY and where to AXFR.
17:46:21 <Kiall> (summarized my idea ^)
17:46:24 <mugsie> Kiall: yup
17:46:28 <mugsie> i think that works
17:46:30 <rjrjr_> makes sense.
17:46:34 <RaginBajin> mugsie: ok that's what I thought.. I've heard the term mdns before but not as mini-dns, so I wanted to be sure.
17:46:58 <mugsie> jbratton: does that look like what you were thinking?
17:47:09 <jbratton> yeah, that makes perfect sense
17:47:20 <mugsie> cool
17:47:43 <jbratton> we don't add/remove nameservers very often.. so how it is setup.. that can be as static or dynamic as needed
17:48:03 <vinod2> is there already a blueprint to track this?
17:48:05 <Kiall> The other option - which removes the "registers itself" bit, it just to have an API resource that lists out all the mDNS servers with there tags.. Simpler, but when things like dynamically booting a pool for a customer comes along, the registration piece can be reused to handle that
17:48:20 <Kiall> vinod2: No, this came out of the discussions in Atlanta.. But it was unsolved at the time
17:49:25 <Kiall> Doorbell - BRB
17:49:38 <eankutse> I can open a blueprint for this
17:49:55 <Kiall> Thanks eankutse
17:50:07 <RaginBajin> Is designate being the system to initiate the AXFR's or NOTIFY or are we giving that to processes like BIND. Trying to get my head around this, sorry for the questions.
17:50:10 <eankutse> #action eankutse open blueprint for regionalized mdns servers
17:50:25 <mugsie> RaginBajin: it is Designate
17:50:37 <Kiall> RaginBajin: Sure, so.. BIND/PowerDNS etc will be the "real DNS servers" (as it is today)
17:50:44 <shakamunyi> Kiall mDNS tagging makes sense to me
17:50:56 <Kiall> We'll also have this mini-DNS service, that BIND/PowerDNS/etc/etc do AXFR's from
17:50:57 <rjrjr_> Designate will.  the mdns (mini-dns) is going to be a simplified DNS server for transfers initially.
17:51:25 <Kiall> mini-DNS (or mDNS) will sent NOTIFY's to BIND/PowerDNS/etc, and BIND/PowerDNS/etc will perform an AXFR against mDNS
17:52:15 <Kiall> #action eankutse to file blueprint around region-aware handing of NOTIFY's and AXFR's
17:52:31 <Kiall> Once that's up, we can figure out the details
17:53:11 <Kiall> But.. I think we have a general direction to go with tag's (which may be the wrong word, but we'll figure that out when we have more than 5 mins left in the meet)
17:53:41 <shakamunyi> Kiall agree, think "tags" or (insert name here) is a start
17:53:43 <Kiall> #action kiall to re-add "Server pool deployment question for multi-region/DC name servers" to agenda one the BP is drafted
17:53:57 <Kiall> Okay .. Moving on, unless there are any other comments on this one? :)
17:54:13 <betsy> Not from me. It all sounds good
17:54:17 <Kiall> #topic Open Discussion
17:54:17 <mugsie> +1
17:54:24 <hvprash> so for us newcomers, is this is the official developer documenation we should be referring - http://designate.readthedocs.org/en/latest/devstack.html ? any suggestions, tips to get started?
17:54:26 <Kiall> Okay - Open discussion, anything off-agenda today?
17:54:45 <Kiall> hvprash: I have a ticket filed for me to update those docs, there slightly outdated
17:54:59 <Kiall> https://github.com/moniker-dns/devstack.git was moved to https://github.com/stackforge/designate/tree/master/contrib/devstack
17:55:24 <hvprash> looks like not much has changed and is a good reference to start with ?
17:55:35 <Kiall> Yea, it's just a "plugin" rather than fork of DevStack now
17:56:01 <rjrjr_> are we going to provide support for Keystone v3 domains?  have we been approached about this yet? http://www.florentflament.com/blog/setting-keystone-v3-domains.html
17:56:19 <RaginBajin> I do have a question, if someone wanted to write a driver for say a particular service, is there any starting point to look at
17:56:35 <Kiall> rjrjr_: I've been approached internally by HP Keystone folks, but haven't had much time to dig in yet
17:56:51 <Kiall> RaginBajin: when you say service, you mean something like a 3rd party hosted DNS?
17:56:57 <Kiall> or just a different DNS server?
17:57:04 <RaginBajin> kiall:  Yes a 3rd party hosted DNS
17:57:17 <Kiall> Inside of this folder https://github.com/stackforge/designate/tree/master/designate/backend
17:57:31 <Kiall> you'll see all the backends, one of them is a driver for DynECT (i.e DynDns)
17:57:32 <RaginBajin> kiall: Perfect. Thanks
17:57:49 <eankutse> I am startiing work on designate-mdns service. Hope to have basic initial submission in the next few days: https://blueprints.launchpad.net/designate/+spec/mdns-core-mdns-service
17:57:52 <denis_makogon> RaginBajin, do not forget about integration testing inside 3d party CI for any new driver
17:58:23 <Kiall> eankutse: excellent :)
17:58:52 <Kiall> RaginBajin: questions etc, drop by #openstack-dns and people are usually there
17:59:03 <Kiall> 2 mins left - Any other topics before we call it a day?
17:59:27 <betsy> Just FYI, I’ll be working on the database schema redesign for recordsets and records
17:59:51 <Kiall> Okay, if there's nothing else we're at time :)
17:59:52 <Kiall> Thanks all
17:59:53 <Kiall> #endmeeting