Bug #6884
cephtool/test.sh fails in the nightlies
0%
Description
logs: ubuntu@teuthology:/a/teuthology-2013-11-21_23:00:19-rados-next-testing-basic-plana/113055
This test actually failed on the next branch but it would be nice if someone could go through it and verify what really failed, as its hard to distinguish between the positive and negative cases here.
ubuntu@teuthology:/a/teuthology-2013-11-21_23:00:19-rados-next-testing-basic-plana/113055 ubuntu@teuthology:/a/teuthology-2013-11-21_23:00:19-rados-next-testing-basic-plana/113055$ cat config.yaml archive_path: /var/lib/teuthworker/archive/teuthology-2013-11-21_23:00:19-rados-next-testing-basic-plana/113055 description: rados/singleton/{all/cephtool.yaml fs/btrfs.yaml msgr-failures/few.yaml} email: null job_id: '113055' kernel: &id001 kdb: true sha1: 68174f0c97e7c0561aa844059569e3cbf0a43de1 last_in_suite: false machine_type: plana name: teuthology-2013-11-21_23:00:19-rados-next-testing-basic-plana nuke-on-error: true os_type: ubuntu overrides: admin_socket: branch: next ceph: conf: global: ms inject socket failures: 5000 mon: debug mon: 20 debug ms: 1 debug paxos: 20 osd: debug ms: 1 debug osd: 5 osd op thread timeout: 60 osd sloppy crc: true fs: btrfs log-whitelist: - slow request sha1: 203065c076daf9aaa9ade3d7cdd1b10e6700bfe6 ceph-deploy: branch: dev: next conf: client: log file: /var/log/ceph/ceph-$name.$pid.log mon: debug mon: 1 debug ms: 20 debug paxos: 20 install: ceph: sha1: 203065c076daf9aaa9ade3d7cdd1b10e6700bfe6 s3tests: branch: next workunit: sha1: 203065c076daf9aaa9ade3d7cdd1b10e6700bfe6 owner: scheduled_teuthology@teuthology roles: - - mon.a - mon.b - mon.c - mds.a - osd.0 - osd.1 - osd.2 - client.0 targets: ubuntu@plana19.front.sepia.ceph.com: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDD6IKIC04NNnglNNCE0RbuLXjCtUPzT/5zY8qZBcP4bKOkrmj71GlVX+8t2KwsUZA4SYJeczG/WRaHWsmlUELTbpNlATQuo/cFszrSeRugFMq8lWY/qQOCRp3y8vg6BLJZmtZ6PL4LtWxtorZt5buPseJ7x6tXeWoIfTPmTSXnFLY1YxWGz9Gk8/2GOGTJ40NSOaQ+idlcTj+jsRy23tweZI4hjKIaTPTYLbjaSYhYDqDT9XGeBAYeNeNTYGFJcB37ptCzu8jkWuFmKcEhQ9efQZwjhN5BOSEgJP4BXSxVRWJKKf4cf9oFw5oMatMaiZR9BaFjL99jMDWNSj5ddhSV tasks: - internal.lock_machines: - 1 - plana - internal.save_config: null - internal.check_lock: null - internal.connect: null - internal.check_conflict: null - internal.check_ceph_data: null - internal.vm_setup: null - kernel: *id001 - internal.base: null - internal.archive: null - internal.coredump: null - internal.sudo: null - internal.syslog: null - internal.timer: null - chef: null - clock.check: null - install: null - ceph: log-whitelist: - wrongly marked me down - had wrong client addr - had wrong cluster addr - workunit: clients: all: - cephtool - mon/pool_ops.sh teuthology_branch: next verbose: true
History
#1 Updated by Greg Farnum over 10 years ago
- Status changed from New to In Progress
- Assignee set to Greg Farnum
This is the change to the monitor API; it needs to get 0/1 instead of false/true.
#2 Updated by Tamilarasi muthamizhan over 10 years ago
when tested with wip-6884 for workunit and ceph branch, test failed. not sure why.
logs: ubuntu@mira055:/home/ubuntu/new_6884_final
#3 Updated by Greg Farnum over 10 years ago
2013-11-22T17:07:30.288 INFO:teuthology.task.workunit.client.0.err:[10.214.134.140]: + echo note: assuming mon.a is on the currenet host 2013-11-22T17:07:30.288 INFO:teuthology.task.workunit.client.0.err:[10.214.134.140]: + sudo ceph daemon mon.a version 2013-11-22T17:07:30.288 INFO:teuthology.task.workunit.client.0.err:[10.214.134.140]: + grep version 2013-11-22T17:07:30.289 INFO:teuthology.task.workunit.client.0.out:[10.214.134.140]: note: assuming mon.a is on the currenet host 2013-11-22T17:07:30.371 INFO:teuthology.task.workunit.client.0.err:[10.214.134.140]: admin_socket: exception getting command descriptions: [Errno 2] No such file or directory
I'm really not sure what's going on there, except that I don't think the two patches I added did it. This failure is tickling my brain, but I'm not sure why as it's not showing up recently when searching my mail.
#4 Updated by Greg Farnum over 10 years ago
Actually, it looks like mon.a and client.0 are on different hosts, and that would certainly prevent the admin socket from being present; is this a non-default config? :)
roles: - - mon.a - mon.b - mds.a - osd.0 - osd.1 - osd.2 - - mon.c - osd.3 - osd.4 - osd.5 - client.0
#5 Updated by Tamilarasi muthamizhan over 10 years ago
the test passed when run with mon and client on the same node.
#6 Updated by Greg Farnum over 10 years ago
- Status changed from In Progress to Resolved
Yay. Merged into next yesterday after an email report of success.