Fix SecurityGroup availability status by counting security group rules

[gndrmnn]

Consider this minimal example:

---
apiVersion: openstack.k-orc.cloud/v1alpha1
kind: SecurityGroup
metadata:
  name: security-group
spec:
  cloudCredentialsRef:
    cloudName: openstack
    secretName: cloud-config
  resource:
    name: security-group
    description: k-orc generated
    rules:
      - description: rule k-orc
        direction: ingress
        protocol: icmp
        # ethertype: IPv4
        # ethertype: IPv6
        remoteIPPrefix: "0.0.0.0/0"
        portRange:
          min: 1
          max: 42

If we select ethertype is IPv4, everything is fine and the security group rules as well as the security group is created successfully.

However, if we select ethertype is IPv6 the remoteIPPrefix field is (expectedly) rejected by openstack with a http error. The security group is already created at this point and, despite the rule error, enters a true availability state.

With this commit SecurityGroups now count their specified rules and compare them to the number of rules in their ORC status and the openstack resource. As the security group rules are only ever part of one security group, this should be enough to reliably determine, if all rules have been successfully created.

As the mismatch between remoteIPPrefix and ethertype is apparently to be solved "client-side" by ORC in the future, I am not sure, if and how to add a test for this? I think the ultimate reason why a security group rule is rejected by openstack in the future is not known yet, right?

Fixes #120

[mandre]

Comparing the length of security group rules between the spec and the status indeed seems like the right approach for deciding whether the security group should be considered as available.

However I wonder if we should not reschedule a reconcile similarly to what we do in server or volume for example. That's very likely the reason why the flamingo job failed.

[gndrmnn]

However I wonder if we should not reschedule a reconcile similarly to what we do in server or volume for example. That's very likely the reason why the flamingo job failed.

Got it.

Do you want me to add tests for this change? If so, is it possible to simulate an openstack error using kuttl?