Skip to content
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

Conversation

ilayaperumalg
Copy link
Contributor

  • Ability to pass sidecar container via PodSpec
  • Applicable whenever PodSpec is created
  • Add tests

Resolves #414

 - Ability to pass sidecar container via PodSpec
 - Applicable whenever PodSpec is created
 - Add tests

Resolves spring-cloud#414
Copy link
Contributor

@chrisjs chrisjs left a 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.

@ilayaperumalg
Copy link
Contributor Author

@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 sidecarContainer to avoid this key/value constraint.

Irrespective of this, let's discuss further to find a better approach on this. Thanks!

@chrisjs
Copy link
Contributor

chrisjs commented Apr 15, 2021

@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 sidecarContainer to avoid this key/value constraint.

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:

https://docs.spring.io/spring-cloud-dataflow/docs/current/reference/htmlsingle/#_secret_key_references

https://docs.spring.io/spring-cloud-dataflow/docs/current/reference/htmlsingle/#_configmap_key_references

etc. seems like it would be a similar approach. i would advocate for using the generic "containers" naming rather than "sidecar"

@ilayaperumalg
Copy link
Contributor Author

ok, yeah, I missed that. I will work on it and update the PR.

i would advocate for using the generic "containers" naming rather than "sidecar"

Sure, containers that is :-)

@ilayaperumalg
Copy link
Contributor Author

@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.

@ilayaperumalg ilayaperumalg requested a review from chrisjs April 15, 2021 11:47
 - 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
@ilayaperumalg ilayaperumalg force-pushed the GH-414-sidecar-container branch from f77f8aa to 8df9f07 Compare April 15, 2021 12:46
public static class InitContainer extends ContainerProperties {
}

static class Container extends io.fabric8.kubernetes.api.model.Container {
Copy link
Contributor Author

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.

Copy link
Contributor

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

Copy link
Contributor

@chrisjs chrisjs left a 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);
Copy link
Contributor

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 {
Copy link
Contributor

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.
Copy link
Contributor

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);
Copy link
Contributor

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

@ilayaperumalg ilayaperumalg requested a review from chrisjs April 16, 2021 05:36
@chrisjs
Copy link
Contributor

chrisjs commented Apr 16, 2021

merged in d84e6c7

@chrisjs chrisjs closed this Apr 16, 2021
@ilayaperumalg
Copy link
Contributor Author

@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 additionalContainers and you can refer to this test for how to use it. Thanks!

@isha1kh
Copy link

isha1kh commented Apr 19, 2021

@ilayaperumalg - Yes am going to try this soon, thanks.

@isha1kh
Copy link

isha1kh commented Apr 23, 2021

@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.

@ilayaperumalg
Copy link
Contributor Author

On the container restart question, You need to set the restart policy for the container spec .

On the UI, you would only see the additionalContainers as a root property and won't see the nested properties for the container. Please feel free to work on supporting this feature if you are willing to contribute. Thanks!

@umutcann
Copy link
Contributor

Hi @ilayaperumalg, @isha1kh

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.

@ilayaperumalg
Copy link
Contributor Author

You need to set the container properties similar to how we set here

@umutcann
Copy link
Contributor

Thanks @ilayaperumalg , I did not notice before :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Deploying an sidecar container
5 participants