mayadata-io / mayadata-io/d-operators
usecase(litmus): verify creation of cstor pool using director recommendations
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 10
- Forks
- 6
- PR merge metrics
- No merged PRs in 30d
Description
ProblemSatement: As an automation engineer I would like to implement a litmus testcase to verify creation of cstorpool via Director's recommendations API. I want to avoid kubectl, grep, awk, etc in my testcase. I want the testcase should be declarative without use of templating, etc. This testcase should be easy to write & understand. I want the intent to be as close as possible to the business/test logic without exposing technical aspects e.g. http status code, retries, body format, etc.
Refer: https://github.com/mayadata-io/oep-e2e/pull/439
TestCaseID: TCID-DIR-OP-CSP-REC-CREATE-MIRROR
Following are the steps performed:
- use of secret to fetch Director user & pw
- config to provide Director info e.g. ip address, group id, etc
- verify openebs components to be in running state
- director api to verify its components in running state
- director api to fetch recommendations
- fetch recommendation id
- director api to list capacity recommendations
- director api to list device recommendations
- director api to create cstor pool
- director api to fetch cstorpool operation id
- director api to execute cstor pool
- director api to wait for successful creation of cstor pool
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the Litmus testcase described in this issue and the referenced oep-e2e pull request; trace the Director recommendations API steps from component checks through cstor pool creation. Done means a declarative testcase uses the listed secret and configuration, avoids kubectl and shell parsing, and verifies successful pool creation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, kubernetes
- Domain
- api, testing
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100