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

openshift_compatibility #995

Merged

Conversation

Baboulinet-33
Copy link
Contributor

Hello,

I wanted to use victoria logs on openshift but openshift don't like fixed securityContext ("fsGroup" "runAsUser" "runAsGroup").
So I've make some modification on chart to be compatible with openshift.

The modification are clearly a copy/paste of bitnami solution (https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_compatibility.tpl) - you can keep the modification on _helpers.tpl or add the following dependency on all charts:

dependencies:
- name: common
  repository: oci://registry-1.docker.io/bitnamicharts
  version: 2.x.x

For all securityContext parameter, you have a property enabled to enable this parameter.
And you have the parameter global.compatibility.openshift.adaptSecurityContext with value auto, force, disabled:

  • auto: apply if the detected running cluster is Openshift
  • force: perform the adaptation always
  • disabled: do not perform adaptation

An example with auto:

spec:
      containers:
        - name: victoria-logs-single-server
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
              - ALL
            readOnlyRootFilesystem: true
          image: "victoriametrics/victoria-logs:v0.5.2-victorialogs"
          [...]
      securityContext:
        fsGroup: 2000
        runAsNonRoot: true
        runAsUser: 1000
      terminationGracePeriodSeconds: 60
      volumes:
        - name: server-volume
          emptyDir: {}

With force:
openshift: force

spec:
      containers:
        - name: victoria-logs-single-server
          securityContext:
            allowPrivilegeEscalation: false
            capabilities:
              drop:
              - ALL
            readOnlyRootFilesystem: true
          image: "victoriametrics/victoria-logs:v0.5.2-victorialogs"
          [...]
      securityContext:
        runAsNonRoot: true
      terminationGracePeriodSeconds: 60
      volumes:
        - name: server-volume
          emptyDir: {}

@Haleygo
Copy link
Contributor

Haleygo commented Apr 30, 2024

Error: INSTALLATION FAILED: template: victoria-metrics-alert/templates/alertmanager-deployment.yaml:43:24: executing "victoria-metrics-alert/templates/alertmanager-deployment.yaml" at <.Values.alertmanager.securityContext.enabled>: nil pointer evaluating interface {}.enabled

@Baboulinet-33 Could you please fix victoria-metrics-alert chart and solve the conflict?

@Baboulinet-33
Copy link
Contributor Author

Hi, I forgot to respond but I addressed the points mentionned

Copy link
Contributor

@Haleygo Haleygo left a comment

Choose a reason for hiding this comment

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

LGTM

@Haleygo Haleygo merged commit ad7834f into VictoriaMetrics:master May 8, 2024
42 of 43 checks passed
Haleygo added a commit that referenced this pull request May 8, 2024
@Haleygo Haleygo mentioned this pull request May 8, 2024
@Haleygo
Copy link
Contributor

Haleygo commented May 8, 2024

Thanks for contribution!

Haleygo added a commit that referenced this pull request May 10, 2024
Haleygo added a commit that referenced this pull request May 10, 2024
* make up changelogs for:
#1002,
#995

* follow up dfe967d

* make gen-docs

* prepare release
@Baboulinet-33 Baboulinet-33 deleted the feat/openshift_compliance branch May 13, 2024 13:31
@TheMeier
Copy link

just a remark for some future similar changes. maybe it is a good idea to introduce new toggles with defaults set so they match the previous behaviour.
IMHO the default for server.podSecurityContext.enabled should have been true

@Haleygo
Copy link
Contributor

Haleygo commented May 15, 2024

just a remark for some future similar changes. maybe it is a good idea to introduce new toggles with defaults set so they match the previous behaviour. IMHO the default for server.podSecurityContext.enabled should have been true

@TheMeier Yes, thank you for notice and sorry for inconvenience!
It shouldn't break any previous customized securityContext, please see #1023.

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.

None yet

3 participants