| *** nosnos has joined #openstack-dns | 00:36 | |
| *** vipul is now known as vipul-away | 00:57 | |
| *** vipul-away is now known as vipul | 00:59 | |
| *** eankutse has joined #openstack-dns | 02:21 | |
| *** eankutse has quit IRC | 02:43 | |
| *** vipul has quit IRC | 03:11 | |
| *** vipul has joined #openstack-dns | 03:12 | |
| *** CaptTofu_ has joined #openstack-dns | 04:28 | |
| *** CaptTofu has quit IRC | 04:30 | |
| *** eankutse has joined #openstack-dns | 07:49 | |
| *** eankutse has quit IRC | 07:50 | |
| openstackgerrit | Kiall Mac Innes proposed a change to stackforge/designate: Ensure tables are InnoDB and UTF8 https://review.openstack.org/46044 | 10:19 |
|---|---|---|
| openstackgerrit | Kiall Mac Innes proposed a change to stackforge/designate: Ensure tables are InnoDB and UTF8 https://review.openstack.org/46044 | 10:28 |
| *** CaptTofu_ has quit IRC | 10:39 | |
| *** CaptTofu has joined #openstack-dns | 10:39 | |
| *** dguerri has joined #openstack-dns | 10:48 | |
| *** dguerri has joined #openstack-dns | 10:48 | |
| *** dguerri has joined #openstack-dns | 10:49 | |
| *** dguerri has joined #openstack-dns | 10:50 | |
| *** eankutse has joined #openstack-dns | 11:30 | |
| *** eankutse has quit IRC | 11:31 | |
| *** eankutse has joined #openstack-dns | 11:32 | |
| *** eankutse has quit IRC | 11:32 | |
| *** eankutse has joined #openstack-dns | 13:19 | |
| *** eankutse1 has joined #openstack-dns | 13:21 | |
| *** eankutse has quit IRC | 13:21 | |
| *** vinodmr has joined #openstack-dns | 13:32 | |
| *** nosnos has quit IRC | 13:38 | |
| openstackgerrit | A change was merged to stackforge/designate: Ensure tables are InnoDB and UTF8 https://review.openstack.org/46044 | 13:40 |
| *** betsy has quit IRC | 14:20 | |
| *** msisk has joined #openstack-dns | 14:21 | |
| *** betsy has joined #openstack-dns | 15:06 | |
| *** betsy has quit IRC | 15:38 | |
| *** betsy has joined #openstack-dns | 15:43 | |
| *** vinodmr has quit IRC | 15:51 | |
| *** msisk has quit IRC | 16:04 | |
| *** msisk has joined #openstack-dns | 16:05 | |
| *** msisk has quit IRC | 16:06 | |
| openstackgerrit | Kiall Mac Innes proposed a change to stackforge/designate: WIP: Introduce the RecordSet concept https://review.openstack.org/46094 | 16:16 |
| openstackgerrit | Kiall Mac Innes proposed a change to stackforge/designate: WIP: Introduce the RecordSet concept https://review.openstack.org/46094 | 16:17 |
| *** eankutse1 has quit IRC | 16:18 | |
| *** eankutse has joined #openstack-dns | 16:19 | |
| openstackgerrit | Kiall Mac Innes proposed a change to stackforge/designate: WIP: Introduce the RecordSet concept https://review.openstack.org/46094 | 16:22 |
| *** betsy has quit IRC | 16:26 | |
| *** jmcbride has joined #openstack-dns | 16:30 | |
| *** msisk has joined #openstack-dns | 16:35 | |
| openstackgerrit | Kiall Mac Innes proposed a change to stackforge/designate: WIP: Introduce the RecordSet concept https://review.openstack.org/46094 | 16:37 |
| *** betsy has joined #openstack-dns | 16:44 | |
| kiall | *So glad* to finally have time to write actual code again ;) | 16:44 |
| eankutse | Kiall: You've been MIA for a while | 16:46 |
| *** eankutse has quit IRC | 16:53 | |
| *** eankutse has joined #openstack-dns | 16:53 | |
| kiall | eankutse: mixture of DIY work, being ill, and some work on our automation.. Part of the fun of being Dev, Ops and Support ;) | 16:58 |
| eankutse | Welcome back to the IRC :-) | 16:58 |
| kiall | :) | 16:59 |
| betsy | kiall: Hope you're feeling better | 16:59 |
| kiall | So - Short meet over in #openstack-meeting-alt ? | 17:00 |
| betsy | yes | 17:00 |
| *** eankutse1 has joined #openstack-dns | 17:06 | |
| *** eankutse has quit IRC | 17:07 | |
| *** vinodmr has joined #openstack-dns | 17:08 | |
| *** kiall has quit IRC | 17:41 | |
| *** kiall has joined #openstack-dns | 17:51 | |
| *** vinodmr has quit IRC | 17:52 | |
| *** vipul is now known as vipul-away | 18:17 | |
| *** tsimmons has joined #openstack-dns | 18:20 | |
| *** eankutse1 has quit IRC | 18:22 | |
| *** vinodmr has joined #openstack-dns | 18:24 | |
| *** vipul-away is now known as vipul | 18:26 | |
| *** eankutse has joined #openstack-dns | 18:37 | |
| *** vipul is now known as vipul-away | 19:00 | |
| *** jmcbride has quit IRC | 19:26 | |
| *** jmcbride has joined #openstack-dns | 19:40 | |
| kiall | Heya | 19:50 |
| kiall | Heya | 19:50 |
| tsimmons | Hey | 19:50 |
| kiall | tsimmons: Heya - You had some Q's re the draft you put up? | 19:52 |
| tsimmons | Yup. Let's see... | 19:52 |
| kiall | BTW - Someone from your team was asking about public channel logs .. http://eavesdrop.openstack.org/irclogs/%23openstack-dns/ | 19:53 |
| tsimmons | Ah, that's convenient. | 19:53 |
| kiall | Grr - Just realized I left my latest comment on that draft unpublished -_- | 19:54 |
| tsimmons | Oh cool, go ahead and publish it and I'll see if it answers my questions :) | 19:54 |
| kiall | It probably doesn't ;) | 19:54 |
| tsimmons | Ah, well kind of. I guess I was wondering what the plugin ought to do in terms of deciding where zone files should go, in the end. Should it generate them, no matter what and keep them in the state directory, and then copy them over somehow? | 19:55 |
| tsimmons | Or would you rather the plugin just send a message to the agent to generate the zone files? | 19:56 |
| tsimmons | Or maybe both | 19:56 |
| *** vipul-away is now known as vipul | 19:56 | |
| tsimmons | Because we'd like to keep it so that someone could run bind9 locally or on a remote server. | 19:56 |
| tsimmons | Of course you could just run the agent on the same box. | 19:58 |
| kiall | Sorry - was AFK for a sec | 19:58 |
| kiall | So, I actually think there's a whole pile of ways to do it.. and depending on the DNS server in use, things are different | 19:59 |
| *** zane has joined #openstack-dns | 20:00 | |
| kiall | So - PowerDNS uses a plain database, with a concept of "SuperMasters" for pushing to remote datacenters.. | 20:00 |
| kiall | (It doesn't handle delete though..) | 20:00 |
| kiall | Bind9 uses either zonefiles on every server (either every server is a "master" with a full copy of the zone, or some servers are slaves with a stub and a list of masters to AXFR from) | 20:00 |
| kiall | Other DNS servers (well.. providers) have a web services API to interact with them | 20:01 |
| kiall | and .. some deploys will prefer old fashioned NFS or rsync to spread the zone.. | 20:01 |
| kiall | What I'm getting at is, there is no 1 pattern that will suit every deployment and DNS server combination | 20:01 |
| tsimmons | Right, that makes sense. In terms of the Designate bind9 plugin, how do you handle that? | 20:02 |
| tsimmons | Well let me rephrase that. | 20:02 |
| kiall | The short-ish term plan for the pool manager, is 1) for each pool there is exactly 1 active pool manager.. | 20:02 |
| tsimmons | Right ok, so use the pool manager. | 20:03 |
| kiall | 2) thats the only thing central talks to, it won't talk to DNS servers directly | 20:03 |
| tsimmons | ok | 20:03 |
| kiall | So - Pool Managers will load the backend plugins, which will need some minor modifications.. | 20:03 |
| kiall | Say you went with the hidden master approach, combined with remote `rndc addzone` etc to reach the slaves, who then AXFR from the master | 20:04 |
| kiall | The backend plugin would write out the zone file locally, load it into a bind9 server, then call `rndc addzone` against each of the slaves... | 20:05 |
| kiall | (a quick example of that google found is rndc addzone sec.ipamworldwide.com ‘{ type slave; masters { 10.99.32.57; 172.19.23.103; }; allow-query {internal;}; };’) | 20:05 |
| kiall | the backend plugin would be responsible for saying "sec.ipamworldwide.com" is now live on all the DNS servers, which triggers the progression from PENDING->ACTIVE | 20:06 |
| tsimmons | ok. I think I understand. | 20:07 |
| kiall | So - Again, what I'm getting at is, we should 1) pick a method. It doesn't matter if it's remote `rndc addzone` or rsync or .. 2) Try and ensure we allow for the code to be extended to handle other situations, you guys might like rsync, while the next guy wants NFS | 20:08 |
| kiall | and 3) When other groups want to use bind9, but a different pattern, they can hop in and extend where necessary | 20:08 |
| kiall | re #2 on that list, we really don't have any allowances for that today.. But then again, we really don't have any sane allowances for configuring multiple DNS servers (except for those which pull config from a central source) | 20:10 |
| kiall | So, we can go incrementally, getting 1 sane method baked in first, and refactor later to make it easier to extend.. | 20:10 |
| tsimmons | Right. That makes sense. Most of my trepidation was the concept of having everything coming out of central. | 20:11 |
| kiall | Yea, with the pool manager idea, we push the distribution of changes out, allowing central to just fire-and-forget a message into the pool's queue | 20:12 |
| tsimmons | Yeah, that's quite elegant. | 20:13 |
| tsimmons | So in terms of this review here. I should just make it so that the local bind installation works with rndc addzone/delzone, and copy the cache file over into zones.config. But really it's just practice for integrating a similar system with the pool manager. | 20:13 |
| kiall | Yea, all the backends will need some extension to suit the pool manager concept, it shouldn't be a rewrite though! Just some additions | 20:16 |
| tsimmons | Yeah it'll just be a little different. It doesn't matter though, even if no code came out of this I learned a ton. Ok. So is that what Graham is working on, the pool manager? | 20:17 |
| kiall | Yea - Pool Manager made it's way into the async work, as we needed a way to reliably process the "fire and forget" messages in the correct order.. | 20:18 |
| tsimmons | Cool. I think that's a great idea. I can't wait to see it in action. | 20:19 |
| kiall | So, we had a plan for multiple pools at some point anyway, and an active/standby pool manager allows for the FIFO semantics we needed.. and when 1 active pool manager isn't enough, adding a second pool (and thus pool manager) should be easy enough. | 20:19 |
| kiall | Still trying to wrap my head around how 1 set of DNS servers might be shared by multiple pools, since we don't want to limit the # of zones a given set of DNS servers can handle to what 1 pool manager can process.. | 20:20 |
| tsimmons | So the idea being, Designate could be used to manage multiple sets of DNS Servers, serving a different set of zones for different purposes? | 20:23 |
| kiall | Yea, some of the original ideas for "pools" were around things like different service levels (1 offering using 100's of POPs globally, and another offering just 2-3 POPs), and "private dns instances". | 20:24 |
| kiall | We got a surprising number of requests for zones like "dev.local" | 20:25 |
| kiall | which, on 1 set of DNS servers, you can't do (well .. views, but I see that as slicing a DNS server into N parts :)) | 20:25 |
| tsimmons | Yeah, so you'll be able to mark a pool as private, but that would be the customers own DNS server? | 20:26 |
| kiall | So - The idea being, we might spin up managed DNS servers for customers, like Trove does for databases.. These instances would be authoritative to the world, and recursive to their instances.. How that might actually work, I've not researched yet .. But I'm fairly confident it's doable with Neutron! | 20:27 |
| kiall | Anyway - all that is little more than ideas at the moment.. Just some of the things that "pools" might get used for | 20:29 |
| tsimmons | Ahh so they're actually virtual private DNS servers that a customer could add real world domains to, or their own private stuff? | 20:29 |
| tsimmons | I don't understand "These instances would be authoritative to the world, and recursive to their instances.." :) | 20:29 |
| kiall | Well, No reason they can't add both possibly allowing the world to query 1 zone while restricting another to just there instances.. | 20:30 |
| kiall | without split-horzin getting baked into Neuton, they would need to configure the instance as their Neutron subnet's nameserver.. | 20:30 |
| kiall | So, we'd have to allow recursive DNS on them | 20:31 |
| tsimmons | Alright, well. That's more time of yours than I wanted to take up. I'll work on finishing up what I'm doing and then I'll be looking out for some pool manager code to sink my claws into next. | 20:35 |
| tsimmons | Ok, I think I actually get that now. I just needed a minute. That would be awesome. | 20:36 |
| kiall | Yea - The trick is to separate the concepts ;) Since we're planning the absolute bare minimum of the pools concept necessary to get async going.. | 20:38 |
| tsimmons | Yeah. It's cool stuff though. I'll work on finishing up this draft and getting it submitted. Then all of the new hotness. :) | 20:42 |
| kiall | Yea - I'm just hoping we don't find another flaw in this plan .. I think this is plan #3 (or plan #80 if you count plans that didn't last more than 10 minutes ;)) | 20:44 |
| tsimmons | Yeah, but this seems to be pretty clean, having a component that gets the information, a component that processes that and formulates what you want to do, and then sending it to another place that knows how to do it is pretty cool imo. | 20:46 |
| *** msisk has quit IRC | 20:48 | |
| tsimmons | Alright. Well thanks for everything Kiall! I appreciate your time. | 20:54 |
| kiall | Yea, there are days where I'd love to go back to 1 layer .. API -> ZoneFiles .. But then .. There's so much you don't get.. Like scaling to some ridiculous number of zones, or allowing for multiple data entry methods (REST, inbound AXFR, dynamic DNS), classes of service etc ;) | 20:55 |
| *** eankutse has quit IRC | 21:29 | |
| *** jmcbride has quit IRC | 21:52 | |
| *** betsy has quit IRC | 21:58 | |
| *** tsimmons has quit IRC | 22:02 | |
| *** tsimmons has joined #openstack-dns | 22:03 | |
| *** tsimmons has quit IRC | 22:08 | |
| *** vinodmr has quit IRC | 22:14 | |
| *** zane has quit IRC | 22:22 | |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!