IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
When you do `make docker-compose-build` on your branch without any changes, this will use the devel tag as a cache source. This will speed things up if you havent made any local changes to the Makefile or requirements files.
There was quite a bit of drift between the main Dockerfile and this one since we last touched it. It’s heavier than it needs to be, but by using the main development image as the base here, we have less duplicated and outdated code overall.
This was intended to save us CI time if / when we switch away from static nodes for Zuul. After merging this in I discovered that this option does not work with `docker build --cache-from`, which will be more benefical in terms of speed improvements anyway.
This commit does a few things:
- Add the `--squash` option to the `awx-devel-build` make target. This reduces the resulting image size from 2.12 GB to 1.37 GB. I think we can get this down even more by inspecting the image contents.
- Reorganize commands so that the cache expires less often. Before this commit, any changes to the Makefile would essentially cause the entire image to rebuild.
- Break yum dependencies up into multiple lines. This makes it easier to see what changes in a diff.
- Use `n` to install our required version of node (rather `curl node | bash`). I’ve found this to be easier to maintain / more portable when working with other Dockerfiles.
- General organizational changes to make things easier to parse visually.
I wanted to pass `—user` to `docker-compose` up, but that option doesnt exist. To get around this, I had to record the uid on the host (CURRENT_UID), interpolate the variable in tools/docker-compose.yml, and detect that inside the container. I then piggy-backed on the /etc/passwd hack we use for scenarios with unpredictable uids.
this commit implements the bulk of `awx-manage run_dispatcher`, a new
command that binds to RabbitMQ via kombu and balances messages across
a pool of workers that are similar to celeryd workers in spirit.
Specifically, this includes:
- a new decorator, `awx.main.dispatch.task`, which can be used to
decorate functions or classes so that they can be designated as
"Tasks"
- support for fanout/broadcast tasks (at this point in time, only
`conf.Setting` memcached flushes use this functionality)
- support for job reaping
- support for success/failure hooks for job runs (i.e.,
`handle_work_success` and `handle_work_error`)
- support for auto scaling worker pool that scale processes up and down
on demand
- minimal support for RPC, such as status checks and pool recycle/reload