mayadata-io / mayadata-io/d-operators

usecase(litmus): verify creation of cstor pool using director recommendations

Open
#48 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

cstorpoolauto recipe recommendation run use case
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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.