Remove IPC_LOCK capability

[pabrahamsson]

Since we know we're deploying to k8s and are already disabling mlock (also see #80), is there a need for IPC_LOCK?
This also helps with deploying on for example Openshift as we now only need --set server.uid and --set server.gid for the ranges allowed by the restricted SCC. No more mucking around with SCCs and capabilities.

[tongpu]

Always great to see that someone already created the PR I just wanted to start working on. 👍

@jasonodonnell The only way that I can envision that this could break existing deployments is if someone would have explicitly defined disable_mlock = false in either server.standalone.config or server.ha.config.

[tongpu]

@pabrahamsson You probably should also remove the two test cases in test/acceptance/server-ha.bats and test/acceptance/server.bats

[pabrahamsson]

Thank you @tongpu, updated.
@jasonodonnell let me know if I should rebase

[karabijavad]

this would also be nice for allowing deployment on eks + fargate

[pabrahamsson]

@jasonodonnell is there anything I can do to help getting this PR merged?

[karabijavad]

@pabrahamsson you would probably want to conditionally have the securityContext capability exist based on some .Values parameter

some people may want that security context field there

perhaps a .Values.mlock_enabled bool, defaulting to true, which adds the securityContext.capabilities element?

[pabrahamsson]

@karabijavad while I can do what you suggest I'd like to understand the reasoning. The conditionals you're mentioning were already removed as part of #80. mlock is disabled by default (and can't be enabled through values.yaml) hence what's the purpose of IPC_LOCK? It sounds to me like either both mlock and IPC_LOCK are supported (through values.yaml) or both should be removed. Am I missing something?

[karabijavad]

@pabrahamsson my apologies. i had no idea about that. youre right.

[jasonodonnell]

LGTM, thanks!

[lucaspouzac]

Hello, could you release new version with this fix please ?

Thanks!