Ms/validate sec groups

[marsteg]

Is there a related GitHub Issue?

#4103

What is this change about?

Updating and enhancing the existing Validator for Security Groups

Does this PR introduce a breaking change?

It should not as Security Groups are not supported, yet.

Acceptance Steps

create sec-group.json:
E.g.:

{
  "name": "my-group0",
  "rules": [
    {
      "protocol": "tcp",
      "destination": "10.10.10.0/24",
      "ports": "443,80,8080"
    },
    {
      "protocol": "icmp",
      "destination": "10.10.10.0/24",
      "type": 8,
      "code": 0,
      "description": "Allow ping requests to private services"
    }
  ]
}

then create them:
cf curl -X POST "/v3/security_groups" -d@sec-group.json

Tag your pair, your PM, and/or team

@danail-branekov, @georgethebeatle

[danail-branekov]

I have added minor style comments. However, I believe we need tests for the new logic in the validator

[danail-branekov]

You do not need to check whether the string contains a comma or not, SplitSeq would return an iterator with a single element if not, or an iterator with multiple elements if so.

Consider the following example:

func main() {
	stringWithoutComma := "foo"
	stringWithComma := "bar,baz"

	fmt.Printf("slices.Collect(strings.SplitSeq(stringWithoutComma, \",\")) = %+v\n", slices.Collect(strings.SplitSeq(stringWithoutComma, ",")))
	fmt.Printf("slices.Collect(strings.SplitSeq(stringWitComma, \",\")) = %+v\n", slices.Collect(strings.SplitSeq(stringWithComma, ",")))
}

it produces

slices.Collect(strings.SplitSeq(stringWithoutComma, ",")) = [foo]
slices.Collect(strings.SplitSeq(stringWitComma, ",")) = [bar baz]

Having said that, you could iterate over the iterator directly, it does not make a difference whether the string contains commas or not

[marsteg]

i fixed that but Copilot is telling me, that this is buggy and I should just use strings.Split. What do you think - it could be wrong of course...

[danail-branekov]

My initial thought was to use strings.Split but as you used SplitSeq I thought it should be all right. Maybe strings.Split would be simpler.
Out of curiosity, why does copilot think it is buggy?

[marsteg]

The Feedback from Copilot was:
Potential implementation bug:
strings.SplitSeq in validator.go:125 isn’t a standard library function. If tests for multi-destination are added, compilation will fail. This likely should be strings.Split. I can patch this as part of the test addition if you want.

I googled a bit about the strings.SplitSeq and I think copilot just didn't know about it a lot since it's quite new (came in go 1.24). According to this link, it performas better than strings.Split, so I would stick with strings.SplitSeq:
https://groups.google.com/g/golang-checkins/c/zOqiRYhKIaI

Article where SplitSeq is introduced:
https://betterstack.com/community/guides/scaling-go/go-1-24/

[marsteg]

I added some more tests

[danail-branekov]

Looks good, I have added a comment on the test, feel free to apply it, or ignore it - both options are fine.

I am afraid the PR does not compile after you merged it with main. In main we adopted controller-runtime 0.23 which has few braking changes with regards to the webhook APIs. Nothing outrageous, still you would have to adopt it too in this change.

[danail-branekov]

@marsteg controllers tests are failing, see the workflow run. As they are all failing, I assume that there is some wiring missing somewhere