The current implementation of update(#15078), and thus the endpoint /containers/(id)/update, is using HostConfig struct although it's only updating Resources.
This raises few concerns :
- We decided that
update should only update stuff that are in Resources struct, but it's possible to send a complete HostConfig struct which could lead to confusion — like why is some fields not taken care of, etc….
- If a complete
HostConfig struct is passed, it will completely and silently ignore all attributes except Resources. It should at least put a warning.
I think we should reduce what we send and change the API /containers/(id)/update to just take Resoures struct instead of HostConfig — it would make it clear that only stuff in this struct are supported (and it's simpler to implement than doing some diff or something and warn that something that is not in Resources has been wrongly set).
/cc @hqhq @tiborvass @thaJeztah @runcom @duglin @unclejack @icecrime @calavera
The current implementation of
update(#15078), and thus the endpoint/containers/(id)/update, is usingHostConfigstruct although it's only updatingResources.This raises few concerns :
updateshould only update stuff that are inResourcesstruct, but it's possible to send a completeHostConfigstruct which could lead to confusion — like why is some fields not taken care of, etc….HostConfigstruct is passed, it will completely and silently ignore all attributes exceptResources. It should at least put a warning.I think we should reduce what we send and change the API
/containers/(id)/updateto just takeResouresstruct instead ofHostConfig— it would make it clear that only stuff in this struct are supported (and it's simpler to implement than doing some diff or something and warn that something that is not inResourceshas been wrongly set)./cc @hqhq @tiborvass @thaJeztah @runcom @duglin @unclejack @icecrime @calavera