andreaspeters commented on code in PR #586:
URL: https://github.com/apache/mesos/pull/586#discussion_r1943675117
##########
src/docker/executor.cpp:
##########
@@ -318,7 +329,26 @@ class DockerExecutorProcess : public
ProtobufProcess<DockerExecutorProcess>
}
};
- if (container.ipAddress.isSome()) {
+ bool useCNI = false;
+#ifdef __linux__
+ if (network_cni_config_dir.size() > 0 &&
network_cni_plugins_dir.size() > 0) {
+ Try<std::tuple<Subprocess, std::string>> cni = attachCNI(task);
+ if (!cni.isError()) {
+ Subprocess cniSub = std::get<0>(cni.get());
+ std::string cniNetworkName = std::get<1>(cni.get());
+
+ WIFEXITED(cniSub.status().get().get());
+ Try<std::string> cniIP = attachCNISuccess(cniSub);
+ if (cniIP.isError()) {
+ LOG(ERROR) << cniIP.error();
+ } else {
+ useCNI = true;
+ setIPAddresses(cniIP.get(), false);
+ }
+ }
Review Comment:
We can only add CNI if the container is already running since there is no
way for us to "infiltrate" the container during the startup.
There are up to one second where the workload could have connection issues.
But the container will not fail (crash). That's a point we have to write as
notice.
My personal opinion is: Docker inc. should add CNI support to there engine.
But they will not and on the other hand they also do not care there network
plugins. 🤷🏻♂️ At least with these CNI implementation we can use a wide range
of new network interfaces with our docker executor and does not have to use
unmaintained docker network plugins.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
