I'm looking into container.remove and container.delete tasks (https://github.com/CodeNow/khronos/blob/master/lib/tasks/containers/remove.js#L37).
They bot have following logic:
- Check if dock exists in Swarm
- Talk directly to docker daemon using
dockerHost to perform operation.
I'm wondering if we can just talk to Swarm all the time and also skip dockExist check. In the current scenario we make 2 calls: 1 to swarm and 1 to docker daemon. In the new scenario we will have 1 call to swarm.
Benefits:
- Less calls (1 < 2)
- Jobs become more lightweight since they will not have
job.dockerHost property
- Jobs can be reused by other systems. E.x. API would be able to enqueue a job for container removal/deletion without specifying dockerHost.
Context:
I'm thinking about removing this piece of code from API (https://github.com/CodeNow/api/blob/master/lib/workers/instance.container.delete.js#L68).
Theoretically API can either enqueue khronos.container.remove job or emit a new even that khronos can pick it up (I think I like second option better but open for your comments)
I'm looking into
container.removeandcontainer.deletetasks (https://github.com/CodeNow/khronos/blob/master/lib/tasks/containers/remove.js#L37).They bot have following logic:
dockerHostto perform operation.I'm wondering if we can just talk to Swarm all the time and also skip dockExist check. In the current scenario we make 2 calls: 1 to swarm and 1 to docker daemon. In the new scenario we will have 1 call to swarm.
Benefits:
job.dockerHostpropertyContext:
I'm thinking about removing this piece of code from API (https://github.com/CodeNow/api/blob/master/lib/workers/instance.container.delete.js#L68).
Theoretically API can either enqueue
khronos.container.removejob or emit a new even that khronos can pick it up (I think I like second option better but open for your comments)