I thought there was a ticket around allowing operators to induce a kill task, but I can't seem to find it. There are some subtleties, for example kill tasks currently only manifest from a framework's request (so it's not clear what assumptions folks have made). Feel free to create a ticket for this.
Keep in mind you can always do a hard drain (SIGUSR1 is the current mechanism) of the agent which will destroy all of the containers for you. On Thu, Oct 29, 2015 at 11:19 AM, John Omernik <[email protected]> wrote: > I am wondering if there are some easy ways to take a healthy slave/agent > and start a process to bleed processes out. > > Basically, without having to do something where every framework would > support it, I'd like the option to > > 1. Stop offering resources to new frameworks. I.e. no new resources would > be offered, but existing jobs/tasks continue to run. > 2. Offer the ability, especially in the UI, but potentially in API as > well to "kill" a task. This would cause a failure that force the framework > to respond. For example, if it was a docker container running in marathon, > if I said "please kill this task" it would, marathon would recognize the > failure and try to restart the container. Since our agent (in point 1) is > not offering resources, then that task would not fall on the agent in > question. > > > The reason for this manual bleeding is to say run updates on a node or > pull it out of service for other reasons (memory upgrades etc) and do so in > a manual way. You may want to address what's running on the node manually, > thus a whole scale "kill everything" while it SHOULD be doable, may not > always be feasible. In addition, the inverse offers thing seems neat, but > frameworks have to support it. > > So, is there any thing like that now and I am just missing it in the > documentation? I am curious to hear how others are handling this situation > in their environments. > > John > > > >
