Ceph » CephFS

tests passed

http://pulpito.ceph.com/zyan-2016-03-01_20:05:19-hadoop-jewel-testing-basic-mira/

old libcephfs only has permission check for open. Now, It has full permission checks (open, lookup, setattr ...)

Maybe this has same issue as the python libcephfs tests did, they were creating files with mode 0, which used to work

Wait, can you expand on that John? I wasn't really looking at the python tests, although I know it involved root ownership — didn't you just start running them as sudo?
I think that should generally be VFS-controlled, not something in our Client environment (I mean, I know we're checking mode and uid now, but the VFS is also gating on those first, so if we're disagreeing it's probably a bug?).

Greg Farnum wrote:

Wait, can you expand on that John? I wasn't really looking at the python tests, although I know it involved root ownership — didn't you just start running them as sudo?

Yeah, it was a s/nosetests/sudo nosetests/

I think that should generally be VFS-controlled, not something in our Client environment (I mean, I know we're checking mode and uid now, but the VFS is also gating on those first, so if we're disagreeing it's probably a bug?).

Right, but there's no VFS in the libcephfs python tests or in hadoop.

On this subject, the C libcephfs API has the ll functions (used by ganesha) that enable it to pass through UIDs. But the python API and the 'normal' C API doesn't have that, and just reads the UID from the environment. I'm thinking we maybe want to add uid/gid to the ceph_create function so that users are explicitly picking UID (since getting it from environment was not enforced anyway)

d'oh, right. Okay, I get the problem now. I've run this through a couple of times in my latest integration branch, btw, and it seems fine (although we're still hitting a failure in hadoop sometimes; need to dig into that).