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

use dedicated image for projects persistence PVC init tasks #1078

Merged
merged 1 commit into from Nov 3, 2022

Conversation

FlorianLaunay
Copy link
Contributor

Delegate chmod and chgrp tasks to a dedicated init container running as root.

Fixes #1055

SUMMARY

On some storage provisioners, owner of mounted PVCs will not be mapped to the fsGroup security context setting.

So directory modifications at the mount point level like chmod, chown or chgrp will not be possible for a non-root running container.

Solution : modify deployment template roles/installer/templates/deployments/deployment.yaml.j2 to create a second init container dedicated to running tasks related to projects persistence volume

ISSUE TYPE
  • Bug, Docs Fix or other nominal change
ADDITIONAL INFORMATION

Tested with operator 0.30.0

{% if init_container_extra_volume_mounts -%}
{{ init_container_extra_volume_mounts | indent(width=12, first=True) }}
securityContext:
runAsUser: 0
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, we can't do this. OpenShift and other locked-down flavors of Kubernetes require addition privileges in order to use securityContext. We will need to take a look and see if there is another way of fixing this.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps by using a bare quay.io/centos/centos image for this task instead of _control_plane_ee_image and removing this dedicated securityContext.

Somehow it is like reverting #1012 just for chmod and chgrp.

What do you think about ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in 761640b

Tested with operator 0.30.0

I will rebase if you are okay

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@shanemcd is this way better?

@FlorianLaunay FlorianLaunay changed the title run projects persistence PVC related tasks in a dedicated init pod running as root use dedicated image for projects persistence PVC init tasks Oct 7, 2022
@FlorianLaunay
Copy link
Contributor Author

@TheRealHaoLiu what do you think about this fix for #1055 ?

@bpedersen2
Copy link

Looks like a valid approach to me

@bpedersen2
Copy link

Tested against devel-HEAD, works nicely.

@shanemcd
Copy link
Member

shanemcd commented Nov 1, 2022

Hello. Apologies for the delay here. I ran the CI checks and they failed. I think this will get resolved with a rebase. Please do that and we'll get this merged ASAP.

@shanemcd
Copy link
Member

shanemcd commented Nov 1, 2022

@rooftopcellist can you help drive this one home?

@FlorianLaunay
Copy link
Contributor Author

FlorianLaunay commented Nov 3, 2022

@shanemcd no apologies needed, it is an open source project 😉
Rebase done 👌

@shanemcd
Copy link
Member

shanemcd commented Nov 3, 2022

@FlorianLaunay I appreciate you saying that, and wish more people shared that sentiment. 😅 I just kicked off the CI checks, if the tests pass this will merge.

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

Successfully merging this pull request may close these issues.

K3s issue with Operator version 0.29.0
4 participants