Description of problem: When I use postgresql 9.5 pod as external db for testing pod appliance with external db. The database pod gets broken. It doesn't matter whether I use ephemeral or persistent postgresql pod. There is no such issue in cloudforms 5.9. Version-Release number of selected component (if applicable): 5.8.4.2 How reproducible: 100% Steps to Reproduce: 1. create project and deploy postgresql 9.5 pod. Values can be db=vmdb, user=root, password=smartvm 2. create another project and deploy pod appliances using external db template. It should use created above db. NOTE: ip address should be actual pod ip not service ip 3. Take a look at postgresql pod Actual results: postgresql pod becomes not ready. created db gets removed and etc. Expected results: there shouldn't be any harmful operations over db
It sounds like this is only an issue in a very specific deployment scenario where a user is hosting their database on a pod which is not our PG pod and configuring the external database template to an internal pod IP. Is that correct? Is this something we would ever suggest to a customer? Ievgen, can you confirm that the external database template works properly in 5.8 when configured against a database running on a VM? If this case works I would assume this becomes much lower priority. Also, can you post logs from the failure (DB and application logs) as well as the specific PG container image you're using for the test?
Nick, yes, that's correct. that's why I set initially set medium prio and didn't add blocker tag. yes when it comes to external database template + vm db, it works right as well. So, this affects only our test automation for 5.8 and won't probably be noticed by customer. I'll attach logs in a bit.
Okay, thanks Ievgen. Given the content from comment 3 (and that 5.8 in OpenShift is tech-preview) can we tone down the priority and severity and remove the blocker flag?
Agreed, back to medium and removing blocker. If this is something a customer won't hit and only impacts testing, is there any workaround for your testing?
yes, I have workaround for testing. So, it doesn't affect testing much.
I don't think this is something we're going to take on. There's a workaround for testing and no reason that customers would deploy like this.