-
Notifications
You must be signed in to change notification settings - Fork 480
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
Avoid initContainer while mounting a volume #1179
Comments
Is this duplicate of #891 ? If yes, you might be able to specify image like this: <plugin>
<groupId>org.eclipse.jkube</groupId>
<artifactId>kubernetes-maven-plugin</artifactId>
<version>${jkube.version}</version>
<configuration>
<enricher>
<config>
<jkube-volume-permission>
<imageName>name-foo</imageName>
</jkube-volume-permission>
</config>
</enricher>
</configuration>
</plugin> |
Thanks for the help to change the image, is there any option to avoid the usage of init container ? |
@thibaut-fluteaux-infy : Would it be possible for you to share a reproducer project? I will help me debug cause for behavioral difference between two plugins. |
considering volumeclaim "volumetest" allready exist. regards |
I see you're using quite an old version of the Fabric8 Maven Plugin. I tried with the latest version of FMP v4.4.1 and I was able to see initContainers generated. I think this change was done by me in fabric8io/fabric8-maven-plugin#1318 |
thanks for your answer, no way to disable the usage of init container by jkube ? |
Right now, no. If you want we can add a configuration option to disable this here: However, we need to decide if it's really the way we would like to go. |
I encountered the same problem and did not want to use initContainer automatically loaded in Depl0ymentConfig, so I disabled jkube-volume-Permission.My configuration is as follows: <configuration>
<enricher>
<excludes>
jkube-volume-permission
<excludes>
</enricher>
</configuration> |
…isable initContainer addition (eclipse-jkube#1179) Currently, VolumePermissionEnricher adds an initContainer in order to fix permission of currently mounted PeristentVolume. However, some users have reported that they don't really need it. Adding a flag to disable this behavior. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…isable initContainer addition (eclipse-jkube#1179) Currently, VolumePermissionEnricher adds an initContainer in order to fix permission of currently mounted PeristentVolume. However, some users have reported that they don't really need it. Adding a flag to disable this behavior. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…isable initContainer addition (eclipse-jkube#1179) Currently, VolumePermissionEnricher adds an initContainer in order to fix permission of currently mounted PeristentVolume. However, some users have reported that they don't really need it. Adding a flag to disable this behavior. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…ty out of VolumePermissionEnricher (eclipse-jkube#1179) Related to eclipse-jkube#1179 + Move setting PersistentVolumeClaim's storageClass related logic into a new enricher : PersistentVolumeClaimStorageClassEnricher . This way user can simply exclude VolumePermissionEnricher to opt out of volume permission initContainer. + Deprecate VolumePermissionEnricher's `defaultStorageClass` and `useStorageClassAnnotation` fields in favor of PersistentVolumeClaimStorageClassEnricher equivalents. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
I've moved out functionality unrelated to Volume permissions in #1179 Now in order to avoid initContainer you just need to exclude the enricher as @kuailexingmao suggested. |
…ty out of VolumePermissionEnricher (eclipse-jkube#1179) Related to eclipse-jkube#1179 + Move setting PersistentVolumeClaim's storageClass related logic into a new enricher : PersistentVolumeClaimStorageClassEnricher . This way user can simply exclude VolumePermissionEnricher to opt out of volume permission initContainer. + Deprecate VolumePermissionEnricher's `defaultStorageClass` and `useStorageClassAnnotation` fields in favor of PersistentVolumeClaimStorageClassEnricher equivalents. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…ty out of VolumePermissionEnricher (eclipse-jkube#1179) Related to eclipse-jkube#1179 + Move setting PersistentVolumeClaim's storageClass related logic into a new enricher : PersistentVolumeClaimStorageClassEnricher . This way user can simply exclude VolumePermissionEnricher to opt out of volume permission initContainer. + Deprecate VolumePermissionEnricher's `defaultStorageClass` and `useStorageClassAnnotation` fields in favor of PersistentVolumeClaimStorageClassEnricher equivalents. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…ty out of VolumePermissionEnricher (eclipse-jkube#1179) Related to eclipse-jkube#1179 + Move setting PersistentVolumeClaim's storageClass related logic into a new enricher : PersistentVolumeClaimStorageClassEnricher . This way user can simply exclude VolumePermissionEnricher to opt out of volume permission initContainer. + Deprecate VolumePermissionEnricher's `defaultStorageClass` and `useStorageClassAnnotation` fields in favor of PersistentVolumeClaimStorageClassEnricher equivalents. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…ty out of VolumePermissionEnricher (eclipse-jkube#1179) Related to eclipse-jkube#1179 + Move setting PersistentVolumeClaim's storageClass related logic into a new enricher : PersistentVolumeClaimStorageClassEnricher . This way user can simply exclude VolumePermissionEnricher to opt out of volume permission initContainer. + Deprecate VolumePermissionEnricher's `defaultStorageClass` and `useStorageClassAnnotation` fields in favor of PersistentVolumeClaimStorageClassEnricher equivalents. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…ty out of VolumePermissionEnricher (eclipse-jkube#1179) Related to eclipse-jkube#1179 + Move setting PersistentVolumeClaim's storageClass related logic into a new enricher : PersistentVolumeClaimStorageClassEnricher . This way user can simply exclude VolumePermissionEnricher to opt out of volume permission initContainer. + Deprecate VolumePermissionEnricher's `defaultStorageClass` and `useStorageClassAnnotation` fields in favor of PersistentVolumeClaimStorageClassEnricher equivalents. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…ty out of VolumePermissionEnricher (eclipse-jkube#1179) Related to eclipse-jkube#1179 + Move setting PersistentVolumeClaim's storageClass related logic into a new enricher : PersistentVolumeClaimStorageClassEnricher . This way user can simply exclude VolumePermissionEnricher to opt out of volume permission initContainer. + Deprecate VolumePermissionEnricher's `defaultStorageClass` and `useStorageClassAnnotation` fields in favor of PersistentVolumeClaimStorageClassEnricher equivalents. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…ty out of VolumePermissionEnricher (eclipse-jkube#1179) Related to eclipse-jkube#1179 + Move setting PersistentVolumeClaim's storageClass related logic into a new enricher : PersistentVolumeClaimStorageClassEnricher . This way user can simply exclude VolumePermissionEnricher to opt out of volume permission initContainer. + Deprecate VolumePermissionEnricher's `defaultStorageClass` and `useStorageClassAnnotation` fields in favor of PersistentVolumeClaimStorageClassEnricher equivalents. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
…ty out of VolumePermissionEnricher (#1179) Related to #1179 + Move setting PersistentVolumeClaim's storageClass related logic into a new enricher : PersistentVolumeClaimStorageClassEnricher . This way user can simply exclude VolumePermissionEnricher to opt out of volume permission initContainer. + Deprecate VolumePermissionEnricher's `defaultStorageClass` and `useStorageClassAnnotation` fields in favor of PersistentVolumeClaimStorageClassEnricher equivalents. Signed-off-by: Rohan Kumar <rohaan@redhat.com>
Description
Since I switch from fabric8 to JKUBE, When I add a volume in my description.yaml.
An initContainer using busybox is automatically added, was not the case with fabric8.
The main issue, my openshift instance dont have access to busybox image (due to corporate restriction)
Info
mvn -v
) : 3.8.1The text was updated successfully, but these errors were encountered: