Change:
// Name of the workload. Name string // Values of parameters used in the workloadTemplate. <del> Params map[string]int </del> <ins> Params params } type params struct { params map[string]int // isUsed field records whether params is used or not. isUsed map[string]bool } // UnmarshalJSON is a custom unmarshaler for params. // // from(json): // 	{ // 		"initNodes": 500, // 		"initPods": 50 // 	} // // to: //	params{ //		params: map[string]int{ //			"intNodes": 500, //			"initPods": 50, //		}, //		isUsed: map[string]bool{}, // empty map //	} // func (p *params) UnmarshalJSON(b []byte) error { aux := map[string]int{} if err := json.Unmarshal(b, &aux); err != nil { return err } p.params = aux p.isUsed = map[string]bool{} return nil } // get returns param. func (p params) get(key string) (int, error) { p.isUsed[key] = true param, ok := p.params[key] if ok { return param, nil } return 0, fmt.Errorf("parameter %s is undefined", key) } // unusedParams returns the names of unusedParams func (w workload) unusedParams() []string { var ret []string for name := range w.Params.params { if !w.Params.isUsed[name] { ret = append(ret, name) } } return ret </ins> } // op is a dummy struct which stores the real op in itself.

Discussion:
Note: this issue should be viewed in the context of . If this happens, this is very likely a typo where someone used a parameter in a way they didn't mean to (for example, ). /sig scheduling /assign
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
/remove-lifecycle stale
/good-first-issue
This request has been marked as suitable for new contributors. Please ensure the request meets the requirements listed . If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : /good-first-issue Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Hi this is my first time contributing to kubernetes. can you provide me some guidance on how to to get started?
Hi, is this issue still valid to work on?
yes, this is still valid. I recommend starting with the and reading from there.
are you still working on this issue or should I work on it.
I would like to work on this issue if you haven't started already.
would it be ok if I took a look at this?
/assign
Hi Can you help me in why its not assigning the values to createNodes and createPods directly and using the opcode and countParam in performance-
We use a field to differentiate between different operations. The value of the field (e.g. "createNodes") determines the operation. The field defines the number of pods/nodes to create. What do you mean by "assigning the values to createNodes and createPods directly"?
Thanks for the information.

By assigning, I just meant that whether we can assign createNodes directly like ( createNodes: $initNodes ).
I don't think that's possible since there can potentially be other parameters besides the countParam. For example: Different operations could potentially have different parameters.
createNodes and createPods aren't the only operations. Other operations (e.g. churn and barrier), including future ones, may not fit that format. It's also easier to parse and more explicit this way.
Thanks , Having a doubt more, in performance- under the name:SchedulingPodAntiAffinity, ! why are we giving the same values in 5000Nodes as given in 500Nodes, or this is an error.
that sounds like a typo indeed
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-contributor-experience at . /lifecycle stale
Hello Are you still going to work on this issue?
Hi I have worked on the issue but not working for a while as was unsure about the exact problem.
, no problem if you are willing to work on this issue, shall unassign myself
/unassign
Thanks :)
/assign
/remove-lifecycle stale
hey! I am beginner and I interested in scheduling and I know basics of scheduling , so how can I start to contribute on this issue.
Sorry, PR for this issue has already created.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs. This bot triages issues and PRs according to the following rules: After 90d of inactivity, is applied After 30d of inactivity since was applied, is applied After 30d of inactivity since was applied, the issue is closed You can: Mark this issue or PR as fresh with Mark this issue or PR as rotten with Close this issue or PR with Offer to help out with [Issue Triage][1] Please send feedback to sig-contributor-experience at . /lifecycle stale [1]: