generate additional SRV records if port name is specified

[jdef]

related to #61

summary: if s task provides a discoveryInfo w/ named ports then mesos-dns will generate additional SRV records for those ports: _{di-port-name}._{task-name}._{protocol}.{framework}.{domain}.

[sargun]

Technically RFC non-compliant, but RFCs be damned, productivity ftw.

[jdef]

considering _{portname}._sub._{taskname}._{protocol} since it's just as expressive but probably more compat with existing tooling that understands dns-sd (not that we're super concerned about implementing dns-sd)

[jdef]

xref https://tools.ietf.org/html/rfc6763

[sargun]

I prefer the current patch. It's something we're already doing, and I think preserving the SRV-style records follows the principal of least surprise. If we choose to support dns-sd, I'd rather create both records.

[jdef]

understood. i still modified the current patch to simply prepend a
_portname if there is one. so it's possible to get
_portname._taskname._protocol .. but still think that's ok

On Wed, Mar 2, 2016 at 4:37 PM, Sargun Dhillon notifications@github.com
wrote:

I prefer the current patch. It's something we're already doing, and I
think preserving the SRV-style records follows the principal of least
surprise. If we choose to support dns-sd, I'd rather create both records.

—
Reply to this email directly or view it on GitHub
#386 (comment).

[sargun]

Is there any reason to reuse records, and do this in place? Does Golang actually care that much or optimize that much do this in place? Can we just create another slice, and populate that? I think that would make this code much easier to read.

[jdef]

this can be more efficient if the underlying capacity of the slice is
large enough to hold twice the record count. in this particular instance it
depends how golang is allocating the initial slice for varargs parameter.
experiments on playground suggest that it allocates a slice w/ a capacity
equivalent to the # of variadic params.

even so, I'm loath to changing this line: it's concise and idiomatic.

On Thu, Mar 3, 2016 at 1:00 PM, Sargun Dhillon notifications@github.com
wrote:

In records/chains.go
#386 (comment):

+const (

• protocolNone = "" // for readability
• domainNone = "" // for readability
  +)

+// withProtocol appends ._{protocol}.{framework} to records. if protocol is "" then
+// the protocols "tcp" and "udp" are assumed.
+func withProtocol(protocol, framework string, spec labels.Func, gen chain) chain {

• return func(records ...string) {

•   protocol = spec(protocol)
  

•   if protocol != protocolNone {
  

•       for i := range records {
  

•           records[i] += "._" + protocol + "." + framework
  

•       }
  

•   } else {
  

•       records = append(records, records...)
  

Is there any reason to reuse records, and do this in place? Does Golang
actually care that much or optimize that much do this in place? Can we just
create another slice, and populate that? I think that would make this code
much easier to read.

—
Reply to this email directly or view it on GitHub
https://github.com/mesosphere/mesos-dns/pull/386/files#r54919995.

[sargun]

So, I like FP, but the lambda passing doesn't seem as idiomatic (in go) that I hoped for. I found the code really hard to read, but I don't think that's a matter of code-quality, I think that it's just a matter of statements like:

// withNamedPort prepends a `_{discoveryInfo port name}.` to records
func withNamedPort(portName string, spec labels.Func, gen chain) chain {
    portName = spec(portName)
    if portName == "" {
        return gen
    }
    return func(records ...string) {
        // generate without port-name prefix
        gen(records...)

        // generate with port-name prefix
        for i := range records {
            records[i] = "_" + portName + "." + records[i]
        }
        gen(records...)
    }
}

-- and since it's passing around lambdas that all have the same type signature / name, and doing all of the manipulations of data types in place, it makes it difficult to follow. I'm not saying we should change it, I'm just wondering if we have a better way to structure this flow.

I'm curious as to whether using goroutines as generators, and channels to wire them all up might be a better option. I know that's less efficient, but as a general pattern I like it, and since you're only processing one item at a time, it should be memory efficient, and not require interesting scheduling.

[sargun]

lgtm.

[jdef]

thanks @sargun. bombs away