-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for sidecar container #423
Add support for sidecar container #423
Conversation
- Ability to pass sidecar container via PodSpec - Applicable whenever PodSpec is created - Add tests Resolves spring-cloud#414
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i think the terminology here can be more generic. a pod can contain multiple containers. "sidecar" is more of a pattern type term. i think a generic deployer property that contains the container info for one or more containers say something like additionalContainers
or whatnot would be more appropriate. the property should allow for multiple container definitions to be passed.
@chrisjs Good point. In fact, when I was getting started with this feature, my original intention was to allow multiple containers instead of just a single additional container. But, since the deployment properties have key/value pairs as String/String, I was thinking maybe we could add the initial support to add a single sidecar container with the specific key named Irrespective of this, let's discuss further to find a better approach on this. Thanks! |
we already map objects beyond key/value pairs, for example: etc. seems like it would be a similar approach. i would advocate for using the generic "containers" naming rather than "sidecar" |
ok, yeah, I missed that. I will work on it and update the PR.
Sure, |
@chrisjs Updated the PR with the suggested changes. With this set of changes, we can support having multiple containers with all the supported configurations for a container. |
- Add list of `Container` objects as a property named `additionalContainers` in K8s deployer property - Use `additionalContainers` as the deployer property to extract the additional container configurations - Add and Update tests
f77f8aa
to
8df9f07
Compare
public static class InitContainer extends ContainerProperties { | ||
} | ||
|
||
static class Container extends io.fabric8.kubernetes.api.model.Container { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am curious if we can use the same approach of using fabric8 api models to other supported properties as well. I believe this can eliminate some explicit models with a fewer properties (for instance the ContainerProperties we have for InitContainer).
Also, I thought having an explicit type named Container
could help here. But, I am ok if we can directly use the fabric8 Container type as is in this class.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you could use the fabric8 objects, but thats a bit leakly. theres an open issue around this: #296
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor things but beyond that LGTM
|
||
List<Container> additionalContainers = this.deploymentPropertiesResolver.getAdditionalContainers(deploymentProperties); | ||
for (Container additionalContainer: additionalContainers) { | ||
podSpec.addToContainers(additionalContainer); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like theres a addAllToContainers
that could be used rather than the loop here
public static class InitContainer extends ContainerProperties { | ||
} | ||
|
||
static class Container extends io.fabric8.kubernetes.api.model.Container { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you could use the fabric8 objects, but thats a bit leakly. theres an open issue around this: #296
@@ -687,6 +693,11 @@ public void setVolumeMounts(List<VolumeMount> volumeMounts) { | |||
*/ | |||
private InitContainer initContainer; | |||
|
|||
/** | |||
* A side car container one can add to the main application container. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A side car container
-> A container
|
||
String taskName = request.getDefinition().getName(); | ||
|
||
log.info("Checking job pod spec annotations of {}...", taskName); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks like this should be removed, or the message changed
merged in d84e6c7 |
@isha1kh @pravinkumarb84 If possible, it would be great to try out the latest SCDF 2.8.0 SNAPSHOT and Skipper 2.7.0-SNAPSHOT and let us know your feedback on supporting additional containers. Please pay attention to the name of the property |
@ilayaperumalg - Yes am going to try this soon, thanks. |
@ilayaperumalg - I've tried against the above version and although the additional container is getting added. I've noticed an issue i.e. when trying to update the stream via Skipper UI, the additional container properties aren't re-populated. |
On the container restart question, You need to set the restart policy for the container spec . On the UI, you would only see the |
I also want to try this implementation. As I understand, we should pass an container yaml as additionalContainers param, right? Do you have any sample to try? Thanks. |
You need to set the container properties similar to how we set here |
Thanks @ilayaperumalg , I did not notice before :) |
Resolves #414