Create labels when volume exists only remotely #34896
Conversation
|
ping @srust @clintkitson @gourao |
|
@tiborvass any idea when this pull request will get merged for an engine release? Thank you |
|
@tiborvass any ETA as to when this will get merged into which release? I have a customer that has been having problems with this Docker Certified Rex-Ray PlugIn for EMC's Isilon for several months now. Thank you, Josh |
|
@cpuguy83 @tiborvass there is a meeting with this customer this week and we need a solid update to give them. Can someone provide an update on to when this will be merged and what release will address it? This stemmed from the Docker Certified Plugin for Rex-Rex for EMC Isilon: Thank you, Josh |
|
@sixcounts for certified plugins it'll have to end up in a Docker EE release, so that would have to be back-ported by Docker; it's best to open a backport request for that internally. |
volume/store/store.go
Outdated
| if err != nil { | ||
| return nil, &OpErr{Op: "create", Name: name, Err: err} | ||
| } | ||
|
|
||
| logrus.Debugf("Registering new volume reference: driver %q, name %q", vd.Name(), name) | ||
|
|
||
| if v, _ := vd.Get(name); v != nil { |
There was a problem hiding this comment.
Maybe I don't need to get rid of this... may need to revisit, but just need to ensure that labels are stored locally.
cpuguy83
force-pushed
the
store_labels_when_exists
branch
from
7e70776 to
c99431e
Compare
Before this, if a volume exists in a driver but not in the local cache, the store would just return a bare volume. This means that if a user supplied options or labels, they will not get stored. Instead only return early if we have the volume stored locally. Note this could still have an issue with labels/opts passed in by the user differing from what is stored, however this isn't really a new problem. This fixes a problem where if there is a shared storage backend between two docker nodes, a create on one node will have labels stored and a create on the other node will not. Signed-off-by: Brian Goff <[email protected]>
cpuguy83
force-pushed
the
store_labels_when_exists
branch
from
c99431e to
4d8598a
Compare
|
@cpuguy83 if is ready to merge ? |
|
I'm happy with it, no behavior change in volume driver interaction like was originally implemented. On mobile so I can't inspect that windows error at the moment. |
I restarted |
|
LGTM |
1 similar comment
|
LGTM |
Before this, if a volume exists in a driver but not in the local cache,
the store would just return a bare volume. This means that if a user
supplied options or labels, they will not get stored.
Instead only return early if we have the volume stored locally. Note
this could still have an issue with labels/opts passed in by the user
differing from what is stored, however this isn't really a new problem.
There is a minor behavior change in the interaction with the volumedriver in that
createis called each time instead of doing aget and then create. This shouldn't be a problem as the get was just a
best effort and create is expected to be idempotent.
This fixes a problem where if there is a shared storage backend between
two docker nodes, a create on one node will have labels stored and a
create on the other node will not.