usage: teuthology-openstack [-v] [--dry-run] [-s SUITE] [-c CEPH] [-k KERNEL]
                            [-f FLAVOR] [-d DISTRO]
                            [--suite-branch SUITE_BRANCH] [-e EMAIL] [-N NUM]
                            [-l JOBS] [--subset SUBSET] [-p PRIORITY]
                            [--timeout TIMEOUT] [--filter FILTER]
                            [--filter-out FILTER_OUT] [--throttle THROTTLE]
                            [--suite-relpath SUITE_RELPATH] [-r RERUN]
                            [-R RERUN_STATUSES] [-D DISTROVERSION] [-n NEWEST]
                            [-S SHA1] [--ceph-repo CEPH_REPO]
                            [--suite-repo SUITE_REPO]
                            [--sleep-before-teardown SLEEP_BEFORE_TEARDOWN]
                            [--key-name KEY_NAME]
                            [--key-filename KEY_FILENAME] [-h] [--wait]
                            [--name NAME] [--nameserver NAMESERVER]
                            [--simultaneous-jobs SIMULTANEOUS_JOBS]
                            [--controller-cpus CONTROLLER_CPUS]
                            [--controller-ram CONTROLLER_RAM]
                            [--controller-disk CONTROLLER_DISK] [--setup]
                            [--teuthology-git-url TEUTHOLOGY_GIT_URL]
                            [--teuthology-branch TEUTHOLOGY_BRANCH]
                            [--ceph-workbench-git-url CEPH_WORKBENCH_GIT_URL]
                            [--ceph-workbench-branch CEPH_WORKBENCH_BRANCH]
                            [--upload] [--archive-upload ARCHIVE_UPLOAD]
                            [--archive-upload-url ARCHIVE_UPLOAD_URL]
                            [--test-repo TEST_REPO] [--no-canonical-tags]
                            [config_yaml [config_yaml ...]]

Run a suite of ceph integration tests. A suite is a directory containing
facets. A facet is a directory containing config snippets. Running a suite
means running teuthology for every configuration combination generated by
taking one config snippet from each facet. Any config files passed on the
command line will be used for every combination, and will override anything in
the suite. By specifying a subdirectory in the suite argument, it is possible
to limit the run to a specific facet. For instance -s upgrade/dumpling-x only
runs the dumpling-x facet of the upgrade suite.

Display the http and ssh access to follow the progress of the suite
and analyze results.

  ssh -i teuthology-admin.pem ubuntu@

positional arguments:
  config_yaml           Optional extra job yaml to include

optional arguments:
  -v, --verbose         be more verbose
  --dry-run             Do a dry run; do not schedule anything
  -s SUITE, --suite SUITE
                        The suite to schedule
  -c CEPH, --ceph CEPH  The ceph branch to run against
  -k KERNEL, --kernel KERNEL
                        The kernel branch to run against; if not supplied, the
                        installed kernel is unchanged
  -f FLAVOR, --flavor FLAVOR
                        The ceph packages shaman flavor to run
                        with:('default', 'crimson', 'notcmalloc', 'jaeger')
  -d DISTRO, --distro DISTRO
                        Distribution to run against
  --suite-branch SUITE_BRANCH
                        Use this suite branch instead of the ceph branch
  -e EMAIL, --email EMAIL
                        When tests finish or time out, send an email here
  -N NUM, --num NUM     Number of times to run/queue the job
  -l JOBS, --limit JOBS
                        Queue at most this many jobs
  --subset SUBSET       Instead of scheduling the entire suite, break the set
                        of jobs into <outof> pieces (each of which will
                        contain each facet at least once) and schedule piece
                        <index>. Scheduling 0/<outof>, 1/<outof>, 2/<outof>
                        ... <outof>-1/<outof> will schedule all jobs in the
                        suite (many more than once).
  -p PRIORITY, --priority PRIORITY
                        Job priority (lower is sooner)
  --timeout TIMEOUT     How long, in seconds, to wait for jobs to finish
                        before sending email. This does not kill jobs.
  --filter FILTER       Only run jobs whose description contains at least one
                        of the keywords in the comma separated keyword string
  --filter-out FILTER_OUT
                        Do not run jobs whose description contains any of the
                        keywords in the comma separated keyword string
  --throttle THROTTLE   When scheduling, wait SLEEP seconds between jobs.
                        Useful to avoid bursts that may be too hard on the
                        underlying infrastructure or exceed OpenStack API
                        limits (server creation per minute for instance).
  --suite-relpath SUITE_RELPATH
                        Look for tasks and suite definitions in
                        thissubdirectory of the suite repo.
  -r RERUN, --rerun RERUN
                        Attempt to reschedule a run, selecting only thosejobs
                        whose status are mentioned by--rerun-status.Note that
                        this is implemented by scheduling anentirely new suite
                        and including only jobs whosedescriptions match the
                        selected ones. It does sousing the same logic as
                        --filter.Of all the flags that were passed when
                        schedulingthe original run, the resulting one will
                        onlyinherit the suite value. Any others must bepassed
                        as normal while scheduling with thisfeature.
                        A comma-separated list of statuses to be usedwith
                        --rerun. Supported statuses are: 'dead','fail',
                        'pass', 'queued', 'running', 'waiting'
  -D DISTROVERSION, --distroversion DISTROVERSION, --distro-version DISTROVERSION
                        Distro version to run against
  -n NEWEST, --newest NEWEST
                        Search for the newest revision built on allrequired
                        distro/versions, starting fromeither --ceph or --sha1,
                        backtrackingup to <newest> commits
  -S SHA1, --sha1 SHA1  The ceph sha1 to run against (overrides -c)If both -S
                        and -c are supplied, -S wins, andthere is no
                        validation that sha1 is containedin branch
  --ceph-repo CEPH_REPO
                        Query this repository for Ceph branch and SHA1
  --suite-repo SUITE_REPO
                        Use tasks and suite definition in this repository
  --sleep-before-teardown SLEEP_BEFORE_TEARDOWN
                        Number of seconds to sleep before the teardown
  --key-name KEY_NAME   OpenStack keypair name
  --key-filename KEY_FILENAME
                        path to the ssh private key. Default:
                        ['/home/docs/.ssh/id_rsa', '/home/docs/.ssh/id_dsa',
  -h, --help            show this help message and exit
  --wait                block until the suite is finished
  --name NAME           OpenStack primary instance name
  --nameserver NAMESERVER
                        nameserver ip address (optional)
  --simultaneous-jobs SIMULTANEOUS_JOBS
                        maximum number of jobs running in parallel
  --controller-cpus CONTROLLER_CPUS
                        override default minimum vCPUs when selecting flavor
                        for teuthology VM
  --controller-ram CONTROLLER_RAM
                        override default minimum RAM (in megabytes) when
                        selecting flavor for teuthology VM
  --controller-disk CONTROLLER_DISK
                        override default minimum disk size (in gigabytes) when
                        selecting flavor for teuthology VM
  --setup               deploy the cluster, if it does not exist
  --teardown            destroy the cluster, if it exists
  --teuthology-git-url TEUTHOLOGY_GIT_URL
                        git clone url for teuthology
  --teuthology-branch TEUTHOLOGY_BRANCH
                        use this teuthology branch instead of main
  --ceph-workbench-git-url CEPH_WORKBENCH_GIT_URL
                        git clone url for ceph-workbench
  --ceph-workbench-branch CEPH_WORKBENCH_BRANCH
                        use this ceph-workbench branch instead of main
  --upload              upload archives to an rsync server
  --archive-upload ARCHIVE_UPLOAD
                        rsync destination to upload archives
  --archive-upload-url ARCHIVE_UPLOAD_URL
                        Public facing URL where archives are uploaded
  --test-repo TEST_REPO
                        Package repository to be added on test nodes, which
                        are specified as NAME:URL, NAME!PRIORITY:URL or
                        @FILENAME, for details see below.
  --no-canonical-tags   configure remote teuthology to not fetch tags from
                        http://github.com/ceph/ceph.git in buildpackages task

test repos:

Test repository can be specified using --test-repo optional argument
with value in the following formats:  NAME:URL, NAME!PRIORITY:URL
or @FILENAME. See examples:

1) Essential usage requires to provide repo name and url:

    --test-repo foo:http://example.com/repo/foo

2) Repo can be prioritized by adding a number after '!' symbol
   in the name:

    --test-repo 'bar!10:http://example.com/repo/bar'

3) Repo data can be taken from a file by simply adding '@' symbol
   at the beginning argument value, for example from yaml:

    --test-repo @path/to/foo.yaml

  where `foo.yaml` contains one or more records like:

  - name: foo
    priority: 1
    url: http://example.com/repo/foo

4) Or from json file:

    --test-repo @path/to/foo.json

   where `foo.json` content is:


Several repos can be provided with multiple usage of --test-repo and/or
you can provide several repos within one yaml or json file.
The repositories are added in the order they appear in the command line or
in the file. Example:

    # The foo0 repo will be included first, after all that have any priority,
    # in particular after foo1 because it has lowest priority
    - name: foo0
      url: http://example.com/repo/foo0
    # The foo1 will go after foo2 because it has lower priority then foo2
    - name: foo1
      url: http://example.com/repo/foo1
      priority: 2
    # The foo2 will go first because it has highest priority
    - name: foo2
      url: http://example.com/repo/foo2
      priority: 1
    # The foo3 will go after foo0 because it appears after it in this file
    - name: foo3
      url: http://example.com/repo/foo3

Equivalent json file content below:

        "name": "foo0",
        "url": "http://example.com/repo/foo0"
        "name": "foo1",
        "url": "http://example.com/repo/foo1",
        "priority": 2
        "name": "foo2",
        "url": "http://example.com/repo/foo2",
        "priority": 1
        "name": "foo3",
        "url": "http://example.com/repo/foo3"

At the moment supported only files with extensions: .yaml, .yml, .json, .jsn.

teuthology-openstack 0.0.1.dev296+gb1dac55