ovirt_experimental_master Fails: PostgreSQL is not Accessible During Engine Setup
by Anton Marchukov
Hello All.
FYI. We started to see multiple master system tests failing in row with the
following error in engine-setup logs [1]:
2017-01-17 06:46:29 DEBUG
otopi.ovirt_engine_setup.engine_common.database
database.getCredentials:1267 database connection failed
Traceback (most recent call last):
File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
line 1265, in getCredentials
] = self.isNewDatabase()
File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
line 370, in isNewDatabase
transaction=False,
File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
line 191, in execute
database=database,
File "/usr/share/ovirt-engine/setup/ovirt_engine_setup/engine_common/database.py",
line 125, in connect
sslmode=sslmode,
File "/usr/lib64/python2.7/site-packages/psycopg2/__init__.py", line
164, in connect
conn = _connect(dsn, connection_factory=connection_factory, async=async)
OperationalError: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
3 jobs in row [2], [3], [4] currently failed due to this, so I suspect it
is regression somewhere.
It started around engine patch [5]:
Change 69927 - Merged
packaging: ovirt-engine-hosts-ansible-inventory: Init groups So that they
always exist, even if empty. Change-Id:
If0169b60012ab444c19385363168832f6cd151ab
Bug-Url: https://bugzilla.redhat.com/1405813
however I am not sure of that is the cause or not. Will reply to this
message if I get any updates.
Thanks,
[1]
http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/4789/art...
[2] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/4789/
[3] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/4790/
[4] http://jenkins.ovirt.org/job/test-repo_ovirt_experimental_master/4791/
[5] https://gerrit.ovirt.org/#/c/69927/
--
Anton Marchukov
Senior Software Engineer - RHEV CI - Red Hat
7 years, 10 months
Fwd: nfs-utils-2.1.1 Changes Everything!
by Sandro Bonazzola
FYI from fedora development mailing list.
---------- Messaggio inoltrato ----------
Da: "Steve Dickson" <SteveD(a)redhat.com>
Data: 16/Gen/2017 21:12
Oggetto: nfs-utils-2.1.1 Changes Everything!
A: "Development discussions related to Fedora" <
devel(a)lists.fedoraproject.org>
Cc:
Hello,
The latest nfs-utils release drastically changes how the NFS
servers are configured, for the good IMHO...
All daemon configuration now goes through /etc/nfs.conf.
See nfs.conf(5) for details.
The command line interfaces in the systemd services files
have been removed. Which means all your current configures
will break, because the variables in /etc/sysconfig/nfs are
no longer used.
Again, I think is a move in the right direction and I know
you might find this surprising 8-) but I really don't want to
break all the current server configuration. So I'm trying t
o figure out how to do this with least amount of impact.
Here is what I see as the options
1) Upgrade rawhide w/out a backward compatible patch
(since it is so early in the release cycle)
Upgrade f25 with an backwards compatible patch
2) Upgrade rawhide and f25 with the backward compatible
patch... but we have to ween ourselves of the command
line interface at some point...
3) Do nothing and push everything into f27, which is the least
favorite option.
I'm leaning toward option 1... but I'm asking... so I'm listening. :-)
Also, how do I documented something like this?
tia,
steved.
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
7 years, 10 months
[ATTENTION NEEDED] Jenkins restart
by Gil Shinar
Hi all,
Jenkins will be restarted today at 18:00 o'clock.
Please try not to send patches at least half an hour before.
In case you did, please retrigger them after restart completes.
Thanks
Gil
7 years, 10 months
[oVirt 4.1 Localization Question #3] "Cannot ${action} ${type}. Duplicate ${entity}."
by Yuko Katabami
Hello oVirt developers.
Could anyone help with the following question?
*File:* AppErrors
*Resource ID:* ACTION_TYPE_FAILED_DUPLICATE_ENTITY_IN_AFFINITY_GROUP
*String:* Cannot ${action} ${type}. Duplicate ${entity}.
*Question: *Is "Duplicate" used as verb or adjective?
Is it asking user to duplicate the entity, or reporting that the entity is
duplicated, and unable to perform the action?
Thank you,
Yuko
7 years, 10 months
Postponing oVirt 4.1 RC build to Wednesday Jan 18th
by Sandro Bonazzola
Hi,
we still have 3 approved blockers for 4.1[1] so release status is No go.
The ETA for the fix is Wednesday morning, so we're postponing the build to
Wednesday Jan 18th 11:00 TLV time / 10:00 CET
Thanks
--
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
7 years, 10 months
Reminder: we have Wildfly's web mgmt console (with auth)
by Roy Golan
For quite some time now we can access Wildfly's web console on
https://127.0.0.1:8706
It's the UI equivalent of jboss.cli but much more convenient. Example of
tasks you can perform there:
- Change logging settings, live
- Tweak the managed thread pool (will send a different thread about it)
- Shutdown/reload the service
- Tweak db connection details
- Get info/stats on the running setup EE components and more
One of the main advantages over the old jmx method is that it uses a plugin
to authenticate the engine user so your credentials should be admin@internal
or any superuser for that matter.
The default is to expose it to localhost and that could be change in
services/ovirt-engine/ovirt-engine.xml.in.For firewalled setups, you can
ssh tunnel your machine to overcome that as always.
R
7 years, 10 months
Issues Running Engine Setup Related to Database Autovacuum Settings
by Phillip Bailey
Hi team,
I'm having trouble running engine-setup on a fresh database. When I first
ran setup I received a message prompting me to update the
autovacuum_vacuum_scale_factor, which I did. I then received another
prompting me to update the autovacuum_analyze_scale_factor, which I also
did. The next prompted me to update the autovacuum_max_workers to a value
of at least 6. I have tried changing the value to both 6 and 7 multiple
times, but it doesn't acknowledge that the change has been made and won't
let me proceed with setup.
Could someone tell me if I'm doing something wrong or if this is an issue
with the new feature?
Thanks!
-Phillip Bailey
7 years, 10 months
