Re: Review Request 46897: Use `gdebi` for auto dep resolution.

2016-05-02 Thread Joshua Cohen 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46897/#review131355
---


Ship it!




Ship It!

- Joshua Cohen


On May 2, 2016, 6:14 p.m., John Sirois wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46897/
> ---
> 
> (Updated May 2, 2016, 6:14 p.m.)
> 
> 
> Review request for Aurora, Benjamin Staffin and Joshua Cohen.
> 
> 
> Bugs: AURORA-1687
> https://issues.apache.org/jira/browse/AURORA-1687
> 
> 
> Repository: aurora-packaging
> 
> 
> Description
> ---
> 
> This makes us more robust to upstream packaging changes.  The `gdebi`
> tool gives us `apt-get install` dependency calculation, fetching and
> install for a local deb package.
> 
>  builder/deb/debian-jessie/Dockerfile |  5 +++--
>  builder/deb/ubuntu-trusty/Dockerfile | 11 ++-
>  2 files changed, 9 insertions(+), 7 deletions(-)
> 
> 
> Diffs
> -
> 
>   builder/deb/debian-jessie/Dockerfile 
> 50b50817ba24db6b226e30746064627b79152aff 
>   builder/deb/ubuntu-trusty/Dockerfile 
> 21617e79927af6c529ae0e0f2e47b027989444ac 
> 
> Diff: https://reviews.apache.org/r/46897/diff/
> 
> 
> Testing
> ---
> 
> Locally before [this 
> fix](https://github.com/benley/gradle-packaging/commit/d5388990bf2daa85f40bd09259373e5360018249)
> ```
> ./build-artifact.sh builder/deb/ubuntu-trusty /tmp/snapshot.tar.gz 
> 0.13.1-SNAPSHOT
> ```
> 
> Observed the java 7 package get pulled to satisfy the java-runtime
> dependency of the gradle package.  Not ideal, but it allowed the build
> to succeed since we control the default java (used by gradle) with
> `update-alternatives` higher in the `Dockerfile`.
> 
> 
> Thanks,
> 
> John Sirois
> 
>

Re: Review Request 46835: Add client and scheduler support for launching tasks using the Mesos unified containerizer

2016-05-02 Thread Joshua Cohen 


> On May 2, 2016, 2:54 p.m., John Sirois wrote:
> > src/main/python/apache/aurora/config/schema/base.py, line 172
> > 
> >
> > The MesosJob is trending more and more towards a c-style union, 
> > different parts of the config are active depending on the setup and its not 
> > clear which except by reading docs carefully.  I put some effort towards 
> > supporting nicer pystachio evolution in an experiment documented in [this 
> > review feedback](https://reviews.apache.org/r/44745/) and there is a [new 
> > release](https://github.com/wickman/pystachio/releases) not used by Aurora 
> > yet that supports Choice fields.  It seems like work along these lines 
> > would be useful to stop the bleeding in general.  I'm not sure if that 
> > should of work should be coupled to this review though.
> 
> Joshua Cohen wrote:
> Oh, I didn't realize that `Choice` support landed in pystachio, that's 
> awesome! I think that making it explicit that you can specify either a 
> `Container` or an `Image` is, in general, a good thing. That said, thinking 
> it through further, the `Image` is not mutually exclusive with the container. 
> It's mutually exclusive with a docker container. What if instead of changing 
> job config such that you have to choose either a `Container` or an `Image`, I 
> instead just added a mesos property to the container struct and made `Image` 
> a property there? That more accurately reflects what's going on under the 
> covers (i.e. when specifying an `Image` on the job, what we're really doing 
> is using the MesosContainerizer and telling it to load that image).
> 
> John Sirois wrote:
> I think you mean this:
> ```thrift
> class AppcImage(Struct):
>   name = Required(String)
>   image_id = Required(String)
> 
> 
> class DockerImage(Struct):
>   name = Required(String)
>   tag = Required(String)
> 
> 
> class Mesos(Struct):
>   image = Image
> 
> 
> class Container(Struct):
>   docker = Docker
>   mesos = Mesos  
> ```
> 
> Which sounds ok.  I really don't like the `Container.(docker|mesos)` and 
> `Image.(appc|docker)` c-style union thing, but that could continue to be 
> deferred to a scoped upgrade to pystachio 0.8.1 + instroduce new Choice 
> fields deprecating the current situation.

Yes, that's what I'm suggesting. However, in retrospect, there's probably no 
reason *not* to pull in pystachio 0.8.1 to enable this to be a choice from the 
start. At least in that case the deprecation is only for Docker users, and 
people who adopt the unified containerizer won't have to deal with a 
deprecation down the line.

I can do the same on the thrift side as well, get rid of the TaskConfig.Image 
and add an optional Image to the existing MesosContainer.


- Joshua


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46835/#review131153
---


On April 29, 2016, 4:22 p.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46835/
> ---
> 
> (Updated April 29, 2016, 4:22 p.m.)
> 
> 
> Review request for Aurora, John Sirois, Maxim Khutornenko, and Bill Farner.
> 
> 
> Bugs: AURORA-1636, AURORA-1637, AURORA-1638, and AURORA-1639
> https://issues.apache.org/jira/browse/AURORA-1636
> https://issues.apache.org/jira/browse/AURORA-1637
> https://issues.apache.org/jira/browse/AURORA-1638
> https://issues.apache.org/jira/browse/AURORA-1639
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> A few notes:
> 
> 1. It's not possible to configure Mesos 0.27.x to launch docker tasks due to 
> a bug in parsing the docker_store_dir flag. Fixed here: 
> https://reviews.apache.org/r/43451/ but has not been backported to Mesos 
> 0.27. This means we can only launch tasks that use AppC images until we 
> upgrade our Mesos dependency to 0.28.x. The good news is I've confirmed that 
> launching tasks with Docker images *does* work by using Aurora linked against 
> 0.27.x but running Mesos 0.28.x in Vagrant.
> 1. In order to work around the setuid issues (i.e. task is launched as root, 
> but the executor cannot setuid because the role-user does not exist), I've 
> mounted /etc/passwd and /etc/group into the container and added a new flag, 
> `thermos_run_as_job_role`, to the scheduler. This flag is only used when 
> launching a task with a filesystem image, and causes us to add 
> `--execute-as-user ` to the thermos executor commandline.
> 1. The Mesos unified containerizer does not automatically create mount points 
> in the filesystem from the image. It expects the full path to the mount to 
> ex

Re: Review Request 46835: Add client and scheduler support for launching tasks using the Mesos unified containerizer

2016-05-02 Thread John Sirois 


> On May 2, 2016, 8:54 a.m., John Sirois wrote:
> > src/main/python/apache/aurora/config/schema/base.py, line 172
> > 
> >
> > The MesosJob is trending more and more towards a c-style union, 
> > different parts of the config are active depending on the setup and its not 
> > clear which except by reading docs carefully.  I put some effort towards 
> > supporting nicer pystachio evolution in an experiment documented in [this 
> > review feedback](https://reviews.apache.org/r/44745/) and there is a [new 
> > release](https://github.com/wickman/pystachio/releases) not used by Aurora 
> > yet that supports Choice fields.  It seems like work along these lines 
> > would be useful to stop the bleeding in general.  I'm not sure if that 
> > should of work should be coupled to this review though.
> 
> Joshua Cohen wrote:
> Oh, I didn't realize that `Choice` support landed in pystachio, that's 
> awesome! I think that making it explicit that you can specify either a 
> `Container` or an `Image` is, in general, a good thing. That said, thinking 
> it through further, the `Image` is not mutually exclusive with the container. 
> It's mutually exclusive with a docker container. What if instead of changing 
> job config such that you have to choose either a `Container` or an `Image`, I 
> instead just added a mesos property to the container struct and made `Image` 
> a property there? That more accurately reflects what's going on under the 
> covers (i.e. when specifying an `Image` on the job, what we're really doing 
> is using the MesosContainerizer and telling it to load that image).

I think you mean this:
```thrift
class AppcImage(Struct):
  name = Required(String)
  image_id = Required(String)


class DockerImage(Struct):
  name = Required(String)
  tag = Required(String)


class Mesos(Struct):
  image = Image


class Container(Struct):
  docker = Docker
  mesos = Mesos  
```

Which sounds ok.  I really don't like the `Container.(docker|mesos)` and 
`Image.(appc|docker)` c-style union thing, but that could continue to be 
deferred to a scoped upgrade to pystachio 0.8.1 + instroduce new Choice fields 
deprecating the current situation.


- John


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46835/#review131153
---


On April 29, 2016, 10:22 a.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46835/
> ---
> 
> (Updated April 29, 2016, 10:22 a.m.)
> 
> 
> Review request for Aurora, John Sirois, Maxim Khutornenko, and Bill Farner.
> 
> 
> Bugs: AURORA-1636, AURORA-1637, AURORA-1638, and AURORA-1639
> https://issues.apache.org/jira/browse/AURORA-1636
> https://issues.apache.org/jira/browse/AURORA-1637
> https://issues.apache.org/jira/browse/AURORA-1638
> https://issues.apache.org/jira/browse/AURORA-1639
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> A few notes:
> 
> 1. It's not possible to configure Mesos 0.27.x to launch docker tasks due to 
> a bug in parsing the docker_store_dir flag. Fixed here: 
> https://reviews.apache.org/r/43451/ but has not been backported to Mesos 
> 0.27. This means we can only launch tasks that use AppC images until we 
> upgrade our Mesos dependency to 0.28.x. The good news is I've confirmed that 
> launching tasks with Docker images *does* work by using Aurora linked against 
> 0.27.x but running Mesos 0.28.x in Vagrant.
> 1. In order to work around the setuid issues (i.e. task is launched as root, 
> but the executor cannot setuid because the role-user does not exist), I've 
> mounted /etc/passwd and /etc/group into the container and added a new flag, 
> `thermos_run_as_job_role`, to the scheduler. This flag is only used when 
> launching a task with a filesystem image, and causes us to add 
> `--execute-as-user ` to the thermos executor commandline.
> 1. The Mesos unified containerizer does not automatically create mount points 
> in the filesystem from the image. It expects the full path to the mount to 
> exist in the image. For /etc/passwd and /etc/groups this is not a problem, 
> but for the announcer acls file it was. I ended up moving the announcer acl 
> file into its own directory and mount that instead. In conjunction with this 
> I also had to modify our http_example Dockerfile to explicitly create that 
> mount point. A case could be made for sticking with the current path and just 
> creating an empty file in the image, I felt that creating an empty directory 
> was slightly less gross. This is tracked by 
> https://issues.apache.org/jira/browse/MESOS-5229.
> 1. The AppC image for end to end tests is created by runni

Re: Review Request 46897: Use `gdebi` for auto dep resolution.

2016-05-02 Thread Benjamin Staffin 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46897/#review131343
---


Ship it!




Ship It!

- Benjamin Staffin


On May 2, 2016, 11:14 a.m., John Sirois wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46897/
> ---
> 
> (Updated May 2, 2016, 11:14 a.m.)
> 
> 
> Review request for Aurora, Benjamin Staffin and Joshua Cohen.
> 
> 
> Bugs: AURORA-1687
> https://issues.apache.org/jira/browse/AURORA-1687
> 
> 
> Repository: aurora-packaging
> 
> 
> Description
> ---
> 
> This makes us more robust to upstream packaging changes.  The `gdebi`
> tool gives us `apt-get install` dependency calculation, fetching and
> install for a local deb package.
> 
>  builder/deb/debian-jessie/Dockerfile |  5 +++--
>  builder/deb/ubuntu-trusty/Dockerfile | 11 ++-
>  2 files changed, 9 insertions(+), 7 deletions(-)
> 
> 
> Diffs
> -
> 
>   builder/deb/debian-jessie/Dockerfile 
> 50b50817ba24db6b226e30746064627b79152aff 
>   builder/deb/ubuntu-trusty/Dockerfile 
> 21617e79927af6c529ae0e0f2e47b027989444ac 
> 
> Diff: https://reviews.apache.org/r/46897/diff/
> 
> 
> Testing
> ---
> 
> Locally before [this 
> fix](https://github.com/benley/gradle-packaging/commit/d5388990bf2daa85f40bd09259373e5360018249)
> ```
> ./build-artifact.sh builder/deb/ubuntu-trusty /tmp/snapshot.tar.gz 
> 0.13.1-SNAPSHOT
> ```
> 
> Observed the java 7 package get pulled to satisfy the java-runtime
> dependency of the gradle package.  Not ideal, but it allowed the build
> to succeed since we control the default java (used by gradle) with
> `update-alternatives` higher in the `Dockerfile`.
> 
> 
> Thanks,
> 
> John Sirois
> 
>

Review Request 46897: Use `gdebi` for auto dep resolution.

2016-05-02 Thread John Sirois 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46897/
---

Review request for Aurora, Benjamin Staffin and Joshua Cohen.


Bugs: AURORA-1687
https://issues.apache.org/jira/browse/AURORA-1687


Repository: aurora-packaging


Description
---

This makes us more robust to upstream packaging changes.  The `gdebi`
tool gives us `apt-get install` dependency calculation, fetching and
install for a local deb package.

 builder/deb/debian-jessie/Dockerfile |  5 +++--
 builder/deb/ubuntu-trusty/Dockerfile | 11 ++-
 2 files changed, 9 insertions(+), 7 deletions(-)


Diffs
-

  builder/deb/debian-jessie/Dockerfile 50b50817ba24db6b226e30746064627b79152aff 
  builder/deb/ubuntu-trusty/Dockerfile 21617e79927af6c529ae0e0f2e47b027989444ac 

Diff: https://reviews.apache.org/r/46897/diff/


Testing
---

Locally before [this 
fix](https://github.com/benley/gradle-packaging/commit/d5388990bf2daa85f40bd09259373e5360018249)
```
./build-artifact.sh builder/deb/ubuntu-trusty /tmp/snapshot.tar.gz 
0.13.1-SNAPSHOT
```

Observed the java 7 package get pulled to satisfy the java-runtime
dependency of the gradle package.  Not ideal, but it allowed the build
to succeed since we control the default java (used by gradle) with
`update-alternatives` higher in the `Dockerfile`.


Thanks,

John Sirois

Re: Review Request 46835: Add client and scheduler support for launching tasks using the Mesos unified containerizer

2016-05-02 Thread Joshua Cohen 


> On May 2, 2016, 2:54 p.m., John Sirois wrote:
> > src/main/python/apache/aurora/config/schema/base.py, line 172
> > 
> >
> > The MesosJob is trending more and more towards a c-style union, 
> > different parts of the config are active depending on the setup and its not 
> > clear which except by reading docs carefully.  I put some effort towards 
> > supporting nicer pystachio evolution in an experiment documented in [this 
> > review feedback](https://reviews.apache.org/r/44745/) and there is a [new 
> > release](https://github.com/wickman/pystachio/releases) not used by Aurora 
> > yet that supports Choice fields.  It seems like work along these lines 
> > would be useful to stop the bleeding in general.  I'm not sure if that 
> > should of work should be coupled to this review though.

Oh, I didn't realize that `Choice` support landed in pystachio, that's awesome! 
I think that making it explicit that you can specify either a `Container` or an 
`Image` is, in general, a good thing. That said, thinking it through further, 
the `Image` is not mutually exclusive with the container. It's mutually 
exclusive with a docker container. What if instead of changing job config such 
that you have to choose either a `Container` or an `Image`, I instead just 
added a mesos property to the container struct and made `Image` a property 
there? That more accurately reflects what's going on under the covers (i.e. 
when specifying an `Image` on the job, what we're really doing is using the 
MesosContainerizer and telling it to load that image).


- Joshua


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46835/#review131153
---


On April 29, 2016, 4:22 p.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46835/
> ---
> 
> (Updated April 29, 2016, 4:22 p.m.)
> 
> 
> Review request for Aurora, John Sirois, Maxim Khutornenko, and Bill Farner.
> 
> 
> Bugs: AURORA-1636, AURORA-1637, AURORA-1638, and AURORA-1639
> https://issues.apache.org/jira/browse/AURORA-1636
> https://issues.apache.org/jira/browse/AURORA-1637
> https://issues.apache.org/jira/browse/AURORA-1638
> https://issues.apache.org/jira/browse/AURORA-1639
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> A few notes:
> 
> 1. It's not possible to configure Mesos 0.27.x to launch docker tasks due to 
> a bug in parsing the docker_store_dir flag. Fixed here: 
> https://reviews.apache.org/r/43451/ but has not been backported to Mesos 
> 0.27. This means we can only launch tasks that use AppC images until we 
> upgrade our Mesos dependency to 0.28.x. The good news is I've confirmed that 
> launching tasks with Docker images *does* work by using Aurora linked against 
> 0.27.x but running Mesos 0.28.x in Vagrant.
> 1. In order to work around the setuid issues (i.e. task is launched as root, 
> but the executor cannot setuid because the role-user does not exist), I've 
> mounted /etc/passwd and /etc/group into the container and added a new flag, 
> `thermos_run_as_job_role`, to the scheduler. This flag is only used when 
> launching a task with a filesystem image, and causes us to add 
> `--execute-as-user ` to the thermos executor commandline.
> 1. The Mesos unified containerizer does not automatically create mount points 
> in the filesystem from the image. It expects the full path to the mount to 
> exist in the image. For /etc/passwd and /etc/groups this is not a problem, 
> but for the announcer acls file it was. I ended up moving the announcer acl 
> file into its own directory and mount that instead. In conjunction with this 
> I also had to modify our http_example Dockerfile to explicitly create that 
> mount point. A case could be made for sticking with the current path and just 
> creating an empty file in the image, I felt that creating an empty directory 
> was slightly less gross. This is tracked by 
> https://issues.apache.org/jira/browse/MESOS-5229.
> 1. The AppC image for end to end tests is created by running 
> [docker2aci](https://github.com/appc/docker2aci) on our http_example docker 
> image. The base box needed to be upgraded to add this utility. I haven't 
> published the new base box yet even though I've updated the Vagrantfile to 
> point to version 6. Once this review has been approved and I'm sure there's 
> no further changes that need to be made I'll publish the base box before 
> committing.
> 
> 
> Diffs
> -
> 
>   RELEASE-NOTES.md 7a37d0d69f688bece624628fe5b98efc85d506a2 
>   Vagrantfile 3f126ee348d0f95d6f159b62280de79f41e87e2e 
>   build-support/packer/build.sh 76197c31c365aa3d8a67049da40

Re: Review Request 46835: Add client and scheduler support for launching tasks using the Mesos unified containerizer

2016-05-02 Thread John Sirois 

---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46835/#review131153
---



I've hung back from a detailed review base on Maxim's comment.  It may be that 
we need a bridge from old docker support to new unified container support that 
uses old(current)-style embedding of thermos in the image, but I'd like to hear 
that is definitely the case before repeating this tactic.


RELEASE-NOTES.md (line 18)


Can you just say that Aurora requires Mesos 0.28.0+ to use this feature?



src/main/python/apache/aurora/config/schema/base.py (line 172)


The MesosJob is trending more and more towards a c-style union, different 
parts of the config are active depending on the setup and its not clear which 
except by reading docs carefully.  I put some effort towards supporting nicer 
pystachio evolution in an experiment documented in [this review 
feedback](https://reviews.apache.org/r/44745/) and there is a [new 
release](https://github.com/wickman/pystachio/releases) not used by Aurora yet 
that supports Choice fields.  It seems like work along these lines would be 
useful to stop the bleeding in general.  I'm not sure if that should of work 
should be coupled to this review though.


- John Sirois


On April 29, 2016, 10:22 a.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46835/
> ---
> 
> (Updated April 29, 2016, 10:22 a.m.)
> 
> 
> Review request for Aurora, John Sirois, Maxim Khutornenko, and Bill Farner.
> 
> 
> Bugs: AURORA-1636, AURORA-1637, AURORA-1638, and AURORA-1639
> https://issues.apache.org/jira/browse/AURORA-1636
> https://issues.apache.org/jira/browse/AURORA-1637
> https://issues.apache.org/jira/browse/AURORA-1638
> https://issues.apache.org/jira/browse/AURORA-1639
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> A few notes:
> 
> 1. It's not possible to configure Mesos 0.27.x to launch docker tasks due to 
> a bug in parsing the docker_store_dir flag. Fixed here: 
> https://reviews.apache.org/r/43451/ but has not been backported to Mesos 
> 0.27. This means we can only launch tasks that use AppC images until we 
> upgrade our Mesos dependency to 0.28.x. The good news is I've confirmed that 
> launching tasks with Docker images *does* work by using Aurora linked against 
> 0.27.x but running Mesos 0.28.x in Vagrant.
> 1. In order to work around the setuid issues (i.e. task is launched as root, 
> but the executor cannot setuid because the role-user does not exist), I've 
> mounted /etc/passwd and /etc/group into the container and added a new flag, 
> `thermos_run_as_job_role`, to the scheduler. This flag is only used when 
> launching a task with a filesystem image, and causes us to add 
> `--execute-as-user ` to the thermos executor commandline.
> 1. The Mesos unified containerizer does not automatically create mount points 
> in the filesystem from the image. It expects the full path to the mount to 
> exist in the image. For /etc/passwd and /etc/groups this is not a problem, 
> but for the announcer acls file it was. I ended up moving the announcer acl 
> file into its own directory and mount that instead. In conjunction with this 
> I also had to modify our http_example Dockerfile to explicitly create that 
> mount point. A case could be made for sticking with the current path and just 
> creating an empty file in the image, I felt that creating an empty directory 
> was slightly less gross. This is tracked by 
> https://issues.apache.org/jira/browse/MESOS-5229.
> 1. The AppC image for end to end tests is created by running 
> [docker2aci](https://github.com/appc/docker2aci) on our http_example docker 
> image. The base box needed to be upgraded to add this utility. I haven't 
> published the new base box yet even though I've updated the Vagrantfile to 
> point to version 6. Once this review has been approved and I'm sure there's 
> no further changes that need to be made I'll publish the base box before 
> committing.
> 
> 
> Diffs
> -
> 
>   RELEASE-NOTES.md 7a37d0d69f688bece624628fe5b98efc85d506a2 
>   Vagrantfile 3f126ee348d0f95d6f159b62280de79f41e87e2e 
>   build-support/packer/build.sh 76197c31c365aa3d8a67049da40b2976c1e25d22 
>   docs/reference/configuration.md 9fcfdfcd9ab793e888ca2bba2035d5122142a5ab 
>   docs/reference/scheduler-configuration.md 
> d2262f79edfde23eccd87bae7f1cf319b63b1103 
>   examples/vagrant/announcer-auth.json  
>   examples/vagrant/mesos_config/etc_mesos-slave/appc_store_dir PRE-CREATION 
>   examples/vagrant/mesos_config/etc_mesos-slave/image_providers PRE-CREATION 
>   examples/vagrant/

Re: Review Request 46835: Add client and scheduler support for launching tasks using the Mesos unified containerizer

2016-05-02 Thread Joshua Cohen 


> On April 29, 2016, 11:39 p.m., Maxim Khutornenko wrote:
> > Following up on our offline conversation, it would be great to explore the 
> > feasibility of running executor outside of user image. This was one of the 
> > proposed [goals](http://markmail.org/message/g2xkh7nzzblokdgk) behind 
> > moving to unified containerizer and is likely [already 
> > possible](https://github.com/apache/mesos/blob/master/docs/container-image.md#executor-dependencies-in-a-container-image)
> >  with mesos. As it stands, there is not much that separates appc adoption 
> > from the existing docker implementation feature-wise. I am fine proceeding 
> > with this patch as an interim solution though as long as we identify the 
> > follow up work to explore the possibilities here.

Yes, I'll continue to investigate the feasibility of configuring the executor 
to be mounted via a Volume that specified an Image. That would allow us to 
decouple the executor's filesystem from the task's.

That said, I think that this patch paves the way for that work so I'd like it 
to move forward on its own if there are no objections.


- Joshua


---
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/46835/#review131220
---


On April 29, 2016, 4:22 p.m., Joshua Cohen wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/46835/
> ---
> 
> (Updated April 29, 2016, 4:22 p.m.)
> 
> 
> Review request for Aurora, John Sirois, Maxim Khutornenko, and Bill Farner.
> 
> 
> Bugs: AURORA-1636, AURORA-1637, AURORA-1638, and AURORA-1639
> https://issues.apache.org/jira/browse/AURORA-1636
> https://issues.apache.org/jira/browse/AURORA-1637
> https://issues.apache.org/jira/browse/AURORA-1638
> https://issues.apache.org/jira/browse/AURORA-1639
> 
> 
> Repository: aurora
> 
> 
> Description
> ---
> 
> A few notes:
> 
> 1. It's not possible to configure Mesos 0.27.x to launch docker tasks due to 
> a bug in parsing the docker_store_dir flag. Fixed here: 
> https://reviews.apache.org/r/43451/ but has not been backported to Mesos 
> 0.27. This means we can only launch tasks that use AppC images until we 
> upgrade our Mesos dependency to 0.28.x. The good news is I've confirmed that 
> launching tasks with Docker images *does* work by using Aurora linked against 
> 0.27.x but running Mesos 0.28.x in Vagrant.
> 1. In order to work around the setuid issues (i.e. task is launched as root, 
> but the executor cannot setuid because the role-user does not exist), I've 
> mounted /etc/passwd and /etc/group into the container and added a new flag, 
> `thermos_run_as_job_role`, to the scheduler. This flag is only used when 
> launching a task with a filesystem image, and causes us to add 
> `--execute-as-user ` to the thermos executor commandline.
> 1. The Mesos unified containerizer does not automatically create mount points 
> in the filesystem from the image. It expects the full path to the mount to 
> exist in the image. For /etc/passwd and /etc/groups this is not a problem, 
> but for the announcer acls file it was. I ended up moving the announcer acl 
> file into its own directory and mount that instead. In conjunction with this 
> I also had to modify our http_example Dockerfile to explicitly create that 
> mount point. A case could be made for sticking with the current path and just 
> creating an empty file in the image, I felt that creating an empty directory 
> was slightly less gross. This is tracked by 
> https://issues.apache.org/jira/browse/MESOS-5229.
> 1. The AppC image for end to end tests is created by running 
> [docker2aci](https://github.com/appc/docker2aci) on our http_example docker 
> image. The base box needed to be upgraded to add this utility. I haven't 
> published the new base box yet even though I've updated the Vagrantfile to 
> point to version 6. Once this review has been approved and I'm sure there's 
> no further changes that need to be made I'll publish the base box before 
> committing.
> 
> 
> Diffs
> -
> 
>   RELEASE-NOTES.md 7a37d0d69f688bece624628fe5b98efc85d506a2 
>   Vagrantfile 3f126ee348d0f95d6f159b62280de79f41e87e2e 
>   build-support/packer/build.sh 76197c31c365aa3d8a67049da40b2976c1e25d22 
>   docs/reference/configuration.md 9fcfdfcd9ab793e888ca2bba2035d5122142a5ab 
>   docs/reference/scheduler-configuration.md 
> d2262f79edfde23eccd87bae7f1cf319b63b1103 
>   examples/vagrant/announcer-auth.json  
>   examples/vagrant/mesos_config/etc_mesos-slave/appc_store_dir PRE-CREATION 
>   examples/vagrant/mesos_config/etc_mesos-slave/image_providers PRE-CREATION 
>   examples/vagrant/mesos_config/etc_mesos-slave/image_provisioner_backend 
> PRE-CREATION 
>   examples/vagrant/mesos_config/etc_mesos-s