aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <wfar...@apache.org>
Subject Re: Containers are always being started with `-c "$MESOS_SANDBOX/null"`
Date Mon, 03 Aug 2015 16:35:47 GMT
That is indeed dead, thanks for pointing this out.  Submitted a patch to
remove it: https://reviews.apache.org/r/37041/

-=Bill

On Mon, Aug 3, 2015 at 8:37 AM, Steve Niemitz <sniemitz@twitter.com.invalid>
wrote:

> Ah there you go, I've never even seen that script before, I think you may
> have stumbled on some dead code. :P
>
> I recommend using
>
> https://github.com/tellapart/aurora/blob/master/examples/vagrant/upstart/aurora-scheduler.conf
> as an example of the flags you need.
>
>
> On Mon, Aug 3, 2015 at 11:31 AM, Jay Taylor <jay@jaytaylor.com> wrote:
>
> > Hi Steve,
> >
> > Here is my scheduler.sh (I started with
> > examples/scheduler/scheduler-local.sh):
> >
> >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *#!/usr/bin/env bashset -o errexitset -o pipefailset -x. /etc/profile#
> An
> > > example scheduler launch script.# It assumes a local ZooKeeper ensemble
> > > running at localhost:2181 and a master under /mesos/master# Location
> > where
> > > aurora-scheduler.zip was
> > > unpacked.AURORA_SCHEDULER_HOME=/usr/local/aurora-scheduler# Flags that
> > > control the behavior of the JVM.JAVA_OPTS=(  -server  -Xmx1g  -Xms1g  #
> > > Location of libmesos-XXXX.so / libmesos-XXXX.dylib
> > > -Djava.library.path=/usr/local/lib)# Flags control the behavior of the
> > > Aurora scheduler.# For a full list of available flags, run
> > > bin/aurora-scheduler -helpAURORA_FLAGS=(  -cluster_name=gw_hobart  #
> > Ports
> > > to listen on.  -http_port=8081  -native_log_quorum_size=1
> > > -zk_endpoints=localhost:2181
> > > -mesos_master_address=zk://localhost:2181/mesos
> > > -serverset_path=/aurora/scheduler
> > > -native_log_zk_group_path=/aurora/replicated-log
> > > -native_log_file_path="$AURORA_SCHEDULER_HOME/db"
> > > -backup_dir="$AURORA_SCHEDULER_HOME/backups"  # TODO(Kevin Sweeney):
> > Point
> > > these to real URLs.  -thermos_executor_path=/dev/null
> > > -allowed_container_types='MESOS,DOCKER'  -allow_docker_parameters=true
> > > -vlog=FINEST  -logtostderr)# Environment variables control the behavior
> > of
> > > the Mesos scheduler driver (libmesos).export GLOG_v=1export
> > > LIBPROCESS_PORT=8083JAVA_OPTS="${JAVA_OPTS[*]}" exec
> > > "$AURORA_SCHEDULER_HOME/bin/aurora-scheduler" "${AURORA_FLAGS[@]}"*
> >
> >
> > And now I see that things are just as you said: invalid "null"
> thermos.pex
> > path:
> >
> >
> > > *# TODO(Kevin Sweeney): Point these to real URLs.**
> > > -thermos_executor_path=/dev/null*
> >
> >
> > I'll get that sorted and try again.
> >
> > Thank you for your help!
> >
> > On Mon, Aug 3, 2015 at 7:29 AM, Steve Niemitz
> <sniemitz@twitter.com.invalid
> > >
> > wrote:
> >
> > > It seems like your scheduler is misconfigured somehow.  The args being
> > > passed in the docker container should look like:
> > > [
> > >   "-c",
> > >   "$MESOS_SANDBOX/thermos_executor.pex <lots of arguments>"
> > > ]
> > >
> > > Can you attach the flags you've configured the scheduler with?  It
> looks
> > > like the executor uri flag is somehow wrong (is it possible its
> actually
> > > "null" in your config?)
> > >
> > > On Sat, Aug 1, 2015 at 5:19 PM, Jay Taylor <outtatime@gmail.com>
> wrote:
> > >
> > > > Greetings Aurora folks,
> > > >
> > > > I want to get a docker container running on Aurora.
> > > >
> > > > Here is my .aurora file:
> > > >
> > > >
> > > > > *run_process = Process(*
> > > > > *    name="my-app",*
> > > > > *    cmdline="sleep 300",**)*
> > > > >
> > > > > *app_task = Task(*
> > > > > *  name = "my-app",*
> > > > > *  processes = [run_process],*
> > > > > *  resources = Resources(*
> > > > > *    cpu = 1,*
> > > > > *    disk = 100*MB,*
> > > > > *    ram = 512*MB,*
> > > > > *  ),**)*
> > > > >
> > > > > *app_container = Container(*
> > > > > *  docker = Docker(*
> > > > > *    image = "my-registry:5001/jay/my-app",*
> > > > > *    parameters = [*
> > > > > *      {*
> > > > > *        "name": "env",*
> > > > > *        "value": "FOO=BAR",*
> > > > > *      },*
> > > > > *    ],*
> > > > > *  ),**)*
> > > > >
> > > > > *jobs = [*
> > > > > *  Service(*
> > > > > *    cluster = "test_cluster",*
> > > > > *    environment = "devel",*
> > > > > *    role = "web-server",*
> > > > > *    name = "my-app",*
> > > > > *    instances = 1,*
> > > > > *    task = app_task,*
> > > > > *    container = app_container,*
> > > > > *  ),**]*
> > > >
> > > >
> > > > My expectation was that the container would be invoked and "sleep
> 300"
> > > > would be run inside (for testing purposes).
> > > >
> > > > However, the task almost immediately starts an endless "flapping
> > penalty"
> > > > cycle.
> > > >
> > > > Inspecting one of the failed containers reveals some interesting
> > > > information:
> > > >
> > > > *$ sudo docker inspect 1337afaf7331*
> > > >
> > > > *[{*
> > > >
> > > > *    "AppArmorProfile": "",*
> > > >
> > > > *    "Args": [*
> > > >
> > > > *        "-c",*
> > > >
> > > > *        "$MESOS_SANDBOX/null"*
> > > >
> > > > *    ],*
> > > >
> > > > *    "Config": {*
> > > >
> > > > *        "AttachStderr": false,*
> > > >
> > > > *        "AttachStdin": false,*
> > > >
> > > > *        "AttachStdout": false,*
> > > >
> > > > *        "Cmd": [*
> > > >
> > > > *            "-c",*
> > > >
> > > > *            "$MESOS_SANDBOX/null"*
> > > >
> > > > *        ],*
> > > >
> > > >
> > > > Why is the task launch command "$MESOS_SANDBOX/null"?
> > > >
> > > > I also tried to get one of the examples up
> > > >
> (./src/test/sh/org/apache/aurora/e2e/http/http_example_docker.aurora),
> > > but
> > > > the task immediately starts flapping and no containers even get
> > created.
> > > >
> > > > How can we get control over the -c command sent to docker?
> > > Alternatively,
> > > > if there is some way to prevent the "-c" flag altogether that would
> > work
> > > > too since the docker image already has a perfectly fine CMD defined.
> > > >
> > > > Any insight or information would be GREATLY appreciated!!!
> > > >
> > > > Best regards,
> > > > Jay
> > > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message