Replacement transformer fails for list

[hem2]

Describe the bug
Replacement transformer fails for list with "Error: wrong Node Kind for expected: ScalarNode was SequenceNode: value: . " error.

Steps To Reproduce
Change L47 to a list https://github.com/airshipit/airshipctl/blob/master/krm-functions/replacement-transformer/local-resource/example-use.yaml and run "kustomize fn run local-resource/example-use.yaml" and it fails with the above error.

Expected behavior
Replacement transformer should be able to replace of type list.

Environment

• airshipctl Version: latest on master
• Operating System: NA
• Kernel version: NA
• Kubernetes Version: NA
• Go version: go1.16.2
• Hardware specs (e.g. 4 vCPUs, 16GB RAM, bare metal vs VM): NA

[gnana03]

I would like to pick this

[eak13]

@gnana03 - it's all yours. Thanks.

[michaelfix]

@gnana03 , what t-shirt size would you estimate this effort to be?

• <=1 days | Small | refactor, 1 function, documentation
• 2-5 days | Medium | moderate complexity, generic code, or enhancement to existing feature
• 5-7+ days | Large | multiple functional areas; complex function or capability, or multiple PSs

[raliev12]

This issue seems invalid. We don't have to change object types, source and target fields types must match, so transformer behavior looks expected in described case. This is kind of protection measure - mixing types can cause multiple issues. Also, static validation (which we have enabled) verifies object type and its value as well, in case of mismatch - the error will be thrown. OpenAPIv3 schema doesn't support multiple types for an object:
type - Value MUST be a string. Multiple types via an array are not supported. [1]

As a workaround, you can use smp or json patch to remove value first, then apply transformer. But I would not recommend doing this for schema-declared kinds. Since we don't have a defined OpenAPIv3 schema for VariableCatalogue, such workaround could be applied.

[1] https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.3.md#schemaObject

[eak13]

@hem2 Reddy, can you take a look at Ruslan's comments & let us know if this is still an issue?

[hem2]

@ak3216 I agree with Ruslan. Let's close this. Thank you.

[eak13]

@hem2 thanks! Closing per comments above.