Closes: #6890
Some remarks,
- `# coding ... utf-8` statements are not needed
- isdigit on strings instead of a try-catch.
- Default opening mode is read, so we can do `open()` without the `'r'` everywhere
- Removed inheritinng from `object` class, it isn't necessary in python3.
- `super(ClassName, self)` can now be replaced with `super()`
- Use of itertools and `chain` on a couple places dealing with sets.
- Used the operator module instead of lambdas when warranted
`itemgetter(0)` instead of `lambda x: x[0]`
`attrgetter('name')` instead of `lambda x: x.name`
- `sorted` returns a list, so no need to use `list(sorted(...))`
- Removed `dict()` using dictionary comprehensions whenever possible
- Attempted to remove python3.2 support
Signed-off-by: alexrecuenco <alejandrogonzalezrecuenco@gmail.com>
This change reverts the new naming convention introduced in 1.23 for service containers.
One-off containers will now use a slug instead of a sequential number as they do not
present addressability concerns and benefit from being capable of running in parallel.
Signed-off-by: Joffrey F <joffrey@docker.com>
The Service.create_container() method fetches a list of the current
containers in order to determine the next container number. In doing so,
it makes several API calls: one to fetch the list of containers, then
one per container in order to inspect it.
In some situations it can happen that a container is removed after
having been listed: in that case, the call to inspect will get a 404 and
raise a NotFound.
One situation in which this has been observed is when trying to
concurrently create multiple one-off containers for the same service
(using `docker-compose run` and a unique `--name`), as described in
more detail in gh-5179.
This patch adds a unit test that simulates the race between the
calls to list and to inspect, and changes Service._next_container_number
to skip removed containers instead of blowing up.
Fixes gh-5179
Signed-off-by: Alberto Piai <apiai@sensational.ch>
* Add shm_size to build configuration
* Make it possible to enlarge/customize shm size during build
* Value in bytes, or use string like "512M" or "1G" ...
* Add to compose format 2.3 and (provisionally) >=3.5 format
* Add automated test for shm_size in build-opts
Signed-off-by: Marc van den Hoogen <marc@vandenhoogen.eu>
Made unit tests compatible with previously added shm_size build-option
Signed-off-by: Marc van den Hoogen <marc@vandenhoogen.eu>
Also support shm_size build-opt when conf override
Signed-off-by: Marc van den Hoogen <marc@vandenhoogen.eu>
Automated test for shm_size build-option
Signed-off-by: Marc van den Hoogen <marc@vandenhoogen.eu>
Schema 3.4, add shm_size to schema 2.3, updated const.py
Signed-off-by: Marc van den Hoogen <marc@vandenhoogen.eu>
Corrected typo in config_schema_v3.4
Signed-off-by: Marc van den Hoogen <marc@vandenhoogen.eu>
Add support for g/m/k units for shm_size in build-opts
Signed-off-by: Marc van den Hoogen <marc@vandenhoogen.eu>
Reorder imports in service.py
Signed-off-by: Marc van den Hoogen <marc@vandenhoogen.eu>
