Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Improve vstart_runner to (optionally) create its own cluster #12800
Some minor comments. I want to give this a try but won't be able to until I get back to the USA. Too many troubles with the VPN.
I tried running the example test:
I had to fix a few permission denied errors by adding some sudos. Here's a patch:
After fixing that, I ran across a strange error or newly uncovered bug. A
To debug, I added a stat after the creation of
So it went to owner root and permissions 0500. Looks like a bug or is this something else?
@batrick when cephfs-data-scan injects a file from just its data objects, it invents some new metadata -- the uid/gid gets set to root/root.
Last I ran these tests they definitely didn't require root, I wonder if you've changed machines and need to update configuration to enable mounting ceph fuse as non-root?
Isn't that damage supposed to be repaired before getfattr gets executed?
I'm using my laptop as the rex machines' disks are full. I am able to do fuse mounts as a normal user. I was trying to resolve problems I saw here after a failure (undoing my patch and retrying):
I had noticed the
Looking back in the logs, I remember I also saw this:
which made me think ceph-fuse had failed to start but now I see it was just normal log output after the process exited.
So I think I don't actually need root for ceph-fuse (except for the dcache consistency) but I still have this chmod problem. Have you seen this before?
@jcsp, tried again and got the same error. I don't have anything in my PYTHONPATH. I'm just using a virtualenv with teuthology and then starting vstart_runner.py:
By the debug log, it appears it is using LocalFuseMount as expected.
In any case I think you can merge this if you want. This is most likely not relating to this PR. Other tests like tasks.cephfs.test_readahead work just fine.