[ovirt-users] Answer file key for "nonlocal postgres"

[Jamie Lawrence]

> On Mar 25, 2017, at 10:57 PM, Yedidyah Bar David <didi at redhat.com> wrote:
> 
> On Fri, Mar 24, 2017 at 3:08 AM, Jamie Lawrence
> <jlawrence at squaretrade.com> wrote:

[…]

>> Anyone know what I am missing?
> 
> Probably OVESETUP_PROVISIONING/postgresProvisioningEnabled
> and OVESETUP_DWH_PROVISIONING/postgresProvisioningEnabled .

Appreciate the reply - thanks!

> That said, I strongly recommend to not try and write the answer file
> by hand. Instead, do an interactive setup with the exact conditions […]

I know what I was doing is unsupported. I was wondering down the wrong troubleshooting path for a bit there, but I think ultimately what I need is also unsupported.

It was because I was trying to push this into our extant DB infrastructure, which is PG 9.5. Which I found doesn’t work with a local-install, either. (I was thinking it would work due to past experience with things that demand an old Postgres; IME, PG generally has pretty solid forward-compatibility.)

So that leads me to my next question: if I install under the supported  version and dump/load/reconfigure to PG9.5.3, is anyone aware of any actual problems (other than lack of official support)? In doing answerfile-driven installs repeatedly, the point where it now fails is after the DB load, with ovirt-aaa-jdbc-tool choking and failing the run.

The reason I’m considering that as my fallback, nothing-else-worked option is that the DB needs to live in one of our existing clusters. We are a heavy Postres shop with a lot of hardware, humans and process devoted to maintaining it, and the DBAs would hang my corpse up as a deterrent to others if I started installing ancient instances in random places for them to take care of.

> https://bugzilla.redhat.com/show_bug.cgi?id=1396925

Was unaware of that; thanks for sharing (and doing!) it.

Thanks for the help,

-j