record generation is too aggressive w/ respect to tasks with dots in their name

[jdef]

for example, marathon will create tasks for deployment groups with names like a.b.c or member.team.org. currently the dns952 label package converts these dots to dashes. for example, a a task named "a.b.c" is transformed to "a-b-c". this facilitates SRV record construction based on task name such that task a.b.c has an srv record of _a-b-c._tcp.{some-domain-suffix}.

@ConnorDoyle says that a better transformation would generate an srv record named _a._tcp.b.c.{some-domain-suffix}. this would preserve the naming hierarchy established by the framework. it also allows each framework to be responsible for the uniqueness of task names, instead of clobbering the task name in transformation like we currently do.

@kozyraki what are your thoughts?

[kozyraki]

I don't think it's worth putting much effort in the current naming scheme. We should put more thought in the naming scheme proposed using the discovery info. Look at the google doc and make comments. Stefan is just starting with it.

On May 1, 2015, at 6:13 PM, James DeFelice [email protected] wrote:

for example, marathon will create tasks for deployment groups with names like a.b.c or member.team.org. currently the dns952 label package converts these dots to dashes. for example, a a task named "a.b.c" is transformed to "a-b-c". this facilitates SRV record construction based on task name such that task a.b.c has an srv record of _a-b-c._tcp.{some-domain-suffix}.

@ConnorDoyle says that a better transformation would generate an srv record named _a._tcp.b.c.{some-domain-suffix}. this would preserve the naming hierarchy established by the framework. it also allows each framework to be responsible for the uniqueness of task names, instead of clobbering the task name in transformation like we currently do.

@kozyraki what are your thoughts?

—
Reply to this email directly or view it on GitHub.

[kozyraki]

@jdef I think long term we will be fine because users will be able to configure naming.

Short term, we have a few choices:

• leave it as is for now
• take back the conversion of "." to "-". To avoid confusion, we can roll out the _ep name for the service now, rather than later.

Opinions?

[tsenart]

Link #230

[jdef]

xref #168

[jdef]

not sure that we can actually change the name generation scheme at this point w/o breaking TONS of people, therefore closing this out