*** matsuhashi has joined #openstack-dns | 00:00 | |
*** eankutse has joined #openstack-dns | 00:14 | |
*** eankutse has quit IRC | 00:14 | |
*** eankutse has joined #openstack-dns | 00:15 | |
*** nosnos has joined #openstack-dns | 00:23 | |
*** vipul is now known as vipul-away | 00:48 | |
*** vipul-away is now known as vipul | 00:53 | |
openstackgerrit | Emmanuel Ankutse proposed a change to stackforge/designate: Update domains when servers are created, modified or deleted https://review.openstack.org/45078 | 01:33 |
---|---|---|
openstackgerrit | Emmanuel Ankutse proposed a change to stackforge/designate: Update domains when servers are created, modified or deleted https://review.openstack.org/45078 | 01:41 |
openstackgerrit | Emmanuel Ankutse proposed a change to stackforge/designate: Update domains when servers are created, modified or deleted https://review.openstack.org/45078 | 01:47 |
*** eankutse1 has joined #openstack-dns | 01:53 | |
*** eankutse1 has quit IRC | 01:53 | |
*** eankutse has quit IRC | 01:56 | |
*** zane has joined #openstack-dns | 04:35 | |
*** CaptTofu has joined #openstack-dns | 05:17 | |
*** zane has quit IRC | 06:16 | |
*** zane has joined #openstack-dns | 06:23 | |
*** zane has quit IRC | 06:24 | |
*** matsuhashi has quit IRC | 06:27 | |
*** matsuhashi has joined #openstack-dns | 06:28 | |
*** CaptTofu has quit IRC | 07:17 | |
*** matsuhas_ has joined #openstack-dns | 08:03 | |
*** matsuhashi has quit IRC | 08:03 | |
*** matsuhas_ has quit IRC | 08:39 | |
*** matsuhashi has joined #openstack-dns | 08:47 | |
*** matsuhashi has quit IRC | 08:49 | |
*** matsuhashi has joined #openstack-dns | 08:50 | |
*** matsuhas_ has joined #openstack-dns | 08:51 | |
*** matsuhashi has quit IRC | 08:55 | |
*** leizhang has joined #openstack-dns | 09:31 | |
*** matsuhas_ has quit IRC | 09:43 | |
*** leizhang has quit IRC | 09:56 | |
*** leizhang has joined #openstack-dns | 09:56 | |
*** nosnos has quit IRC | 10:17 | |
*** cflmarques has joined #openstack-dns | 10:54 | |
cflmarques | Hi Guys. | 11:08 |
cflmarques | Does anyone knows if Designate/APIv2 will be implemented on Havana release? | 11:08 |
mugsie | cflmarques: we are not really tied to the Openstack release cycles yet | 11:09 |
kiall | cflmarques: And - it's in progress, but .. not 100% confident on when it'll be "done" | 11:10 |
cflmarques | oh okay, | 11:11 |
cflmarques | Thank's a lot | 11:11 |
*** cflmarques has quit IRC | 12:12 | |
*** jmcbride has joined #openstack-dns | 12:15 | |
*** jmcbride has quit IRC | 12:19 | |
*** betsy has joined #openstack-dns | 13:03 | |
*** CaptTofu has joined #openstack-dns | 13:03 | |
*** eankutse has joined #openstack-dns | 13:17 | |
*** eankutse has quit IRC | 13:17 | |
*** eankutse has joined #openstack-dns | 13:17 | |
*** CaptTofu has quit IRC | 13:39 | |
*** tsimmons has joined #openstack-dns | 14:14 | |
*** msisk has joined #openstack-dns | 14:23 | |
*** tsimmons has quit IRC | 14:44 | |
*** tsimmons has joined #openstack-dns | 14:46 | |
*** jmcbride has joined #openstack-dns | 14:47 | |
*** tsimmons has quit IRC | 14:47 | |
*** jmcbride has quit IRC | 14:57 | |
*** jmcbride has joined #openstack-dns | 14:57 | |
*** CaptTofu has joined #openstack-dns | 15:05 | |
artom | https://blueprints.launchpad.net/designate/+spec/domain-import-export | 15:19 |
artom | I'm sorta working on that already (while waiting for higher up to approve (or not) me contributing to Designate). | 15:20 |
*** zane has joined #openstack-dns | 15:20 | |
artom | PowerDNS's zone2json tool does a good chunk of the job already... | 15:20 |
artom | At least for importing. | 15:21 |
artom | But that's the 'hacky internal script' way of doing it... | 15:25 |
*** openstackgerrit has quit IRC | 15:33 | |
*** openstackgerrit has joined #openstack-dns | 15:33 | |
*** ChanServ sets mode: +v openstackgerrit | 15:33 | |
betsy | artom: Looks like the blueprint you're referencing is talking about import/export for BiND9 format zone files. Is that what you're working on? Or, is it import/export for PowerDNS? | 15:37 |
artom | It's BIND zonefiles. | 15:42 |
artom | But PowerDNS (since version 3.3) comes with a tool called zone2json. | 15:42 |
artom | You give it a BIND named.conf and it spits out all the zones in JSON. | 15:42 |
artom | Handy because while I found python modules to parse zonefiles, so far I haven't see anything that can parse an entire BIND config starting from just the named.conf. | 15:43 |
artom | Actually, there's https://pypi.python.org/pypi/bicop | 15:45 |
artom | But not updated since 2009 and in RC status... | 15:45 |
*** vinodmr has joined #openstack-dns | 15:47 | |
artom | Heh, and it just failed on the named.conf I have. | 15:47 |
betsy | Ah. If it puts them in JSON, that's handy 'cause you can import them into anything - db, flat file, etc | 15:48 |
*** CaptTofu has quit IRC | 16:01 | |
kiall | artom: I have some *aful* code laying around that makes use of https://pypi.python.org/pypi/dnspython/1.11.1 for parsing zone files.. | 16:07 |
kiall | The library works well, but doesn't go from named.conf -> a bunch of zones.. It just does 1 zone file at a time.. | 16:08 |
kiall | (It's also the most painful library in the world to use.. but it does work reliably) | 16:08 |
artom | How do you see import/export fitting into the rest of Designate? | 16:10 |
artom | For example, the importing - as a standalone tool that performs API queries? | 16:10 |
artom | Or more... 'baked in'? | 16:11 |
kiall | artom: I think the best solution for users is an import API, upload a zonefile .. then have it do it's thing. | 16:11 |
artom | Ah! | 16:12 |
kiall | That way, people using perl/ruby/java/python/node/<insert hipster language here> can make use of it without re-implementing the whole thing :) | 16:12 |
artom | Scheme ;) | 16:12 |
artom | The problem with that (that I'm facing now) is that zonefiles could be split into different files. | 16:15 |
artom | So the file containing the SOA is included from a bunch of other files. | 16:16 |
vinodmr | Also if we have something like description fields that are not present in zonefiles buy present in central, how do we handle the import/export for those - we just ignore them? | 16:17 |
kiall | For built into designate's API, I'd argue that shouldn't be something we support. | 16:17 |
*** CaptTofu has joined #openstack-dns | 16:17 | |
kiall | vinodmr: Yea, I think import/export should care most about the standard zonefile content, I'd rather not add any "extra syntax" on top .. | 16:18 |
artom | Which is why I was thinking of something standalone... | 16:18 |
artom | And then I saw the blueprint and came here ;) | 16:18 |
kiall | On export, comments might just be comments in the zonefile.. But importing that might not be so easy (multi line comments might get split over 2 records etc) | 16:18 |
artom | So maybe a designte-manage command? | 16:18 |
kiall | artom: Well, it depends.. I think we want an API that accepts a whole and complete zonefile, then does it's thing.. | 16:19 |
kiall | designateclient could be given just enough smarts to assemble multi file zones into a single one for upload. | 16:19 |
artom | Ah! | 16:20 |
kiall | i.e. it should be possible to "parse" the include statements without doing a full-blown zonefile parser on the client side. | 16:21 |
artom | I can't argue on correctness - but that may end up being impractical for some (most?) users... | 16:21 |
kiall | I'd argue 99% of people with existing zonefiles have each zone self contained in a single file :) But - I'm totally making numbers up and going on gut ;) | 16:22 |
artom | They would have to triage their zonefile to exclude the bits and pieces that are included. | 16:22 |
kiall | Or, are you talking about importing multiple zones at once? | 16:23 |
artom | Yeah. | 16:23 |
artom | We shouldn't make assumptions, but why else would anyone use the importer? | 16:24 |
kiall | So, if I run my own DNS for example.com today and decide I want to switch to, say, HP Cloud DNS, a single zone, single file, import makes lots of sense, and will be a common thing for any public Designate deployments | 16:25 |
kiall | On the other hand, if run HP, and decide I want to switch all of HP's DNS to designate, then that's a totally different scenario where they may be hundreds of zones to move | 16:26 |
artom | True, true... | 16:26 |
artom | And you want to target the first one with import/export... | 16:26 |
artom | If both can be done in a semi-elegant way... | 16:27 |
kiall | If the API has a 1 zone, 1 file importer, then that covers use case #1 | 16:27 |
*** pasquier-s has quit IRC | 16:28 | |
kiall | Then, the client can be given a really minimal parser to take a multi file zonefile (still 1 zone) and parse the includes to generate 1 file for upload.. | 16:28 |
eankutse | Case #2 is a very important one as well | 16:28 |
eankutse | for initially migrating to Designate from an existing system | 16:28 |
eankutse | what is a suggested best approach for that? | 16:29 |
eankutse | import/export as well? | 16:29 |
kiall | And finally, for whole company / 200 zones style moves, we again layer on top of that, with a small named.conf parser that gets builds (zonename, main_zone_file) pairs to pass to ^ | 16:29 |
kiall | s/builds// | 16:29 |
kiall | But, I think the key thing for me is, the main zonefile parsing (extracting all the records, their types, their TTLs etc) should be server side. | 16:30 |
kiall | And, multi file stuff should be handled client side... Since, we can't resolve the include paths server side | 16:31 |
kiall | include "/etc/somepath/bla.conf"; \n include "/etc/someotherpath/bla.conf"; | 16:31 |
kiall | and include "../../../bla.conf" | 16:31 |
kiall | all those need to be parsed on the client, as they have no meaning once the set of files are uploaded | 16:32 |
kiall | (Also .. We'd need to find the set of files to upload in the first place, making the minimal include parser necessary anyway!) | 16:32 |
artom | What about fixes/changes to zonefile parsing? | 16:32 |
vinodmr | I would think for case #2, there should be a separate tool. Things like these are not done frequently and they are run with admin privileges | 16:32 |
artom | It's apparently very difficult to do. | 16:32 |
artom | So if there's ever a fix for a specific thing that we didn't think of, people need to wait for a new server release. | 16:33 |
kiall | That goes both ways! | 16:33 |
artom | Whereas if it's done client-side, it's easier to release a client update, no? | 16:33 |
kiall | If the client side parser has a bug, then I hope your application is compatible with the new release! | 16:33 |
artom | Not sure I understood that... | 16:34 |
kiall | And .. On top of that, perl/ruby/java/python/node/<insert hipster language here> would each need a full parser if it's client side.. | 16:34 |
eankutse | Kiall: for case #2, what do you think are downsides to using an approach where a db ETL tool is used to move (Export/Transform/Load) data across from existing db into designate-central? | 16:35 |
kiall | eankutse: I think that's perfectly okay for something in-house you plan on building and running once, for something we include with designate, I believe it would require the maintenance of lots of duplicated code | 16:36 |
eankutse | agree | 16:36 |
eankutse | do you think it's a viable approach though? | 16:37 |
artom | Why would perl/ruby/java/python/node/<insert hipster language here> need a full parser? | 16:37 |
artom | Or maybe I'm not getting what your idea of client-side is. | 16:37 |
kiall | eankutse: For 1 off bulk importers, I'd probably call straight into designate-central via RPC, bypassing the API, but not going straight to the database.. | 16:41 |
eankutse | Ahh. Thx | 16:42 |
kiall | artom: For me - client side is the customer.. | 16:42 |
*** CaptTofu has quit IRC | 16:43 | |
*** CaptTofu has joined #openstack-dns | 16:43 | |
artom | (Sorry for the haggling - not trying to be a pain in the ass - it's work that I'll end up doing one way or another, so I want to gage where the project is heading and why to avoid duplicate work if possible). | 16:44 |
artom | Now, back to haggling ;) | 16:44 |
kiall | artom: no problem at all - the more haggling, the better everyone understands :) | 16:44 |
artom | If designateclients gets a import command... | 16:45 |
artom | Why does that require Perl/Java/etc parsers? | 16:46 |
kiall | For the same reason we have multiple languages here: https://wiki.openstack.org/wiki/SDKs | 16:46 |
kiall | Not all imports will be someone typing out a command on the CLI, some will be integrating with existing systems in ways we've never even considered. | 16:47 |
artom | Ah, gotcha. | 16:48 |
kiall | Moving the complexity of full zonefile parsing to the server keeps the language bindings simple | 16:48 |
kiall | Then, the CLI that wraps the Python bindings can be given just enough of a parser to understand what an "include" is.. | 16:48 |
*** CaptTofu has quit IRC | 16:48 | |
*** CaptTofu has joined #openstack-dns | 16:49 | |
kiall | At that point, single zones spread over multiple files should be importable.. | 16:49 |
kiall | And finally, on top of that, you might layer something that can read a named.conf to determine the all zone names and "top" zonefiles for each zone, at that point, importing all zones from an existing bind server should work | 16:50 |
artom | Ok, I get use case #1 | 16:52 |
artom | In use case #2 where a large org is deploying Designate and moving all their domains to it... | 16:52 |
artom | They have access to the server. | 16:53 |
artom | Eh, it would be duplicate code. | 16:55 |
artom | I was thinking of a bulk importer server-side as a designate-manage command, for example. | 16:55 |
artom | But if you already have zone parsing in the API, there's no point in recoding something that does the same thing with named.conf parsing on top. | 16:56 |
*** CaptTofu has quit IRC | 16:58 | |
*** CaptTofu has joined #openstack-dns | 16:59 | |
*** vinodmr has quit IRC | 16:59 | |
*** jmcbride has quit IRC | 17:00 | |
kiall | (sorry - AFK dealing with something) | 17:05 |
*** CaptTofu has quit IRC | 17:20 | |
*** CaptTofu has joined #openstack-dns | 17:20 | |
*** jmcbride has joined #openstack-dns | 17:23 | |
*** jmcbride1 has joined #openstack-dns | 17:26 | |
*** jmcbride has quit IRC | 17:27 | |
*** tsimmons has joined #openstack-dns | 17:33 | |
*** shakayumi has joined #openstack-dns | 17:41 | |
*** eankutse has quit IRC | 17:41 | |
*** CaptTofu has quit IRC | 17:49 | |
*** CaptTofu has joined #openstack-dns | 17:50 | |
*** CaptTofu has quit IRC | 17:57 | |
*** eankutse has joined #openstack-dns | 17:59 | |
*** vinodmr has joined #openstack-dns | 18:01 | |
*** jmcbride1 has quit IRC | 18:08 | |
artom | No worries, was AFK pheeding ;) | 18:24 |
*** jmcbride has joined #openstack-dns | 18:33 | |
*** vipul is now known as vipul-away | 18:47 | |
*** vipul-away is now known as vipul | 18:47 | |
*** vinodmr has quit IRC | 18:53 | |
*** leizhang has quit IRC | 18:55 | |
*** tsimmons has quit IRC | 18:58 | |
*** eankutse has quit IRC | 19:02 | |
*** eankutse has joined #openstack-dns | 19:03 | |
*** vinodmr has joined #openstack-dns | 19:07 | |
*** jmcbride has quit IRC | 19:11 | |
*** tsimmons has joined #openstack-dns | 19:12 | |
*** CaptTofu has joined #openstack-dns | 19:12 | |
*** msisk has quit IRC | 19:22 | |
*** vinodmr has quit IRC | 19:23 | |
*** tsimmons has quit IRC | 19:24 | |
*** eankutse has quit IRC | 19:24 | |
*** vipul is now known as vipul-away | 19:24 | |
*** CaptTofu has quit IRC | 19:29 | |
*** dmakogon_ has joined #openstack-dns | 19:45 | |
*** tsimmons has joined #openstack-dns | 19:46 | |
*** tsimmons1 has joined #openstack-dns | 19:51 | |
*** tsimmons has quit IRC | 19:51 | |
*** jmcbride has joined #openstack-dns | 19:59 | |
*** msisk has joined #openstack-dns | 20:00 | |
*** tsimmons1 has quit IRC | 20:00 | |
*** jmcbride has quit IRC | 20:18 | |
*** msisk has quit IRC | 20:19 | |
*** vipul-away is now known as vipul | 20:20 | |
*** shakayumi has quit IRC | 20:36 | |
*** EmilienM has quit IRC | 21:22 | |
*** EmilienM has joined #openstack-dns | 21:23 | |
*** zane has quit IRC | 22:07 | |
*** dmakogon_ has quit IRC | 22:24 | |
*** openstack has quit IRC | 22:35 | |
*** openstack has joined #openstack-dns | 22:35 | |
*** ChanServ sets mode: +v openstack | 22:36 | |
openstackgerrit | Betsy Luzader proposed a change to stackforge/designate: docs: Correct errors in the Create Record examples https://review.openstack.org/47648 | 22:41 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!