Sebastian Woehrl

> Would it be cleaner to just require the autoscaler to be created in the same namespace as the cluster so non-superusers can use it? I think it will be...

Hi @AndersBennedsgaard. We are already planning a new release for the beginning of December. More frequent releases would be good, but we currently have a bottleneck in maintainers, so no...

> I'm not saying that you necessarily have to provide a snapshot release of the operator, but I would personally love to have the opportunity to easily test the operator...

Hi @nilushancosta. Thanks for reporting this. This is clearly a bug and the operator should just wait if the cluster is not yet correctly reachable.

A solution to this problem was implemented in the linked PR and merged to main. Closing this issue as solved.

Hi @anubisg1 > I'm thinking this fix isn't in the release yet? Correct. This PR was merged shortly after the last release. It will be included in the next version...

@anubisg1 That might very well be the best solution. Have the user either use only securityconfig or (basically) only CRDs.

@saketmht Such a PR would be highly appreciated. For backwards compatibility the old securityconfig logic needs to remain, but it can be changed to only apply the `config.yml` if the...

@saketmht > Then I will create separate issues (one at a time) for each CRD that I will add. We can discuss the CRD fields/designs in the same issue. Is...

@saketmht > For this I think, the admin certs (which are used by the securityconfig-job to execute the securityadmin script) can be mounted to the cluster pods as well and...