-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DeployableByOLM" err="<nil>" result=ERROR for open-access ibm-mq-operator 1.3.1 #844
Comments
Adding more details because it seems to be a regression introduced between preflight 1.0.8 and preflight 1.1.0. Here I used another open-access operator for the tests, it passed DeployableByOlm on preflight 1.0.8 and failed DeployableByOlm starting from preflight 1.1.0: quay.io/rh-nfv-int/testpmd-operator:v0.2.9 Logs on 1.0.8 (DeployableByOlm passed):
Logs on 1.1.0 (DeployableByOlm failed):
Logs on 1.4.2 (DeployableByOlm failed):
|
@tkrishtop thanks for reporting this! The operator image you gave me there is the operator application container itself, but The core of the issue is that the bundle is malformed. The ValidateOperatorBundle check result is not included in your snippets, but I would guess that it is also failing in your execution, indicating that the service account in the
To test, I rebuilt the bundle with that service account manifest specifying a different service account and all tests passed without a problem. For reference, I've temporarily published that bundle here The ScorecardOlmSuiteCheck check throws an error as well for the same reason. I do find it odd that this is being listed as an error, and will look into why - but if I had to guess, it's because the scorecard results themselves report an error instead of a failure. I'll check our logic that causes a scorecard check value to get reported as an erroring check vs. a failing check, but there may not be much we can do about this. With that said, DeployableByOLM still fails with, seemingly, no error. I'll look into the reasons why this is happening and see what I can do to fix it soon. All of this relates to the testpmd-operator-bundle - but you initially reported this issue with another bundle that's not accessible to me. It's entirely possible that the case there may be different, but have a look and see if this may be the cause. If not, let us know and I'm happy to troubleshoot further - but we may need to work with you get a better look at the bundle in question. Let us know. |
Hi @komish, thank you for having a look! Just a quick update before heading into the weekend:
The IBM operator is also an open-access one:
|
Awesome, thank you! I'll check the same with this bundle. Have a great weekend! |
This bundle was also failing validation, and DeployableByOLM performs a validation as a preventative measure, but logs failure as an error because it's an executional failure and not a deployment failure. I've submitted a PR to fix the issue with the nil errors when the DeployableByOLM check passes, which should help provide more information here. |
@komish, so starting from preflight 1.1.0, DeployableByOLM is not an independent check anymore, it will fail if ValidateOperatorBundle fails. Is that correct? |
It is still an independent check, but because we perform a validation within DeployableByOLM to reduce the likelihood of a failure in deployment that is similar to Bundle Validation, a failure in bundle validation will probably cause a failure in DeployableByOLM. In other words, if the bundle does not validate, deployable will probably fail very early. |
Well, at least, it's not the case for ibm-mq-operator and testpmd-operator. These operators passed DeployableByOlm on preflight 1.0.8, that's why the issue was open. Although the current situation looks logical and the error is now clear. Thank you for the fix, @komish! Going to close the issue. |
Bug Description
There is an unclear error produced by DeployableByOLM on an open-access IBM operator:
Could we have a bit more logs in that situation?
Version and Command Invocation
preflight version: the same error on pr843 and 1.4.2
Expected Result
Get a bit more logs to understand why DeployableByOLM threw an error
Actual Result
DeployableByOLM" err="<nil>" result=ERROR
The text was updated successfully, but these errors were encountered: