Wednesday, 2013-09-25

*** yidclare has quit IRC00:14
*** nosnos has joined #openstack-dns00:16
*** matsuhashi has joined #openstack-dns00:35
*** kiall has quit IRC03:04
*** nosnos has quit IRC03:40
*** nosnos has joined #openstack-dns03:41
*** nosnos has quit IRC03:42
*** nosnos has joined #openstack-dns03:44
*** kiall has joined #openstack-dns04:09
*** vipul is now known as vipul-away04:12
*** vipul-away is now known as vipul04:16
*** krow has joined #openstack-dns04:36
*** krow has quit IRC05:54
*** krow has joined #openstack-dns05:55
*** krow has quit IRC07:32
openstackgerritGraham Hayes proposed a change to stackforge/designate: Add status fields for domains and records  https://review.openstack.org/4473010:00
openstackgerritGraham Hayes proposed a change to stackforge/designate: Add status fields for domains and records  https://review.openstack.org/4473010:11
openstackgerritGraham Hayes proposed a change to stackforge/designate: WIP: Adding inital server pools implementation  https://review.openstack.org/4739710:33
*** krow has joined #openstack-dns11:04
*** krow has quit IRC11:23
openstackgerritKiall Mac Innes proposed a change to stackforge/python-designateclient: Add Python bindings docs  https://review.openstack.org/4824412:54
openstackgerritKiall Mac Innes proposed a change to stackforge/python-designateclient: Add Python bindings docs  https://review.openstack.org/4824412:55
*** dmakogon has quit IRC13:22
*** eankutse has joined #openstack-dns13:44
openstackgerritKiall Mac Innes proposed a change to stackforge/python-designateclient: Add Python bindings docs  https://review.openstack.org/4824413:52
openstackgerritKiall Mac Innes proposed a change to stackforge/python-designateclient: Add Python bindings docs  https://review.openstack.org/4824413:54
openstackgerritA change was merged to stackforge/python-designateclient: Add Python bindings docs  https://review.openstack.org/4824413:57
*** matsuhashi has quit IRC14:07
*** nosnos has quit IRC14:08
*** pp has joined #openstack-dns14:13
openstackgerritKiall Mac Innes proposed a change to stackforge/python-designateclient: Correct two Record examples in the binding docs  https://review.openstack.org/4826214:16
kiallhttp://python-designateclient.readthedocs.org/en/latest/bindings.html :)14:19
ppHi guys , anyone can help with my multiple node ubuntu 12.04  with grizzly  , all the service quantum , e nova are fine  , in my vm the can ping each other , from vm I can ping outside , I can access from outside with ssh , but if I use apt-get update is stock , and I have tried with ubuntu-desktop I not able to surf  , not open the page .  from  tail -f grep dns /var/log/syslog  http://paste.ubuntu.com/6154635/   any suggestion ?14:19
openstackgerritA change was merged to stackforge/python-designateclient: Correct two Record examples in the binding docs  https://review.openstack.org/4826214:19
kiallpp: probably the wrong room ;) This is more related to the Designate project.. BUT.. Have you checked the contents of /etc/resolve.conf, and ensured it's pointing to the right thing?14:22
kiallI've actually never used quantum, but I'm betting it's DNS handling isn't too far off nova-network's ..14:22
kiallmake sure "dnsmasq" isn't installed on any of the hardware nodes, and that "dnsmasq-base" is ..14:23
ppfrom the vm is point :  nameserver 8.8.8.814:23
ppsearch openstacklocal14:23
kiallAh ..14:23
kiallWell ..can you ping 8.8.8.8?14:23
kiallIf not.. That's defiantly a quantum setup issue.. I've no clue how to help with that!14:24
kiall#openstack or #openstack-neutron might be able to offer some advice..14:24
ppkiall:  yes I can ping any  ip , but I cant do example apt-get update14:24
ppkiall: thanks for help14:24
kiallNo worries - either way, with 8.8.8.8 as your instances nameserver, it's likely going to be a networking issue ..14:25
*** betsy has quit IRC14:25
*** zane has joined #openstack-dns14:40
*** pp has left #openstack-dns14:40
*** pp has joined #openstack-dns14:46
ppkiall:  do you suggest an other dns ?14:47
*** yidclare has joined #openstack-dns14:55
*** betsy has joined #openstack-dns15:11
*** zane has quit IRC15:21
*** zane has joined #openstack-dns15:28
*** zane has left #openstack-dns15:29
*** zane has joined #openstack-dns15:29
artomI had a meeting with the higher ups about what direction we're heading in with Designate.15:32
artomSince we want to expose NSD to the world, there was talk about coding a NSD backend for Designate.15:32
artom(As opposed to slaving NSDs to Designate's PowerDNS+MySQL master).15:33
artomI said upstream is unlikely to be interested, since for an NSD agent to make sense, it would have to be able to control a remote NSD (kinda like the BIND backend with rndc now), and NSD3 has no native remote-control functionality.15:34
kiallartom: heya15:34
artomTherefore any NSD backend would include an "agent" that would run on the remove NSDs.15:34
artomAnd that's most likely out of scope for Designate.15:34
kiallSo .. uninterested is probably harsh :) Just wanting to avoid proliferation of backends unnecessarily!15:35
kiallSome of work-in-progress at the moment is also relevant here.. lets see if I can find mugsie link15:36
kiallmugsie's link*15:36
kiallhttps://wiki.openstack.org/wiki/Designate/Server_Pools15:36
*** dmakogon has joined #openstack-dns15:37
kiallWith ^, we're pushing the responsibility of distributing changes to multiple nameservers into the backends15:37
kiallSince, each one is drastically different..15:37
kiallPowerDNS is just a DB, BIND masters are a file on disk and (possibly) a remote call to `rndc addzone` for the slaves..15:38
kialland NSD, per your description, will require "touching" each server directly..15:38
kiallAll very very different approaches :)15:38
artomAnd now I'm imagining the FSM caressing an NSD server... ;)15:39
kiallWhat I'm getting at is, a backend is (will be) essentially free to choose how to distribute the changes using whatever works for that nameserver15:39
artomRight.15:40
kiallHah :)15:40
artomThe issue with NSD is that there's no remote control for it. So either the backend is local to each NSD server (and thus remove to the rest of Designate, communicating with it through the MQ perhaps?)15:41
artoms/remove/remote/15:42
artomOr the backend is a client-server type thing with a server sitting on each remote NSD accepting commands from the client, which is local to Designate.15:42
kialllocal to each NSD wouldn't necessarily work with the newer plans.. Part of the issue with the old way was that we expected the backend to be local to each service.. and that really doesn't work the way you might expect!15:43
kiallto each nameserver in cases where something local needed to be touched*15:43
kiallBut, yea, the NSD backend could easily send out a message over rabbitmq or whatever, and have the actual nameservers action the change..15:44
kiallThe difference between old and new is, the backend class is responsible for that, rather than assuming a single method will always work and baking in it15:44
kiallbaking it in*15:44
artomYeah, I see...15:45
artomBut say we commit an NSD backend in the future, but we add "Oh and by the way, with this backend there's also this Python daemon we coded that needs to run on each NSD server in order to effect the changes"15:47
artomThat seems... out of scope?15:47
artomFor Designate proper, anyways.15:47
*** dmakogon has quit IRC15:48
kiallNot 100% out of scope, but probably not 100% in scope either.. If it was pretty isolated, in such a way that it had very few dependencies on the rest of the code (the non NSD backend code anyway), It would be much easier to fit in..15:49
kiallThe difficulty with every new backend etc that comes in, is suddenly, it needs to be maintained :)15:49
artomIf we do end up going this route it'll be backed by the company, so as long as we're not bankrupt it should remain maintained ;)15:53
kiall:)15:54
artomAnd when you say "it had very few dependencies on the rest of the code" - it == the daemon?15:55
kiallYea, the more isolated custom stuff for a specific backend is, the less maintenance needs over time15:55
artomTrue, true15:56
artomAlso, it would probably be a good idea for the BIND and NSD backends so share the zonefile-writing code.15:58
artomThe differences would be in how they effect the changes.15:58
artoms/so share/to share/15:59
kiallartom: absolutely..16:05
kiallBoth use standard RFC style zonefiles .. So it should be no issue16:05
artomNothing's decided for the backend yet - I'll have to make a quick presentations for the higher-ups about the pros and cons of rolling an NSD backend vs PowerDNS -> NSD with AXFR and some hooks...16:10
artomI did get the go-ahead for working with upstream though.16:10
kiallartom: actually.. speaking of hooks16:10
kiallSo, we do emit notifications about all changes etc over rabbitmq.. There intended for ceilometer / our metering and billing team etc.. But.. They might be useful..16:11
artomYeah, I had some proof of concept code that does just that ;)16:12
*** pp has left #openstack-dns16:12
artom*have16:12
*** ppenjoy has joined #openstack-dns16:13
*** zane has quit IRC16:19
*** zane has joined #openstack-dns16:22
*** vinodmr has joined #openstack-dns16:32
*** ppenjoy has left #openstack-dns16:36
eankutseKiall: regarding https://review.openstack.org/#/c/45078/8, our DNS guru pointed out that the serial number in the SOA records in the backend were not being updated when changes occur in the backend zone due to server_create, server_update, server_delete. Given that the Records.content field (which contains the serial number sub-field) is one Text field, it is proving quite challenging to update that sub-field with the  bulk queries I am16:40
kialleankutse: heya! Yea, I saw the conversion you had with mugsie the other day.. But I haven't had an opportunity to give it any thought myself!16:44
*** Kiall2 has joined #openstack-dns16:58
*** Kiall2 has quit IRC16:59
*** Kiall2 has joined #openstack-dns16:59
*** kiall has quit IRC16:59
*** Kiall2 is now known as Kiall16:59
KiallSo .. Meet in #openstack-meeting-alt16:59
*** dmakogon has joined #openstack-dns17:07
*** zane has left #openstack-dns17:08
*** zane has joined #openstack-dns17:08
*** eankutse has quit IRC17:14
*** jmcbride has joined #openstack-dns17:14
*** eankutse has joined #openstack-dns17:14
*** eankutse has quit IRC17:31
*** eankutse has joined #openstack-dns17:41
*** kiall_ has joined #openstack-dns17:48
*** vipul is now known as vipul-away17:49
*** vipul-away is now known as vipul17:49
*** eankutse has quit IRC17:56
*** eankutse has joined #openstack-dns18:00
*** Kiall has quit IRC18:11
*** vinodmr has quit IRC18:34
*** tsimmons has joined #openstack-dns18:34
*** jmcbride has quit IRC18:59
*** eankutse has quit IRC19:01
*** eankutse has joined #openstack-dns19:03
*** vipul is now known as vipul-away19:30
*** vipul-away is now known as vipul19:37
*** CaptTofu has quit IRC19:43
*** CaptTofu has joined #openstack-dns19:43
*** CaptTofu_ has joined #openstack-dns19:44
*** CaptTofu_ has quit IRC19:44
*** CaptTofu_ has joined #openstack-dns19:48
*** CaptTofu has quit IRC19:48
*** adrian_otto has joined #openstack-dns19:51
*** vipul is now known as vipul-away19:52
*** tsimmons has left #openstack-dns19:53
*** vipul-away is now known as vipul20:00
*** eankutse has quit IRC20:03
*** eankutse has joined #openstack-dns20:06
*** eankutse has quit IRC20:06
*** eankutse has joined #openstack-dns20:06
*** eankutse has quit IRC21:13
*** eankutse has joined #openstack-dns21:15
*** krow has joined #openstack-dns21:40
*** vipul is now known as vipul-away21:47
*** vipul-away is now known as vipul21:47
*** krow has quit IRC21:48
*** eankutse has quit IRC21:51
*** eankutse has joined #openstack-dns21:56
*** betsy has quit IRC22:14
*** krow has joined #openstack-dns22:15
*** eankutse has quit IRC22:20
*** dmakogon has quit IRC22:33
*** dmakogon has joined #openstack-dns22:34
*** zane has quit IRC22:43
*** krow has quit IRC22:53
*** krow has joined #openstack-dns22:56
*** krow has quit IRC23:30
*** adrian_otto1 has joined #openstack-dns23:42
*** adrian_otto has quit IRC23:45
*** adrian_otto1 has quit IRC23:46
*** krow has joined #openstack-dns23:57

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!