Add flag to define Marathon PORT prefix

[MikeMichel]

Marathon overrrides the PORT env inside the container. This can be a nice feature but is also causing trouble if you need to connect to the port the container app did set to PORT.

A flag to set env prefix for the ports marathon sets would solve this.

[sttts]

The question is where to define this? In the AppDefinition or globally (as suggested on the mailing list). To keep Marathon jsons portable between installations, I would vote for the AppDefinition.

[MikeMichel]

Maybe a mix makes sense. Set it global with a marathon start parameter but it still can be overwritten in a json app definition.

[kolloch]

@MikeMichel just to check if I understood it correctly: you are talking about environment variable name clashes, right? So if you have a container which also uses the PORT variable for some other meaning, you currently have a problem. To prevent that, you want to be able to configure a prefix like "MARATHON_" such that all environment variables set by marathon are prefixed with it, e.g. PORT becomes MARATHON_PORT, PORT0 becomes MARATHON_PORT0 etc.

Correct?

[MikeMichel]

Hi,

right. Apps like nodejs usually do a process.env.PORT just to name one. One of the last official elasticsearch containers also had this problem. A prefix would prevent this.

[kolloch]

I guess, we should have prefixed all automatic variables with MARATHON_ from the beginning.

In my opinion, we should definitely enable defining this per AppDefinition since a global setting would potentially invalidate existing app configurations. That would also allow migration of the config on a per app basis.

We can either make the prefix port variable specific or more general.

What would be a good name for a general prefix attribute of the app definition? "automaticEnvVarsPrefix" is maybe a bit verbose. "envAutoVarsPrefix"?

I guess the setting should not effect

• MESOS_TASK_ID
• MARATHON_APP_ID
• MARATHON_APP_VERSION

since they are already prefixed.

All ports related variables should be prefixed.

We also set HOST. Should we also prefix that?

I would like to hear the opinion of @drexin and @ConnorDoyle about that as well.

[MikeMichel]

@kolloch is there a time frame to get this done?

[MikeMichel]

@kolloch 0.10.0 seems to be far away. could you give me a hint where to disable this override in the source code?

[kolloch]

Hi @MikeMichel ,

unfortunately, you are absolutely right because many things in 0.10.0 will actually be shifted to even later releases.

The code is in TaskBuilder.scala. Search for PORT.

Does it help you to make this a global setting (since that's easier to do)? That might make migrations difficult, though.

[MikeMichel]

yes, a global setting would be absolutely fine.