> On Feb. 24, 2015, 6:01 a.m., Joshua Cohen wrote:
> >
> 
> Steve Niemitz wrote:
>     I'm not a big fan of how the parsing works here either.  I was thinking 
> about this last night, I think I have a better plan here.  Lemme know what 
> you think.
>     
>     I already want to add volume support per-job at some point, so I propose 
> adding the needed thrift objects to api.thrift (Volume, Mode enum), and 
> converting the command line into those objects in ExecutorSettings.  That 
> would then let me reuse the volume-adding code in MesosTaskFactory for normal 
> volumes in the future.
>     
>     Re: command line, I chose the format there because it's the same as the 
> docker command line.  What about making a new parser to parse that into the 
> above mentioned thrift objects?
> 
> Stephan Erb wrote:
>     How about using the same format and argument name as Mesos' 
> `--default_container_info`:
>     
>         {
>           "type": "MESOS",
>           "volumes": [
>             {
>               "host_path": "./.private/tmp",
>               "container_path": "/tmp",
>               "mode": "RW"
>             }
>           ]
>         }
>         
>     See https://mesos.apache.org/documentation/latest/configuration/
> 
> Steve Niemitz wrote:
>     JSON on the command line is an escaping nightmare IMO, and very verbose 
> to specify 2 (or 3) strings for this use case.

JSON on the command line also makes me uneasy, but i don't think we have 
precedent for command line entities with this many knobs (3 are obvious so far).

How about 2 approaches as straw men:

`-volume_mounts_read_only` and `-volume_mounts_read_write`, both key-value 
mappings

`-volume_mounts_config`, path to a JSON file with entities similar to what 
Stephan sketched above

The first approach has the upside that it fits with the status quo, but it 
cannot be easily extended if we ever want more attributes.  The second would be 
the first config file we use, but is more future-proof.


- Bill


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


On Feb. 24, 2015, 2:07 a.m., Steve Niemitz wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/31338/
> -----------------------------------------------------------
> 
> (Updated Feb. 24, 2015, 2:07 a.m.)
> 
> 
> Review request for Aurora, Jay Buffington and Bill Farner.
> 
> 
> Bugs: AURORA-1107
>     https://issues.apache.org/jira/browse/AURORA-1107
> 
> 
> Repository: aurora
> 
> 
> Description
> -------
> 
> Added a command line flag, -global_container_mounts, to allow mounting paths 
> from the slaves into the (docker) containers they run.
> 
> This is the first portion of allowing per-job mounts, however, I wanted to 
> get this out first since more people want it.  I'll implement per-job mounts 
> in a future review.
> 
> 
> Diffs
> -----
> 
>   docs/deploying-aurora-scheduler.md d1123359961fd59ddb8c1a07f80f293bdd46019f 
>   src/jmh/java/org/apache/aurora/benchmark/SchedulingBenchmarks.java 
> bacfbfeb237ecddf82f58679e05be012c5214e61 
>   src/main/java/org/apache/aurora/scheduler/app/SchedulerMain.java 
> 24b61c1e4f615295acf28d904588e1512972d3f4 
>   src/main/java/org/apache/aurora/scheduler/mesos/ExecutorSettings.java 
> baacb71403d55c5b90fc11cb2a23f552a32e8ba5 
>   src/main/java/org/apache/aurora/scheduler/mesos/MesosTaskFactory.java 
> 5340d651b298ec8aa079e73d6d2f652fdf876293 
>   src/test/java/org/apache/aurora/scheduler/app/SchedulerIT.java 
> 6575b7d420f17ec68d6e2a83e7b380f684577d4f 
>   
> src/test/java/org/apache/aurora/scheduler/mesos/MesosTaskFactoryImplTest.java 
> 444d6d3fdaf86eb84612f846eaa326eb75c49898 
>   src/test/java/org/apache/aurora/scheduler/mesos/TaskExecutors.java 
> efe62ceb502ead88a2f0cd6d09a76664e465d9bc 
> 
> Diff: https://reviews.apache.org/r/31338/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Steve Niemitz
> 
>

Reply via email to