Thanks for the links. I looked at the doc and couldn't find any source code style guides. Are there any? On Tue, Sep 25, 2018 at 11:36 PM kefu chai <tchaikov@xxxxxxxxx> wrote: > > On Wed, Sep 26, 2018 at 11:42 AM Victor Denisov <denisovenator@xxxxxxxxx> wrote: > > > > I'm also curious where the source code of teutology tests is. > > Is the source code in the main ceph tree or somewhere else. > > What script starts teutology test suit? > > Victor, have you read > http://docs.ceph.com/docs/master/dev/#integration-tests-aka-ceph-qa-suite, > http://docs.ceph.com/teuthology/docs/README.html and > https://github.com/ceph/ceph/tree/master/qa ? they are good start for > those who want to learn more about teuthology testing. teuthology > tests are driven by https://github.com/ceph/teuthology. and the test > suites are located under https://github.com/ceph/ceph/tree/master/qa . > > > > > On Tue, Sep 25, 2018 at 08:35:05PM +0800, kefu chai wrote: > > > On Tue, Sep 25, 2018 at 12:30 PM Victor Denisov <denisovenator@xxxxxxxxx> wrote: > > > > > > > > Hi, > > > > > > > > I have several questions regarding development process: > > > > > > > > - When I pick up a bug from bug queue should I just assign a bug to > > > > myself or put it in in progress state? > > > > > > both would be ideal. if you just change the status of it to "in > > > progress", anyone interested in the bug would wonder who is now > > > working on it? if you just assign it to yourself without updating the > > > status, i'd think, so this guy is just showing his interest in this > > > bug, but he has not started working on it yet. > > > > > > > > > > > - What does verified state of a bug mean? > > > > > > when a bug is reported, we cannot be sure it's actually a valid one. > > > by "verified", i think that means it's a valid bug in the sense that > > > it's not caused by environmental issues, or setting combinations that > > > do not make sense, or corrupted filesystem, etc. > > > > > > > > > > > - What teutology test run consists of and how can I run it on my dev > > > > machine? > > > > > > could you be more specific? but i will try to answer you question > > > anyway. it basically consists of most of things you need to know for > > > debugging an issue. for instances, the sha1 of the ceph commit being > > > tested, the sha1 of the qa suite, the log of all ceph daemons. the > > > coredump if any. > > > > > > not all teuthology can be rerun in your test machine (easily). some > > > of them involve multiple test nodes. when it comes to CephFSTestCase, > > > you can use a vstart cluster to drive it, see > > > https://github.com/ceph/ceph/blob/master/qa/tasks/vstart_runner.py. > > > and if it's a standalone test, you can use qa/run-standalone.sh to > > > drive it, see https://github.com/ceph/ceph/tree/master/qa/standalone . > > > > > > > > > > > Thanks, > > > > Victor. > > > > > > > > > > > > -- > > > Regards > > > Kefu Chai > > > > Thanks, > > Victor. > > > > -- > Regards > Kefu Chai
