Support concurrent creation of volumes (vmdks) #7929
Labels
area/storage
Storage-related functionality
component/portlayer/storage
kind/defect/performance
Behavior that is functionally correct, but performs worse than intended
kind/enhancement
Behavior that was intended, but we want to make better
severity/3-moderate
Medium usability or functional impact. Potentially has an inconvenient workaround.
source/customer
Reported by a customer, directly or via an intermediary
team/foundation
Story
As a user of VIC I expect to be able to concurrently create containers that use volumes
Details
There are two primary issues that are causing undue serialization of volume creation currently:
a. a lock in the volume cache
b. disk attach/detach reconfigure operations
(a) causes strict serialization and should simply be removed in favour of a
singleflight
call or similar.(b) causes partial serialization, but the latency can be high enough that its effect is close to full serialization - this can be addressed with batching logic (see #7895)
The state seen by callers of the API should remain consistent, i.e. list should not show a volume that cannot be used or deleted, and only one create for a volume with a given name should succeed.
This impact concurrent container creation performance when anonymous volumes are part of the container specification.
Acceptance
The text was updated successfully, but these errors were encountered: