Bug 1014012

This happens only if provisioning is selected, right?

In provisioning you can start postgres if already stopped, but please note that if database is not configured, it will fail.

Please make sure it does not leak outside of provisioning.

(In reply to Alon Bar-Lev from comment #1)
> This happens only if provisioning is selected, right?

Yes.

Before that, a warning is emitted:
[WARNING] Cannot connect to database using existing credentials: engine_20131001120806@localhost:5432

This is done in db/connection.py during stage setup.

Do you think that this is enough, and we should close notabug? Assume that if the user sees this warning she should understand the issue, stop setup and check postgres? Perhaps ask if we should start postgres?

> 
> In provisioning you can start postgres if already stopped, but please note
> that if database is not configured, it will fail.
> 
> Please make sure it does not leak outside of provisioning.

As I wrote above, it might make sense to actually try to start postgres in db/connection. Not sure.

(In reply to Yedidyah Bar David from comment #2)
> (In reply to Alon Bar-Lev from comment #1)
> > This happens only if provisioning is selected, right?
> 
> Yes.
> 
> Before that, a warning is emitted:
> [WARNING] Cannot connect to database using existing credentials:
> engine_20131001120806@localhost:5432
> 
> This is done in db/connection.py during stage setup.
> 
> Do you think that this is enough, and we should close notabug? Assume that
> if the user sees this warning she should understand the issue, stop setup
> and check postgres? Perhaps ask if we should start postgres?

If this causing product overwrite, then better to stop installation.

But if setup fails later on because it cannot actually connect to database then we are good.

> 
> > 
> > In provisioning you can start postgres if already stopped, but please note
> > that if database is not configured, it will fail.
> > 
> > Please make sure it does not leak outside of provisioning.
> 
> As I wrote above, it might make sense to actually try to start postgres in
> db/connection. Not sure.


No, all service start/stop and assumption of local installation should go into provisioning/postgres.py.

You can try and start it if osetupcons.ProvisioningEnv.POSTGRES_PG_VERSION exists at _misc.

(In reply to Alon Bar-Lev from comment #3)
> (In reply to Yedidyah Bar David from comment #2)
> > (In reply to Alon Bar-Lev from comment #1)
> > > This happens only if provisioning is selected, right?
> > 
> > Yes.
> > 
> > Before that, a warning is emitted:
> > [WARNING] Cannot connect to database using existing credentials:
> > engine_20131001120806@localhost:5432
> > 
> > This is done in db/connection.py during stage setup.
> > 
> > Do you think that this is enough, and we should close notabug? Assume that
> > if the user sees this warning she should understand the issue, stop setup
> > and check postgres? Perhaps ask if we should start postgres?
> 
> If this causing product overwrite, then better to stop installation.
> 
> But if setup fails later on because it cannot actually connect to database
> then we are good.

No, it does not fail - as I wrote, it (re)starts postgresql after changing pg_hba and creates a new database. It also does not overwrite the database, but it does replace some conf/pki/etc files.

So, just change this warning to error and stop?
I need to check what happens during an upgrade from legacy.

> 
> > 
> > > 
> > > In provisioning you can start postgres if already stopped, but please note
> > > that if database is not configured, it will fail.
> > > 
> > > Please make sure it does not leak outside of provisioning.
> > 
> > As I wrote above, it might make sense to actually try to start postgres in
> > db/connection. Not sure.
> 
> 
> No, all service start/stop and assumption of local installation should go
> into provisioning/postgres.py.
> 
> You can try and start it if osetupcons.ProvisioningEnv.POSTGRES_PG_VERSION
> exists at _misc.

It can't be done at misc, because if we do manage to start pg and connect to the db, we need not ask about provisioning.

(In reply to Yedidyah Bar David from comment #4)
>
> No, it does not fail - as I wrote, it (re)starts postgresql after changing
> pg_hba and creates a new database. It also does not overwrite the database,
> but it does replace some conf/pki/etc files.
> 
> So, just change this warning to error and stop?
> I need to check what happens during an upgrade from legacy.

It continuing to avoid getting stack if there is junk configuration. But maybe we can re-fine this as setup is more stable now.

For legacy upgrade, we must have database available if not we can just abort setup.

(In reply to Alon Bar-Lev from comment #5)
> (In reply to Yedidyah Bar David from comment #4)
> >
> > No, it does not fail - as I wrote, it (re)starts postgresql after changing
> > pg_hba and creates a new database. It also does not overwrite the database,
> > but it does replace some conf/pki/etc files.
> > 
> > So, just change this warning to error and stop?
> > I need to check what happens during an upgrade from legacy.
> 
> It continuing to avoid getting stack if there is junk configuration. But
> maybe we can re-fine this as setup is more stable now.

So? just change this warning to error and stop? :-)

> 
> For legacy upgrade, we must have database available if not we can just abort
> setup.

Sorry, now verified and on upgrade from legacy this warning is not emitted. If we do want it to be, we'd have to make the change I am currently working on, http://gerrit.ovirt.org/19689, smarter.

Thinking about this again, the core problem is a wrong identification of legacy after partial cleanup. I suggest to change the test for this to (also) check
if /etc/sysconfig/ovirt-engine exists. Thoughts?

(In reply to Yedidyah Bar David from comment #6)
> (In reply to Alon Bar-Lev from comment #5)
> > (In reply to Yedidyah Bar David from comment #4)
> > >
> > > No, it does not fail - as I wrote, it (re)starts postgresql after changing
> > > pg_hba and creates a new database. It also does not overwrite the database,
> > > but it does replace some conf/pki/etc files.
> > > 
> > > So, just change this warning to error and stop?
> > > I need to check what happens during an upgrade from legacy.
> > 
> > It continuing to avoid getting stack if there is junk configuration. But
> > maybe we can re-fine this as setup is more stable now.
> 
> So? just change this warning to error and stop? :-)
> 
> > 
> > For legacy upgrade, we must have database available if not we can just abort
> > setup.
> 
> Sorry, now verified and on upgrade from legacy this warning is not emitted.
> If we do want it to be, we'd have to make the change I am currently working
> on, http://gerrit.ovirt.org/19689, smarter.
> 
> Thinking about this again, the core problem is a wrong identification of
> legacy after partial cleanup. I suggest to change the test for this to
> (also) check
> if /etc/sysconfig/ovirt-engine exists. Thoughts?

Another check can be whether /etc/ovirt-engine/.pgpass exists and has content.
We'll also have to rename/remove it on upgrade - Currently it's left as-is.
3.2's cleanup deletes its content, leaving it with just a newline (in my test system).

Again... do whatever you think that resolve this issue.

Provided:

1. postgres service management is done only at provisioning plugin.

2. upgrade (normal and legacy) should fail in any case if database is down.

I think that with these two rules there can be a solution.

Included in 3.3.1 beta

Verified on rhevm3.3 is20
after engine-setup, stoped ovirt-engine and postgresql services.
ran engine-setup, which immediately failed:

[ ERROR ] Failed to execute stage 'Environment setup': Cannot connect to database using existing credentials: engine@localhost:5432
[ INFO  ] Stage: Clean up
          Log file is located at /var/log/ovirt-engine/setup/ovirt-engine-setup-20131030183456.log
[ INFO  ] Stage: Pre-termination
[ INFO  ] Stage: Termination
[ ERROR ] Execution of upgrade failed

oVirt 3.3.1 has been released