Yes, thanks for these additions Adam - much appreciated. …and while we are at it, we will also remove the `slavePreLaunchDockerHook` which is equally superseded by that new hook.
> On Nov 29, 2016, at 7:46 PM, Adam Bordelon <a...@mesosphere.io> wrote: > > + dev@, in case some module developers haven't joined the modules@ list yet. > So this will require code changes (and a recompile) so any module > implementing the previous hook must now use the new hook, potentially > updating to set both environments instead of just the one. Such a hook > compiled against Mesos 1.1 will not work anymore with Mesos 1.2. > > On Tue, Nov 29, 2016 at 10:15 AM, Till Toenshoff <toensh...@me.com> wrote: > >> Hey Folks, >> >> we are removing the slave sided, docker specific hook callback ` >> slavePreLaunchDockerEnvironmentDecorator` and replace it with ` >> slavePreLaunchDockerTaskExecutorDecorator`. >> >> The latter now allows setting two individual environments, one effective >> for the task and one for the executor. Note that as usual, a custom >> executor itself may still decide to make (parts of) the executor >> environment available to its task/s. >> >> We decided to use a protobuf message return signature for that hook, >> allowing us to add things like e.g. volumes without having to come up with >> another hook callback — see discussion around https://issues.apache.org/ >> jira/browse/MESOS-6396?focusedCommentId=15654316&page=com.atlassian.jira. >> plugin.system.issuetabpanels:comment-tabpanel#comment-15654316. >> >> The changes involved should have no extra side-effects - your >> functionality is unaffected if you don't use custom hooks. >> >> Please remember that hooks are still considered experimental and may still >> evolve fast. >> >> >> Let me know what you think! >> >> Till
