Friday, 2019-03-01

*** abaindur__ has quit IRC00:00
*** abaindur has quit IRC00:05
*** abaindur has joined #openstack-dns00:05
*** abaindur_ has joined #openstack-dns00:08
*** abaindur has quit IRC00:10
*** abaindur has joined #openstack-dns01:24
*** abaindur_ has quit IRC01:25
*** abaindur_ has joined #openstack-dns01:28
*** abaindu__ has joined #openstack-dns01:31
*** abaindu__ is now known as abaindur__01:31
*** abaindur has quit IRC01:31
*** abaindur_ has quit IRC01:33
*** abaindur has joined #openstack-dns01:34
*** abaindur_ has joined #openstack-dns01:36
*** abaindur__ has quit IRC01:36
*** abaindur has quit IRC01:38
*** abaindur has joined #openstack-dns01:39
*** abaindur_ has quit IRC01:41
*** abaindur_ has joined #openstack-dns02:40
*** abaindu__ has joined #openstack-dns02:43
*** abaindur has quit IRC02:43
*** abaindu__ is now known as abaindur__02:43
*** abaindur_ has quit IRC02:45
*** abaindur has joined #openstack-dns02:47
*** abaindur_ has joined #openstack-dns02:50
*** abaindur__ has quit IRC02:50
*** abaindur has quit IRC02:52
*** abaindur_ has quit IRC02:52
*** awalende has joined #openstack-dns03:06
*** awalende has quit IRC03:10
openstackgerritMerged openstack/python-designateclient master: add python 3.7 unit test job  https://review.openstack.org/63724804:30
*** abaindur has joined #openstack-dns05:58
*** abaindur has quit IRC05:59
*** abaindur has joined #openstack-dns05:59
*** ivve has joined #openstack-dns06:34
*** abaindur has quit IRC08:01
*** awalende has joined #openstack-dns08:11
*** ginopc has joined #openstack-dns08:11
ivveis there a way to manage the reverse lookup zones in designate? im testing a bit back and forward and i can see that there are still active reverse zones even tho i removed the forward zone (if they are even linked somehow).. im checking in the designate DB08:43
*** salmankhan has quit IRC09:01
*** hoango has joined #openstack-dns09:08
*** hoango has quit IRC09:09
*** eandersson has quit IRC10:20
*** salmankhan has joined #openstack-dns10:29
*** salmankhan1 has joined #openstack-dns10:33
*** salmankhan has quit IRC10:36
*** salmankhan1 is now known as salmankhan10:36
fricklerivve: if you are using neutron integration, the reverse zones should be automatically created by the neutron user, and I don't think they are ever cleaned up. the records in them should be deleted though12:23
ivvefrickler: ok i got it working but there is something strange12:57
fricklermugsie: I just saw that we have [service:worker]enabled marked as deprecated for removal, but it seems to be still needed to be set to true in order for a worker to be started12:58
fricklermugsie: what do you think about a quick patch to change that in stein still, so that we could really drop it in train?12:58
ivvefrickler: i have it working now and they are created in the service tenant.. however i have configured designate.conf to use formatv4 = f-%(hostname)s-%(project)s.%(zone)s12:58
ivvebut it creates the ptr records as formatv4 = %(hostname)s.%(project)s.%(zone)s13:01
ivveis it the default deprecated format = perhaps?13:01
ivveill set format = as well and see if it changes13:03
*** HD|Laptop has joined #openstack-dns13:04
HD|Laptophello everyone.13:04
HD|Laptopi'm trying to get Designate running (debian testing / rocky with Debian packages), but the worker service will not appear in "dns service list", and created zones stay in PENDING13:04
HD|Laptopchanges done via the openstack CLI only get done when I manually restart the worker service13:04
ivvethis feels like a bug13:32
ivveptr's are not obeying formatv4 stanza13:33
HD|Laptophmm. i reverted to pool_manager by setting worker.enabled=false now, even though this feels like wrong...13:55
ivvehmm14:05
ivveseems like %(hostname)s isn't working14:05
ivvefor floating ips14:08
mugsiefrickler: yeah, that is a good idea14:14
mugsieivve: we dont have access to the hostname in the neutron notification14:15
ivvemugsie: yeah i can find some older bugreports from 201714:16
ivveit does however create a "hostname.tenant.zone" PTR14:17
ivvehow is that possible? some kind of default?14:17
ivveis there any other way of solving it?14:17
ivveim guessing display_name doesn't work either14:18
mugsiehttps://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html is another way14:18
ivvemugsie: you mean with port?14:19
mugsieyeah - this removes the need for -sink14:20
mugsiebut it limited in some ways14:20
mugsieivve: when it creates the PTR, is hostname the actuall hostname?14:21
ivveokay so this is my config14:22
ivvefor nova_fixed: formatv4 = f-%(display_name)s-%(project)s.%(zone)s14:23
ivvefor neutron_floating: formatv4 = n-%(display_name)s-%(project)s.%(zone)s14:24
ivvecreate an instance. i receive f-server-project.example.com14:25
ivveall is good14:25
ivvecreate a floating ip for it14:25
ivvei get server.project.example.com from the ptr14:25
ivvewhich is wierd14:25
ivveif it cannot get display_name or hostname, why does it end up there without errors14:25
ivveand why doesn't it use the format i assigned14:26
ivvecan't seem to find anything about it14:26
ivveis it a default from dns_name ?14:27
mugsieI am wondering how the PTR is created at all ...14:28
ivve:D14:28
mugsiedid you set something up in neutron as well?14:29
mugsie-sink by default only does A/AAAA records14:29
ivveaye14:29
ivveneutron.conf with the [designate] stanza like in the guide in the topic14:29
mugsieah, that is where the PTR is coming from14:30
mugsiethat does not allow cusotm formats - it takes dns_name.dns_domain as the format14:30
mugsieso you should have a server.project.example.com A record as well14:31
ivvei do14:31
fricklermugsie: o.k., spinning up a patch14:31
ivveso it doesn't allow custom names at all?14:31
mugsieno - it uses the data for dns_name14:32
mugsieyou could set custom info in dns_name, but thats it14:32
ivveis there any way to make dns_name a default? other than hostname14:32
ivvewithout user intervention at creation14:33
mugsienot that I know of14:33
ivveokay14:33
ivvewell a limitation then, i was chasing the whole format thing14:33
ivvewhat is the floating ip format used for then?14:34
ivveit doesn't create an additional a-record for it14:34
mugsiewhen you use the designate-sink handler, which is an old way to integrate designate and neutron14:34
openstackgerritJens Harbott (frickler) proposed openstack/designate master: Enable worker by default  https://review.openstack.org/64038314:35
ivvei see14:36
ivvemugsie: will the "old" way be obsolete or replaced with new functions to perform such naming in the future?14:38
mugsiefrickler: thanks14:39
mugsieivve: sink is unlikely to be replaced, and I am unaware of any proposed chnages in neutron14:39
mugsiea custom sink handler could so what you need though14:40
mugsiea basic one is here - https://github.com/openstack/designate/tree/master/contrib/designate-ext-samplehandler14:40
*** bnemec is now known as beekneemech14:46
*** awalende has quit IRC15:00
*** awalende has joined #openstack-dns15:00
*** awalende has quit IRC15:04
HD|Laptop*rant* so I have integrated designate with neutron now, following the guide @ https://docs.openstack.org/neutron/rocky/admin/config-dns-int-ext-serv.html#config-dns-int-ext-serv15:09
HD|LaptopI have added two zones a.mydomain.de, b.mydomain.de, and set the respective zones as dns-domain for network a and b15:09
HD|Laptopcreating a port in network a immediately creates a recordset, while creating a port in network b doesn't do *anything* in designate-*.log15:10
HD|Laptopwhat could cause this? the default domain in neutron.conf: dns_domain is b.mydomain.de15:11
*** ivve has quit IRC15:26
HD|Laptop... and updates for the (working) zone a.mydomain.de always only get triggered after the check in "Including zones with action UPDATE and PENDING older than 455s"15:30
mugsieHD|Laptop: is the b.mydomain.de in the same tenant as the netowkr set to use it?15:37
mugsieit sounds like there is an issue with mdns sending NOTIFY's - let me look15:38
HD|Laptopmugsie: I forgot to also enable zone-manager15:46
HD|Laptopthat makes the updates now immediate15:46
HD|Laptopbut b.mydomain.de still does not work15:46
HD|Laptopmugsie: all created with admin CLI credentials15:46
HD|Laptopthe networks have both the same project_id, and dito for the domain zones15:47
mugsiecan I see a "openstack network show" for the 2 of them?15:47
mugsieis there anything in the neutron logs?15:47
HD|Laptopmugsie: sure. http://paste.debian.net/1070877/15:50
mugsieah15:51
mugsieone is router:external15:51
mugsieis that the one that is working?15:51
mugsiehttps://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html#use-case-3-ports-are-published-directly-in-the-external-dns-service15:52
mugsiebrb15:52
HD|Laptopmugsie: that one with router:external is the one that is *not* working15:53
fricklerHD|Laptop: that is the expected, documented behaviour16:02
fricklerHD|Laptop: there is an open feature request for neutron to be more flexible in that regard, though16:03
mugsieah, I missed the extra docs that got added - https://docs.openstack.org/neutron/latest/admin/config-dns-int-ext-serv.html#configuration-of-the-externally-accessible-network-for-use-case-316:04
fricklerHD|Laptop: mugsie: https://bugs.launchpad.net/neutron/+bug/178487916:05
openstackLaunchpad bug 1784879 in neutron "Neutron doesn't update Designate with some use cases" [Wishlist,Triaged] - Assigned to Salvatore Orlando (salvatore-orlando)16:05
fricklerthat reminds me, time to unassign that bug due to lack of response16:06
HD|Laptopah, so that won't be possible at all? -.-16:09
HD|Laptopany way to get around this?16:09
HD|Laptopaside from calling "openstack recordlist create ..." by hand?16:09
mugsieHD|Laptop: right now, not really :/16:12
fricklerHD|Laptop: you might patch the neutron code yourself, see comment #2016:12
HD|Laptophmm. I wonder how hard it would be to add a new property to network objects - something like "force_external_dns", which would override that check.16:16
HD|Laptopfrickler: thanks for the hint - that works! thanks!16:18
*** kmalloc is now known as needscoffee16:22
*** irclogbot_0 has joined #openstack-dns16:53
openstackgerritcaoyuan proposed openstack/python-designateclient master: Update hacking version  https://review.openstack.org/62767116:56
*** ginopc has quit IRC16:57
*** ivve has joined #openstack-dns17:08
*** irclogbot_0 has quit IRC17:56
*** irclogbot_0 has joined #openstack-dns18:04
*** irclogbot_0 has quit IRC18:05
*** irclogbot_0 has joined #openstack-dns18:12
*** ivve has quit IRC18:39
*** Chealion has joined #openstack-dns18:43
*** awalende has joined #openstack-dns19:03
*** ircuser-1 has quit IRC19:03
*** ircuser-1 has joined #openstack-dns19:05
*** awalende_ has joined #openstack-dns19:05
*** awalende has quit IRC19:08
*** ivve has joined #openstack-dns19:47
*** irclogbot_0 has quit IRC19:50
*** irclogbot_0 has joined #openstack-dns20:03
*** salmankhan has quit IRC20:41
*** abaindur has joined #openstack-dns20:55
*** abaindur has quit IRC20:56
*** abaindur has joined #openstack-dns20:57
*** salmankhan has joined #openstack-dns21:09
*** salmankhan has quit IRC21:14
*** awalende has joined #openstack-dns21:21
*** awalende_ has quit IRC21:21
*** irclogbot_0 has quit IRC21:37
*** ivve has quit IRC22:16
*** awalende has quit IRC22:36
*** awalende has joined #openstack-dns22:36
*** awalende has quit IRC22:40
*** odyssey4me_ has joined #openstack-dns22:45
*** odyssey4me has quit IRC22:52
*** eglute has quit IRC22:52
*** timsim has quit IRC22:52
*** cjloader has quit IRC22:52
*** odyssey4me_ is now known as odyssey4me22:52
*** awalende has joined #openstack-dns23:02
*** frickler has quit IRC23:06
*** frickler has joined #openstack-dns23:06
*** abaindur has quit IRC23:20
*** awalende_ has joined #openstack-dns23:32
*** awalende has quit IRC23:35
*** abaindur has joined #openstack-dns23:36
*** awalende_ has quit IRC23:36
*** awalende has joined #openstack-dns23:37
*** awalende has quit IRC23:41

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