Operator trips over provided super-user secret

[quay]

Operator trips over provided super-user secret

[wkulhanek]

Same with Config Secret

[stencell]

I ran into this the other day when I was testing, but never got around to opening an issue. For the SuperUser, you need to use:

superuserCredentialsSecretName

This might just be a docs bug. I didn't get a chance to run into the problem with config secret. That looks like it should be okay, but I don't know if the validation maybe failed on your config secret content vs the name?

https://github.com/redhat-cop/quay-operator/blob/master/pkg/controller/quayecosystem/validation/validate.go#L22-L57

[sabre1041]

@stencell @wkulhanek Wanted to add a few comments related to this issue. PR #29 was submitted and merged to help address them. Some of the highlights:

1. Quay requires a superuser password of at least 8 characters. Added new validation that checks this after resource creation
2. Setup error handling was not properly implemented. Even though an error occurred during the setup process, the provisioning process continued to deploy Quay. Since setup failed, due to internal validation, the secret that is generated after the setup process completes successfully was not generated.
3. The superuserCredentialsSecretName was not mapped properly on the QuayEcosystem object. This has been corrected
4. A complete rewrite of how registry storage is managed was previously completed in order to eventually support fully defining replication scenarios. README was out of date #30 submitted to address this

I would like to push our a new tag for the repository that will provide a stable baseline prior to integrating clair. Looking to do it this week after additional community testing

[wkulhanek]

Fixed.