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