Description of problem: When setting SERVE_HTTPS=False to disable https in assisted service api, assisted service pod shows READY 1/2, giving a false sense of failure when the intention is to disable https. Version-Release number of selected component (if applicable): " Operator Package Name: assisted-service-operator", " Source Index Image: quay.io/ocpmetal/assisted-service-index:latest", " Operator Bundle: quay.io/ocpmetal/assisted-service-operator-bundle:latest", " Operator Bundle Version: 0.0.1 (latest identified)", " Operator Bundle Image Digest: sha256:9c027842d4f608318dccda6d709bc021ad5aa92a27b44ad790866e159af0160e", " Operator Bundle Image Digest Short: 9c027842d4f6", How reproducible: 100% Steps to Reproduce: 1. Deploy latest assisted service via assisted service operator 2. Set SERVE_HTTPS=False in assisted service deployment (Must scale back assisted-service-operator in order to retain the SERVE_HTTPS value [oc scale --replicas=0 deployment/assisted-service-operator]) 3. Check oc get pods Actual results: oc get pods NAME READY STATUS RESTARTS AGE assisted-service-86cdb758dc-p8czw 1/2 Running 4 4m56s Due to Readiness probe failed: Get "https://[fd01:0:0:5::176]:8090/ready": http: server gave HTTP response to HTTPS client Expected results: oc get pods NAME READY STATUS RESTARTS AGE assisted-service-86cdb758dc-p8czw 2/2 Running 4 4m56s Additional info: While I can only imagine someone not using https in a lab /testing env, the ready 1/2 status is confusing.
This is unfortunate, but expected behavior currently. Setting SERVE_HTTPS only tells the service to serve http, but the operator doesn't adjust the health checks accordingly. If we want the operator to take action based on this value we should probably add it to the agentserviceconfig CRD. Thoughts on how we should do that @dzager?
I don't think we want to support disabling https in any official capacity for now. If SERVE_HTTPS is changed in the deployment the expected behavior currently is for the operator to change it back. Anything else is undefined (probably will break things) and should likely be scoped and discussed as an enhancement. If the bmac flow still fails with the latest fix for https://bugzilla.redhat.com/show_bug.cgi?id=1953795 in place, then that bug will probably be the place to report it so I'm going to close this one.