I have two questions.

First, does this change include the executor library? We currently use
environment variables to propagate various config values from an agent to
executors. If it does, what is the alternative?

Second, what will be the preferred way to pass config values to executors?
It would be great to be able to do it uniformly for non-HTTP and HTTP
executors. I can think of several possibilities: cmd flags, adding or
overriding protobufs, extending Executor interface.

On Tue, Mar 8, 2016 at 9:21 PM, Gilbert Song <gilb...@mesosphere.io> wrote:

> Yes, `LIBPROCESS_IP` will be excepted from this change. We will still have
> `LIBPROCESS_IP` set and passed to executors' environment, which is for the
> case that DNS is not available on the slave.
>
> Gilbert
>
> On Tue, Mar 8, 2016 at 11:57 AM, Zhitao Li <zhitaoli...@gmail.com> wrote:
>
>> Is LIBPROCESS_IP going to be an exception to this? Some executors are
>> using this variable as an alternative of implementing their own IP
>> detection logic AFAIK so this behavior would break them.
>>
>> On Tue, Mar 8, 2016 at 11:33 AM, Gilbert Song <gilb...@mesosphere.io>
>> wrote:
>>
>>> Hi,
>>>
>>> TL;DR Executors will no longer inherit environment variables from the
>>> agent by default in 0.30.
>>>
>>> Currently, executors are inheriting environment variables form the agent
>>> in mesos containerizer by default. This is an unfortunate legacy behavior
>>> and is insecure. If you do have environment variables that you want to pass
>>> to the executors, you can set it explicitly by using the
>>> `--executor_environment_variables` agent flag.
>>>
>>> Starting from 0.30, we will no longer allow executors to inherit
>>> environment variables from the agent. In other words,
>>> `--executor_environment_variables` will be set to “{}” by default. If you
>>> do depend on the original behavior, please set
>>> `--executor_environment_variables` flag explicitly.
>>>
>>> Let us know if you have any comments or concerns.
>>>
>>> Thanks,
>>> Gilbert
>>>
>>
>>
>>
>> --
>> Cheers,
>>
>> Zhitao Li
>>
>
>

Reply via email to