[
https://issues.apache.org/jira/browse/MESOS-3340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14744093#comment-14744093
]
Marco Massenzio commented on MESOS-3340:
----------------------------------------
Awesome - we all seem to be all in agreement; how about we drop a line to the
user@ mailing list, alerting of the impending change and see if anyone raises
objections and/or identifies some use cases that we may have missed?
As the scenario [~mcypark] outlined is exactly the one I had in mind and that
seems the most commonly encountered, I think it should be relatively
uncontroversial a change - but better move with caution here, as we risk
breaking a few folks' deployment scripts here...
Thanks, fellas!
> Command-line flags should take precedence over OS Env variables
> ---------------------------------------------------------------
>
> Key: MESOS-3340
> URL: https://issues.apache.org/jira/browse/MESOS-3340
> Project: Mesos
> Issue Type: Improvement
> Components: stout
> Affects Versions: 0.24.0
> Reporter: Marco Massenzio
> Assignee: Klaus Ma
> Labels: mesosphere, tech-debt
>
> Currently, it appears that re-defining a flag on the command-line that was
> already defined via a OS Env var ({{MESOS_*}}) causes the Master to fail with
> a not very helpful message.
> For example, if one has {{MESOS_QUORUM}} defined, this happens:
> {noformat}
> $ ./mesos-master --zk=zk://192.168.1.4/mesos --quorum=1
> --hostname=192.168.1.4 --ip=192.168.1.4
> Duplicate flag 'quorum' on command line
> {noformat}
> which is not very helpful.
> Ideally, we would parse the flags with a "well-known" priority (command-line
> first, environment last) - but at the very least, the error message should be
> more helpful in explaining what the issue is.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
