Description of problem: Deployment consistently fails for only a given template (eap64-mysql-persistent-s2i) Version-Release number of selected component (if applicable): OpenShift Master: v3.2.0.16 Kubernetes Master: v1.2.0-36-g4a3f9c5 How reproducible: Deploy the eap64-mysql-persistent-s2i template as-is and wait for the build to finish, then the deploy will attempt to happen and fail. This occurred at https://console.dev-preview-int.openshift.com/console/project/sspeiche-microservices Interesting event log 5:48:48 PM Replication Controller eap-app-3 Failed create Error creating: pods "eap-app-3-" is forbidden: service account sspeiche-microservices/eap-service-account was not found, retry after the service account is created 4 times in the last minute
I thinks you should create the eap-service-account first , the xpass templates have some special sa defined , for this template , you can use this[1] to create the sa. [1]https://github.com/jboss-openshift/application-templates/blob/master/secrets/eap-app-secret.json
Hi Steve, Looks like the json that is mentioned above is required based on the readme: https://github.com/jboss-openshift/application-templates/blob/master/docs/eap/eap64-mysql-persistent-s2i.adoc#secrets
This is a definite usability bug, could be fixed somewhat with docs. In this case (dev-preview) the user will start at the catalog and have no way to know how to get this information from the catalog. A few different alternatives: - add secret to the templates - remove https from the templates - somehow, inject the link or info for the readme - add the secret template to the catalog
+1 to updating docs or templates. Changing the component.
A few comments to the above - There should be no secrets in templates - There is already a template that doesn't include https (basic) - We're already working on docs for this topic, moving some of the upstream work into product docs. - The secret is *not* a template
Duplicate of 1327313?
Marking as dupe since 1327313 is already planning on addressing the SA creation. Steve, please let us know if you disagree. Thanks! *** This bug has been marked as a duplicate of bug 1327313 ***