Github user vanzin commented on a diff in the pull request:
https://github.com/apache/spark/pull/19954#discussion_r157883353
--- Diff:
resource-managers/kubernetes/core/src/main/scala/org/apache/spark/deploy/k8s/MountSecretsBootstrap.scala
---
@@ -0,0 +1,62 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements. See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.spark.deploy.k8s
+
+import io.fabric8.kubernetes.api.model.{Container, ContainerBuilder, Pod,
PodBuilder}
+
+/**
+ * Bootstraps a driver or executor container or an init-container with
needed secrets mounted.
+ */
+private[spark] class MountSecretsBootstrap(secretNamesToMountPaths:
Map[String, String]) {
--- End diff --
If I understand this class correctly, it seems like what you're trying to
do here is to inject this logic into different steps that require this
functionality. So the code that instantiates those steps needs to know about
this dependency, and needs to know how to create both objects. Then the step
implementation has to call this code.
Instead, wouldn't it be cleaner to make the step inherit this functionality?
e.g.
```
trait MountSecretsBootstrap(args) {
def mountSecrets(...) { }
}
class InitContainerMountSecretsStep extends InitContainerConfigurationStep
with MountSecretsBootstrap {
}
```
The same comment could be made about the init container boostrap.
But in both cases, I'm not sure this would work right now on the executor
side, because as I mentioned it doesn't really use the same abstraction as the
driver side. Which is kinda one of the problems with the current class
hierarchy here...
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
