Tools » teuthology

Required tasks (so far)

• [x] check if teuthology's ansible task can install docker using 3rd party ansible roles.
• [x] refactor docker task to reflect comments by zack/andrew with regards to having a more generic docker task that could launch arbitrary containers on arbitrary hosts.
• [ ] add patch of `orchestra.run` (which takes effect when docker task is initialized) so that commands are launched within a container instead of the
• [ ] make `radosbench` task of `ceph-qa-suite` work with containers

later (after august 08/28)

• [ ] add `build` command that builds a ceph/base image from a SHA
  1. [ ] write dockerfile to build ceph/base from SHA
  2. [ ] create `dev` folder in ceph/ceph-docker
  3. [ ] add `Dockerfile` for building
  4. [ ] try to use ansible's docker_module to build image and push it to the registry
• [ ] add test that mocks the underlying docker-py API (look [here])
• [ ] add `requires` config option for `roles` option. This allows to specify a service dependency that might have been specified in the `services` config option

Had a discussion with Zack on the current status of https://github.com/ceph/teuthology/pull/558 . There are some issues with this approach, mainly that this being implemented as a task is fundamentally different to the way things are done in teuthology. The main goal (in the context of #12379) of using docker is to get a way of constraining resources on osds and that's doable through other means (e.g. directly manipulating cgroups, rather than relying on docker).

What is problematic with this approach (implementing docker as a task) exactly ?

Loic Dachary wrote:

What is problematic with this approach (implementing docker as a task) exactly ?

Sorry, I shouldn't have said problematic. It is fundamentally different in the sense that there are things like:

• making sure that docker is installed in the targets
• properly tearing down containers and any sideffects they might have on targets
• support and build an image from any SHA. All binary preparation is currently done via gitbuilder (it doesn't "speak" docker)

In general, there are some requirements that have to be accomplished "outside" the docker task, and those aren't addressed yet (and it's not clear how they would easily get addressed).

There needs to be a proper analysis of all things that get implied by supporting containers and I don't have enough understanding of all-things-teuthology yet. On the other hand, the infra/devops team is busy enough that they cannot allocate time for this (at this time).

• making sure that docker is installed in the targets

I think it's reasonable to assume you can't and should not deal with this. So you can assume docker is available and start from there. Installing docker on the baremetal is something different and if you try to solve both problems at once it's likely to be a little complicated.

• properly tearing down containers and any sideffects they might have on targets

docker stop / rm will do all the cleanup, the whole point of containers being that it's reasonable to assume there won't be any side effect to cleanup.

• support and build an image from any SHA. All binary preparation is currently done via gitbuilder (it doesn't "speak" docker)

You can ignore that problem and just pull packages from the gitbuilder in the first phase. When that works you can try to be clever about it (maybe something similar to what I did where the install task knows it in docker and create an image after installing the packages).

in general, there are some requirements that have to be accomplished "outside"...

maybe there are such requirements, but I don't see any right now.