14:13:39 #startmeeting Designate 14:13:40 Meeting started Wed Mar 7 14:13:39 2018 UTC and is due to finish in 60 minutes. The chair is mugsie. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:13:41 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:13:43 The meeting name has been set to 'designate' 14:13:46 #topic Roll Call 14:14:05 sorry about the late start, I am missing days :/ 14:15:06 ;-) 14:16:36 anseo 14:16:58 #topic Bug Triage 14:17:18 #link https://bugs.launchpad.net/designate/+bugs?search=Search&field.status=New 14:17:46 #link https://bugs.launchpad.net/designate/+bug/1753503 14:17:47 Launchpad bug 1753503 in Designate "Policy check failed for rule 'update_service_status' " [Undecided,New] 14:18:00 I am confused by ^ 14:18:47 the policy name is wrong, but it should not block quota updates 14:19:41 maybe the "update_service_service_status" causes an error loading the entire policy file? 14:20:26 maybe ... I dont run it with any policy file now that defaults are in code 14:20:41 #link https://bugs.launchpad.net/designate/+bug/1752349 14:20:42 Launchpad bug 1752349 in Designate "Infoblox driver get_dns_view error after changing multi_tenant option" [Undecided,New] 14:21:11 seems legit 14:21:38 #link https://bugs.launchpad.net/designate/+bug/1746836 14:21:39 Launchpad bug 1746836 in Designate "designate-manage does not migrate designate_pdns DB from PowerDNS 3.x to 4.x version DB Schema" [Undecided,New] 14:21:39 Yep, sounds very plausible 14:21:59 I marked the infoblox one as triaged, and added low-hanging-fruit tag 14:22:22 for this db migration - we stopped shipping a schema, as we no longer need a custom one 14:22:49 So is it now possible/easy to migrate from PowerDNS 3.x to PowerDNS 4.x? 14:22:49 our docs now tell people to install the pdns backend as directed by the pdns docs 14:23:04 possible, yes, easy - no 14:23:57 oh, it seems pdns4 can read a pdns3 db 14:24:03 so, yes 14:24:46 Cool 14:25:11 #link https://bugs.launchpad.net/designate/+bug/1746627 14:25:11 Launchpad bug 1746627 in Designate "Reverse floating IP records are removed when floating IP is deleted" [Undecided,New] 14:25:39 this is the old PTR integration 14:26:01 Subject seems wrong… probably means "…NOT removed when…" ? 14:26:22 I *think* we would need a new -sink module to listen for floating-ip-delete messages and delete PTR records when the floating IP is removed 14:26:33 simon-AS559: yea, I just updated it :) 14:28:10 Does the new integration handle this better? 14:28:42 yeah, neutron manages the PTR record itself, and updates / deletes it as it moves around 14:29:31 OK. I'll take the bug and will try to formulate a reply based on that. 14:29:41 simon-AS559: sweet 14:30:11 Oops, took the wrong one (pDNS 3->4 previous). 14:30:19 Well I guess I'll take them both. 14:31:17 even better :) 14:31:23 #topic Back Ports 14:31:27 #link http://paste.openstack.org/show/693655/ 14:32:08 have a look at ^ and see if there is anything that should be back ported to queens / pike / ocata 14:34:58 there doesn't seem to be any changes that are not already proposed as backports 14:35:24 #topic Open Discussion 14:36:12 mugsie Thanks a lot for your patience onboarding me at the PTG, it was great. 14:36:31 simon-AS559: no problem, its good to have engaged users 14:36:44 and people who want to help dev are even better :) 14:38:34 any other topics? 14:38:42 API TXT records string handling related to RFC1035 14:38:47 mugsie: browny_: we have a question on SPF/TXT records. Possibly a bug recently encountered. 14:38:54 sure 14:39:02 The length restriction? 14:39:11 sort of 14:39:15 we run in trouble 14:39:23 the handling of " " empty spaces 14:39:35 in SPF and TXT 14:40:16 Empty spaces within strings inside TXT records should be handled correctly. 14:40:27 yes, if the string is quoted 14:40:28 oh ... I think I remember a bug like this 14:40:28 What Designate currently doesn't handle are multi-string TXT records. 14:41:06 Actually when you have a space within an unquoted string, in reality you have two strings 14:41:11 (TXT records can contain multiple strings) 14:41:16 but if the string is not quoted then it ends up as a multi quotes string without spaces 14:41:31 multi-string is another problem, even under <255 the use of empty spaces in TXT/SPF is possible only if we explicitly quote the record during creation 14:42:01 diman: is this using "--records" or "--record" 14:42:45 mugsie: I've checked --records= 14:43:14 OK - that does seem like a bug 14:43:44 mugsie: so, doing like: openstack recordset create --records="v=spf1 a mx a:mail.domain.com a:mail.domain.ie a:server5.somedomain.com a:server7.somedomain.com mx:server95.somedomain.com include:thatdomain.com ip4:192.168.0.1 ip4:192.168.0.2 ip4:192.168.03 ip4:192.168.0.4 ip4:192.168.0.04 -all" --type="SPF" 02464c06-f04d-4cd2-b8ac-6a216bdf0eea xxx.somedomain.com 14:44:12 will not result in correct SPF 14:44:26 when asking bind directly via dig 14:44:48 but, if we double quote with '" record here "' 14:45:26 that will result in proper reply 14:45:31 oh 14:45:38 that seems like an API parse error 14:45:49 OK, can you file that bug? 14:46:09 mugsie: sure, will do than 14:46:24 I would start looking at the API and adaptor code to find how it is getting parsed inside designate 14:46:31 question is, should API follow e.g. RFC1035 14:46:48 is expressed in one or two ways: as a contiguous set 14:46:48 of characters without interior spaces, or as a string beginning with a " 14:46:48 and ending with a ". 14:46:50 regarding: 14:47:09 yes, it should 14:47:10 so strings with spaces require a "s 14:47:38 and as the person who wrote the parsing code I am 99% sure it is not doing that at the moment 14:47:58 That leaves 1% :-) 14:48:04 well we will fix it then 14:48:51 \o/ 14:49:12 if you need help just shout on the mailing list / #openstack-dns 14:50:27 the question is: should designate api reply with error if the record has empty spaces, but not enclosed into " " explicitly? or should it handle those cases automatically? 14:50:48 because RFC 1035 is kind of saying 14:51:03 is expressed in one or two ways: 14:51:10 I think so 14:51:27 as a contiguous set of characters without interior spaces 14:51:38 - which works fine now 14:52:09 or as a string beginning with a " and ending with a ". Inside a " 14:52:09 delimited string any character can occur, except for a " itself 14:52:25 Yes, it would be good to signal an error in this case. 14:52:38 which also works - if you explicitly wrap the record with spaces with quotes... 14:54:45 yeah, I think we accept quoted strings with spaces, and if someone POSTs a string with spaces, it gets taken as a set of strings 14:55:17 exactly 14:55:57 from the user perspective it is not intuitive that SPF/TXT should have extra quotes if spaces are there 14:56:32 true 14:57:03 no 14:57:03 but, we have stuck to RFCs over UX in the past 14:57:03 (like the "." at the end of zone names) 14:57:32 mugsie: yes, that's why there is a question 14:57:40 API should be RFC conform 14:57:57 CLI or UI can have a better UX 14:58:04 browny_: ++ 14:58:26 should this be fixed on cli / dashboard level 14:59:00 API should give error bassed on API -> spaces no quotes -> error 14:59:16 CLI can be made nice for the user... 14:59:23 yes, and with the work that frickler did to add "--record" we should use that to help build the payload 15:02:29 OK, any other topics? we are just about out of time 15:03:12 OK, time is up :) 15:03:15 #endmeeting