I suspect that this is because you haven’t configured Jenkins to use a build user and it’s building your code as root. Our dockerfiles use the uid of the caller to own the files so that Jenkins can co

Omer, I’d be interested in seeing the stdout/stderr and logging from dfuse where this is happening. As you say the -f option should make it run in the foreground so if you’re not passing this then it

Ok, I’ve reproduced this. The issue is the dockerfile in 1.0.1 is doing a git clone rather than a COPY to get the code, so the dockerfile is fetching the wrong data. I guess the fix would be to update

It looks like you’re trying to use 1.0.1? I’ve just checked that out locally and there’s no reference to patchelf at all in the source tree at that point, we use it now for checking that build version

This will create a build a docker image using the Dockerfile from github, but the sources from the current directory so you need to do this from a checked-out copy of the source tree. Ashley. From: da

I would be grateful if you could try this PR on your Ubuntu 20.04 system. I was able to reproduce the problem here and this fixes it for me, it appears to be additional checks in newer kernels, combin

Peter, Thank you for the update. I had spoken to Gert privately and we’d looked into the Ubuntu issue a bit but he’d also switched to a different OS version for testing. As I said before we do have ub

Peter, There have been no changes in status since your email on the 5th, although there has been a new dependency added to DAOS recently, l4z-devel is now a required package. Your previous problems we

This specific issue is different appears to be at the dfuse/fuse kernel module level. I note you’re using a newer fuse driver than I am (7.31 vs 7.23) and also a newer libfuse3 as evidenced by the “Un

This case is different, the mount point here has not been used to create a container so dfuse is attempting to use the pool and container on the command line. The error reported is a DAOS error rather

Hi, This is the same issue as Gert hit last week, specifically that you’re providing the pool/container UUIDs twice to dfuse, one via the path and once on the command line. The fix in this case would

From: <daos@daos.groups.io> on behalf of Wu Huijun <huijunw91@...> Reply to: "daos@daos.groups.io" <daos@daos.groups.io> Date: Saturday, 6 June 2020 at 09:45 To: "daos@daos.groups.io" <daos@daos

Colin, I’m referring to the “Unified Name Space” feature or workflow that DAOS supports, in essence this is managed through the setting or a extended attribute “user.daos” on entries in the filesystem

Yes, I’d spotted this might be a problem recently when looking at fuse commit history. Fuse started off with one prototype, then updated and we updated daos to match, then they more recently added ver

Could you send me the command line you’re using and the error message? It would help to run in foreground mode to diagnose this. We recently added a check for the mount point to be a special UNS file

Hi, Server_group certainly seems a useful thing to add, service ranks I thought was scheduled for removal but would also make sense if it’s still in use. I can file a ticket and work on this as part o

That looks much better. You should be aware that daos will be using a byte-array for the values, so in this case 42 will be a string, not a integer. It’s likely that you’d want to use pickle/unpickle

The easiest way, assuming you want a single KV per container is to do the following: import pydaos cont = pydaos.cont(‘<pool_uuid>’, ‘<container_uuid>’) kv = cont.root_kv() kv[‘key’] = value If you wa

Alex, Can you elaborate on what it is you’re trying to achieve? There are really two parts to the python bindings, there’s pydaos.raw which is using ctypes to open the daos client shared library from

Patrick, Yes, we spotted that ourselves just after it landed. We’re trying to work out how to handle this, and if there are any other non-default python libs that we already depend on in our build tha