craigcondit commented on pull request #307:
URL:
https://github.com/apache/incubator-yunikorn-k8shim/pull/307#issuecomment-938710472
> Overall looks good. I am not quite sure about the volume binding changes,
but it looks pretty logical. We need to test this part before merging back to
the master branch.
Absolutely. Given the internal churn from K8S 1.16 -> 1.20, we'll need a
pretty deep testing cycle for all of it.
> Another question I have is about the spark client, what are the files you
created and what are the files generated?
`pkg/sparkclient` is all auto-generated (see below).
> I assume files in pkg/sparkclient/clientset/ were automatically generated.
Did you run the code generation from inside the Spark operator repo to obtain
those files and then put them here?
The code generation is run as part of `scripts/code_gen.sh`:
```
./scripts/generate-groups.sh "all" \
github.com/apache/incubator-yunikorn-k8shim/pkg/sparkclient \
github.com/GoogleCloudPlatform/spark-on-k8s-operator/pkg/apis \
"sparkoperator.k8s.io:v1beta2" \
--go-header-file $(dirname "${BASH_SOURCE}")/custom-boilerplate.go.txt \
--output-base "$(dirname "${BASH_SOURCE}")/../../../.."
```
> Moving on how can we make sure the client library we used is compatible
with the spark operator project?
This references the version of the spark-on-k8s-operator package that we
depend on already. All the code gen step does is regenerate the client stubs to
be compatible with k8s clients that do things like require `context` objects to
be passed for most calls. By generating our own stubs, we decouple ourselves
from whether or not upstream spark operator builds against a different k8s by
default.
--
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]
