MarvinCli

marvincli deploy config-file=<marvin-config-file>

EX: marvincli deploy config-file=setup/dev/advanced.cfg

Deploys a data center under CS.

Args:

1. *config-file:config file to use for deploying the datacenter. EX: setup/dev/advanced.cfg

marvincli generateapis api-spec-file= <api-spec-file> folder-path=<path where the output cloudstackAPI information is dumped>

EX: marvincli generateapis api-spec-file=/etc/cloud/cli/commands.xml folder-path=tools/marvin/marvin/

Generates the CloudStack API directory containing CS api information references, which is further used by marvin when making api calls to CS. It uses /etc/cloud/cli/commands.xml to generate these.

Args:

1. api-spec-file: sample spec file path as similar to one /etc/cloud/cli/commands.xml. If no spec-file is provided, it uses /etc/cloud/cli/commands.xml file.
2. folder-path : output folder path where cloudstackAPI directory will be created with all cs api reference information. If no path is provided, it will use the default path as tools/marvin/marvin to generate these.

Note: This currently, is generated as part of mvn profile, with this we can remove the particular mvn profile.

marvincli generateapis end-point=<CS Endpoint ip> folder-path=<path where the output cloudstackAPI information is dumped>

EX: marvincli generateapis end-point=localhost folder-path=tools/marvin/marvin/

Generates the CloudStack API directory containing CS api information references, which is further used by marvin when making api calls to CS. Host ip of CS machine, is used to retrieve this information.

Args:

1. *end-point: ip or name of the cs end point to be used to retrieve api information
2. folder-path : output folder path where cloudstackAPI directory will be created with all cs api reference information. If no path is provided, it will use the default path as tools/marvin/marvin to generate these.

Note: This currently, is generated as part of mvn profile, with this we can remove the particular mvn profile.

marvincli deploydc_and_runtest config-file=<path_to_marvin_cfg> tc-path=<test suite or test case folder path> zone=<name of the zone> hyp-type=<hypervisor_type> required_hardware=<true\false>

EX: marvincli deploydc_and_runtest config-file=setup/dev/advanced.cfg tc-path=test/integration/smoke zone=sandbox-siumulator hyp-type=simulator required-hardware=false

Deploys a datacenter "and" runs test cases as well.

Args:

1. *config-file: Config file path to deploy dc and for running tests. EX: setup/dev/advanced.cfg. Its a mandatory argument. If not provided, it will throw error and exit.
2. *tc-path: Test Case folder or file path to pick tests from.
3. zone: Name of the zone to be used for running test cases. If nothing is provided, picks up the first zone inside cfg for testing.
4. hyp-type: Signifies hypervisor type to be used for running tests, EX: xenserver,kvm,vmware etc. So, if we have four different hosts under different clusters, this will help to run tests against a particular hypervisor type, helps in running multiple tracks against multiple hypervisors at a given time. If nothing is provided, will pick up the first hypervisor from config file.
5. required-hardware: If set to False, picks up test cases which does not require hardware to run, helps in running when we dont have simulator and to test business logic of cs.

marvincli --h

(or)

marvincli --cli-help

Prints the marvincli help. Its commands usage and args information in colored text.

marvincli --v

(or)

marvincli --version

marvincli build_and_install cs-folder-path=<cloudstack code root dir > api-spec-file=<api spec file generated by CS EX: /etc/cloud/cli/commands.xml>

EX: marvincli build_and_install cs-folder-path=/root/cs-4.5/cloudstack/ api-spec-file=EX: /etc/cloud/cli/commands.xml

Builds and install marvin. It uses api spec file

EX: /etc/cloud/cli/commands.xml

file to build cs apis, used for marvin reference and then installs marvin.

Args:

*1. cs-folder-path : CS code root folder path EX: /root/cs-4.5/cloudstack/

2. api-spec-file: api spec file generated by CS EX: /etc/cloud/cli/commands.xml

Note : api-spec-file is not a mandatory field. If nothing is provided, it will use /etc/cloud/cli/commands.xml

marvincli sync_and_install cs-folder-path=<cloudstack code root dir > end-point=<CS installed host ip>

EX: marvincli sync_and_install cs-folder-path=/root/cs-4.5/cloudstack/ end-point=localhost

Builds and install marvin. Its the same as previous command except that it uses an installed CS endpoint to generate apis, build and install marvin instead.

EX: /etc/cloud/cli/commands.xml

file to build cs apis, used for marvin reference and then installs marvin.

Args:

*1. cs-folder-path : CS code root folder path EX: /root/cs-4.5/cloudstack/

2. end-point: CS installed host ip EX: localhost

Note : end-point is not a mandatory field. If nothing is provided, it will use localhost

marvincli runtest config-file=<path_to_marvin_config> tc-path=<path to test case suite or test suite directory> zone=<name of zone> hyp-type=<xenserver or kvm or vmware> required_hardware=<true\false>

EX: marvincli runtest config-file=setup/dev/advanced.cfg tc-ath=test/integration/smoke zone=sandbox-siumulator hyp-type=simulator required-hardware=false

Runs a single test suite or list of suites, mentioned either smoke or component mentioned with below options.

Args:

1. *config-file: Config file path to deploy dc and for running tests. EX: setup/dev/advanced.cfg. Its a mandatory argument. If not provided, it will throw error and exit.
2. *tc-path: Test Case folder or file path to pick tests from.
3. zone: Name of the zone to be used for running test cases. If nothing is provided, picks up the first zone inside cfg for testing.
4. hyp-type: Signifies hypervisor type to be used for running tests, EX: xenserver,kvm,vmware etc. So, if we have four different hosts under different clusters, this will help to run tests against a particular hypervisor type, helps in running multiple tracks against multiple hypervisors at a given time. If nothing is provided, will pick up the first hypervisor from config file.
5. required-hardware: If set to False, picks up test cases which does not require hardware to run, helps in running when we dont have simulator and to test business logic of cs.