Conversation
|
ping @mavenugo @msabansal |
|
ping @mavenugo |
Signed-off-by: Madhan Raj Mookkandy <madhanm@microsoft.com>
|
ping @msabansal @mavenugo Can you look into this? It has been pending for a long time. |
|
LGTM |
| } | ||
|
|
||
| // This is just a stub for now | ||
| endpoint.containerID = sboxKey |
There was a problem hiding this comment.
As per the design, containerID is internal to libnetwork core while the drivers shouldnt assume the presence of container-id. SandboxKey is the generic concept that can be trusted without assuming any changes to the core.
There was a problem hiding this comment.
Yes, I understand that.
But libnetwork's design principle will not work well with Windows, because there is a service "HCS" that manages all the containers. So for any changes to the container, HCS has to be notified of that change. For this the ID of the container is required. This is the basic design principle of Windows Containers.
To explain the internals more, Like CreateComputeSystem HCS call, for Hot Add/Remove of network endpoints, ModifyCompyteSystem HCS call has to be invoked.
Unlike Linux, on Windows, Containers and Networks are not yet decoupled completely to fit into LibNetwork design principle. Once that is done (am not sure when), we could drop the containerID.
Till then windows needs containerID for hot add to work.
| if sb.config.useDefaultSandBox { | ||
| return osl.GenerateKey("default") | ||
| } | ||
| return osl.GenerateKey(sb.containerID) |
There was a problem hiding this comment.
As explained above, this change goes against the current design
|
We can close this request. |
|
as per request from @pradipd |
6 participants
Hot add for windows requires containerID to be passed down to hcsshim, which interally finds the right container and connects the nic.