ansibleshipyard / ansible-marathon Goto Github PK

I think giving people an option to build from source is nice, but by default we use stable gz file.

I'm thinking of allow people to specify "latest", then we would build from source maybe from a build.yml file.

marathon_version: "latest"

@JasonGiedymin what are your thought on this?

http://docs.ansible.com/playbooks_roles.html#role-dependencies

It would be nice to have a place to set JAVA_OPTS

https://mesosphere.github.io/marathon/docs/command-line-flags.html

For now, I'm adding it to my environment but that doesn't seem very safe overall.

I propose to split following task into 1 task to enable the service and one that restarts it (through a handler):

- name: Start Marathon service
  service: name=marathon state=restarted enabled=yes
  tags:
    - restart

Where do I specify the --task_launch_timeout variable for Marathon. We have a slow internet connection thus it takes time to pull the docker images. I have increased the executor_registration_timeout for all the mesos slaves, which I found in https://github.com/AnsibleShipyard/ansible-mesos/blob/master/vars/main.yml but we need to also increase the task_launch_timeout for Marathon.

Add gitter link: https://gitter.im/AnsibleShipyard/devs?utm_source=share-link&utm_medium=link&utm_campaign=share-link

https://groups.google.com/forum/#!topic/marathon-framework/y7r6GrGDKgc

Motivation:

Do the upgrade with the minimum (1) leader fail-overs (vs worst-case: 'number of HA master/marathon nodes'), as recommended on:
https://mesosphere.github.io/marathon/docs/upgrade/index.html
http://stackoverflow.com/questions/33042343/is-it-possible-to-perform-a-zero-downtime-upgrade-or-reconfiguration-of-mesos

Current State

Currently I've a flexible serial attribute to provide the (optional) rolling upgrade logic, in a typical
playbook:

- hosts: marathon
  become: True
  roles:
    - {role: teralytics.marathon}
  environment: "{{proxy_env}}"
  tags: marathon
  serial: "{{ (rolling_upgrade|default(false)|bool)|ternary(1,0) }}"

Goal

run the upgrade in a specific order, so that the current leader (can be provided for ex. using a consul-DNS or mesos-dns url like 'leader.mesos' ) is deployed last.

I've some ideas, but before doing actual work, wanted to ask the ansible/devOps community for any existing solutions or recommendations.
I see 2 diff approaches:

• (a) Splitting the playbook into 2 diff runs:
• 1.run on the list of all selected-nodes, excluding the leader.mesos (could be done with some list mangling, including the resolution of dns entries to IPs to match the leader.mesos with the actual hostname (from the inventory)! )
• 2.run on the remaining leader.mesos host
• (b): using a dynamic inventory, resp. extra python logic that returns a single list of hosts in the right order

Ideas!?