Mibserver localmibs with persitence volume not attached

[josepclavero]

Hi,

I am using helm to deploy the mib-server deployment using a persistence volume, since in my case I have multiple nodes. For some reason, when applying the changes the system does not work correctly, specifically the pvc is not mounted in the pod. This is my configuration:

mibserver:
image:
repository: docker.da.inf.sta/supervisio/pysnmp/mibs/container
tag: "1.15.18"

enablePV: true
localMibs:
pathToMibs: ""
persistence:
existingClaim: "snmp-mibserver"

resources:
limits:
cpu: "1"
memory: 1Gi
requests:
cpu: 200m
memory: 512Mi

Although I have mounted the pvc in the pod manually, applying this config:
apiVersion: apps/v1
kind: Deployment
metadata:
name: snmp-mibserver
namespace: sc4snmp
spec:
template:
spec:
containers:
- name: mibserver
securityContext:
readOnlyRootFilesystem: false
volumeMounts:
- name: task-pv-storage
mountPath: /app/new_mibs/src/vendor
volumes:
- name: task-pv-storage
persistentVolumeClaim:
claimName: snmp-mibserver

With this manual solution, I can confirm that the pvc exists, the mibs exist in the path: "/app/new_mibs/src/vendor" and are compiled. But I would like to solve the problem with the helm in order to have all the configuration for future deployments.
Many thanks,

[josepclavero]

Maybe the problem I have is that I don't have administrator permissions on our K8s cluster. I can't create pv, although I can create pvc. Could this be the cause?

[omrozowicz-splunk]

Hey @josepclavero, I think you might have encountered the problem I was working on in this PR: pysnmp/mibs#203

There were some problems rendering helm template in case of existing pvc, the fix is included in version 1.15.20. Would be great if you can verify if it works well now 😄

[josepclavero]

Hey Olga,
It still doesn't work for me, for some reason I no longer have write access.
I can see this error on the mibserver pod: mkdir: cannot create directory 'output': Read-only file system.
Thanks

[omrozowicz-splunk]

Hey @josepclavero, thanks for the response! I retested in on my device and identified issue with security context not being properly generated, everything is described here: #1194

Also to test it you need to not only update image tag, but also the subchart (because the change was made to helm templates). There is a way to run it from local files, but we'll soon update mibserver dependency and we'll release SC4SNMP beta - will put it here when it's done 🚀

[JohnTorr]

I was about to raise this issue myself. It comes about becasue you have specified existingClaim.

There is a bug in the Chart that says you don't want any PVC when you have something set as existingClaim.

So when it comes time to add the existingClaim in the deployments the helm if statement is in the wrong location and doesn't even attach the existingClaim.

[JohnTorr]

Hey Olga, It still doesn't work for me, for some reason I no longer have write access. I can see this error on the mibserver pod: mkdir: cannot create directory 'output': Read-only file system. Thanks

This is a different issue.
This one is due to the SecurityContext not allowing you to run your container as user 10001, Hence you don't have permissions to create the ./output directory.

It is not a good practice to be writing temporary data into the container ephemeral storage. I will be raising this as a bug myself if I don't see it raised already. The Chart should realistically have the option to have an empty volume for the temporary stuff.

[omrozowicz-splunk]

I was about to raise this issue myself. It comes about becasue you have specified existingClaim.

There is a bug in the Chart that says you don't want any PVC when you have something set as existingClaim.

So when it comes time to add the existingClaim in the deployments the helm if statement is in the wrong location and doesn't even attach the existingClaim.

Hey @JohnTorr, thank you for your input! Do you mean a bug fixed with this PR? pysnmp/mibs#203 Or did you find any other problem?

This is a different issue. This one is due to the SecurityContext not allowing you to run your container as user 10001, Hence you don't have permissions to create the ./output directory.

I tested this using an OpenEBS PVC with local MIBs, and it worked fine after fixing this issue.
I think it would make sense to let users configure the securityContext via values.yaml — it’d make the chart more flexible, especially since real-world setups can vary quite a bit.

It is not a good practice to be writing temporary data into the container ephemeral storage. I will be raising this as a bug myself if I don't see it raised already. The Chart should realistically have the option to have an empty volume for the temporary stuff.

Got it — so we're only mounting /app/new_mibs/src/vendor, and /app/new_mibs/output is just using the container's ephemeral storage, which means it gets wiped every time the pod restarts.
You're saying it'd be better to mount an emptyDir volume there instead for temp data. Makes sense!
Let me know if I got that wrong — feel free to open an issue if needed.

[JohnTorr]

Hey @JohnTorr, thank you for your input! Do you mean a bug fixed with this PR? pysnmp/mibs#203 Or did you find any other problem?

Yes looking at the change in logic without testing yet I believe you have solved this bug.

I will open a new issue for the other comment so this thread is not sidetracked.

[ajasnosz]

Hello @josepclavero, the changes were made and the newest mibserver was released in 1.12.3-beta.7 Remember to run microk8s helm3 repo update and then run helm upgrade with --version 1.12.3-beta.7. This is the upgrade guide.

We’ve tested them on our side and everything looks good, but we’d like to confirm that they resolve the issue you mentioned before we release this code as the official version.