Use MARATHON_SCHEME_PORT label to define scheme of a given port

[clems4ever]

The links in the tasks view use the same scheme as the Marathon UI
web application but in some cases users expose a service with a
different scheme on a given port.

In order to correctly redirect the user clicking on the link of a given
port, one can use MARATHON_SCHEME_PORT and MARATHON_SCHEME_PORT
labels to define the scheme of the all the ports and/or the scheme of port
with index N. The available values for those labels are 'http' and 'https'.

If no label is provided, the scheme is the same as Marathon UI scheme to
avoid breaking compatibility.

[orlandohohmeier]

@clems4ever please excuse the super late response – I was rather busy in the last couple of weeks and didn't found much time to review PRs. I'll look into this one tomorrow morning; once I had a chance to sync with the Marathon team as I'm not sure how to set and configure MARATHON_SCHEME_PORT and I want to properly test this feature before approving it.

[clems4ever]

@orlandohohmeier , thank you for the update.

MARATHON_SCHEME_PORT is a label name that, if provided, must contain 'http' or 'https' to define what is the scheme of the service exposed. If different ports of the same application has various schemes, one can define it by port index by providing the label called MARATHON_SCHEME_PORT where is the index of a given port.

This is a basic implementation that I think is the same in DCOS. However, my colleague @pierrecdn proposed to use health checks to automatically detect the scheme of a given port. I will do the change for our company and post a dedicated PR here in case other people are interested.

Thanks.

[clems4ever]

@orlandohohmeier , any news regarding this PR?

[orlandohohmeier]

@clems4ever I might have misread your comment, as I was under the impression that you're only posting the PR in case other people are interested. My thinking was that we keep the PR open for some time to see whether others would be interested in such a feature and then either move the PR forward or close it. I probably should have communicated my think earlier and am sorry if I indeed misunderstood things.

Given that no one else raised interested so far and that the proposed functionality is relying on a label which doesn't provide any guarantees I'd vote to close the PR. To enable such a feature in a controlled way e.g. by utilizing marathon-lb or some other frameworks labels and info I'd propose to add a plugin mount and or action so that one can dynamically add the resp. functionality based on the environment. What do you think?