<div dir="ltr">For what it's worth, we had a discussion about this in November last year:<div><br></div><div><a href="http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000209.html">http://lists.openstack.org/pipermail/openstack-discuss/2018-November/000209.html</a><br></div><div><br></div><div>I made a comment at the end of that thread about a 'workaround' we have used. It still happens here on Queens and the workaround doesn't solve it permanently.</div><div><br></div><div>--</div><div>MC</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 16, 2019 at 3:22 AM Matt Riedemann <<a href="mailto:mriedemos@gmail.com">mriedemos@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 4/15/2019 10:36 AM, Nicolas Ghirlanda wrote:<br>
> New VMs  are just currently always scheduled to the same compute node, <br>
> even though a manual live-migration is working fine to other compute nodes.<br>
<br>
How are you doing the live migration? If you're using the openstack <br>
command line and defaulting to the 2.1 compute API microversion, you're <br>
forcing the server to another host by bypassing the scheduler which is <br>
maybe why live migration is "working" but server create is not ever <br>
using the other computes.<br>
<br>
> <br>
> <br>
> We're not sure, what the issue is, but perhaps someone may spot it from <br>
> our config:<br>
> <br>
> <br>
> # nova.conf  scheduler config<br>
> <br>
> default_availability_zone = az1<br>
<br>
How many computes are in az1? All 8?<br>
<br>
> <br>
> ...<br>
> <br>
> [filter_scheduler]<br>
> available_filters = nova.scheduler.filters.all_filters<br>
> enabled_filters = RetryFilter, AvailabilityZoneFilter, <br>
> ComputeCapabilitiesFilter, ImagePropertiesFilter, <br>
> ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, <br>
> AggregateInstanceExtraSpecsFilter, AggregateMultiTenancyIsolation, <br>
> DifferentHostFilter, RamFilter, SameHostFilter, NUMATopologyFilter<br>
> <br>
<br>
Not really related to this probably but you can remove RamFilter since <br>
placement does the MEMORY_MB filtering and the RamFilter was deprecated <br>
in Stein as a result.<br>
<br>
It looks like you're getting the default host_subset_size value:<br>
<br>
<a href="https://docs.openstack.org/nova/queens/configuration/config.html#filter_scheduler.host_subset_size" rel="noreferrer" target="_blank">https://docs.openstack.org/nova/queens/configuration/config.html#filter_scheduler.host_subset_size</a><br>
<br>
Which means your scheduler is "packing" by default. If you have multiple <br>
computes and you want to spread instances across them, you can adjust <br>
the host_subset_size value.<br>
<br>
> <br>
> <br>
> Database is an external Percona XtraDB Cluster (Version 5.7.24) with <br>
> haproxy for read-write-splitting (currently only one write node).<br>
> <br>
> We do see mysql errors in the nova-scheduler.log on the write DB node <br>
> when an instance is created.<br>
> <br>
> <br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db [-] <br>
> Unexpected error while reporting service status: OperationalError: <br>
> (pymysql.err.OperationalError) (1213, u'WSREP detected deadlock/conflict <br>
> and aborted the transaction. Try restarting the transaction') <br>
> (Background on this error at: <a href="http://sqlalche.me/e/e3q8" rel="noreferrer" target="_blank">http://sqlalche.me/e/e3q8</a>)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db Traceback <br>
> (most recent call last):<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/servicegroup/drivers/db.py", <br>
> line 91, in _report_state<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> service.service_ref.save()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_versionedobjects/base.py", <br>
> line 226, in wrapper<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return <br>
> fn(self, *args, **kwargs)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/objects/service.py", <br>
> line 397, in save<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db db_service <br>
> = db.service_update(self._context, <a href="http://self.id" rel="noreferrer" target="_blank">self.id</a>, updates)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/api.py", <br>
> line 183, in service_update<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return <br>
> IMPL.service_update(context, service_id, values)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py", <br>
> line 154, in wrapper<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> ectxt.value = e.inner_exc<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", <br>
> line 220, in __exit__<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self.force_reraise()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", <br>
> line 196, in force_reraise<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> six.reraise(self.type_, self.value, self.tb)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/api.py", <br>
> line 142, in wrapper<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return <br>
> f(*args, **kwargs)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/db/sqlalchemy/api.py", <br>
> line 227, in wrapped<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db return <br>
> f(context, *args, **kwargs)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/usr/lib/python2.7/contextlib.py", line 24, in __exit__<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self.gen.next()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", <br>
> line 1043, in _transaction_scope<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db yield <br>
> resource<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/usr/lib/python2.7/contextlib.py", line 24, in __exit__<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self.gen.next()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", <br>
> line 653, in _session<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self.session.rollback()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", <br>
> line 220, in __exit__<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self.force_reraise()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_utils/excutils.py", <br>
> line 196, in force_reraise<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> six.reraise(self.type_, self.value, self.tb)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", <br>
> line 650, in _session<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self._end_session_transaction(self.session)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/oslo_db/sqlalchemy/enginefacade.py", <br>
> line 678, in _end_session_transaction<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> session.commit()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", <br>
> line 943, in commit<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self.transaction.commit()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/orm/session.py", <br>
> line 471, in commit<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db t[1].commit()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", <br>
> line 1643, in commit<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self._do_commit()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", <br>
> line 1674, in _do_commit<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self.connection._commit_impl()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", <br>
> line 726, in _commit_impl<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self._handle_dbapi_exception(e, None, None, None, None)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", <br>
> line 1409, in _handle_dbapi_exception<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> util.raise_from_cause(newraise, exc_info)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/util/compat.py", <br>
> line 265, in raise_from_cause<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> reraise(type(exception), exception, tb=exc_tb, cause=cause)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/engine/base.py", <br>
> line 724, in _commit_impl<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self.engine.dialect.do_commit(self.connection)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/sqlalchemy/dialects/mysql/base.py", <br>
> line 1765, in do_commit<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> dbapi_connection.commit()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", <br>
> line 422, in commit<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> self._read_ok_packet()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", <br>
> line 396, in _read_ok_packet<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db pkt = <br>
> self._read_packet()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/connections.py", <br>
> line 683, in _read_packet<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> packet.check_error()<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/protocol.py", <br>
> line 220, in check_error<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> err.raise_mysql_exception(self._data)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db File <br>
> "/var/lib/kolla/venv/local/lib/python2.7/site-packages/pymysql/err.py", <br>
> line 109, in raise_mysql_exception<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db raise <br>
> errorclass(errno, errval)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db <br>
> OperationalError: (pymysql.err.OperationalError) (1213, u'WSREP detected <br>
> deadlock/conflict and aborted the transaction. Try restarting the <br>
> transaction') (Background on this error at: <a href="http://sqlalche.me/e/e3q8" rel="noreferrer" target="_blank">http://sqlalche.me/e/e3q8</a>)<br>
> 2019-04-15 16:52:10.016 24 ERROR nova.servicegroup.drivers.db<br>
> 2019-04-15 16:52:20.020 24 INFO nova.servicegroup.drivers.db [-] <br>
> Recovered from being unable to report status.<br>
<br>
This is a service update operation which could indicate that the other <br>
computes are reported as 'down' and that's why nothing is getting <br>
scheduled to them. Have you checked the "openstack compute service list" <br>
output to make sure those computes are all reporting as "up"?<br>
<br>
<a href="https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/compute-service.html#compute-service-list" rel="noreferrer" target="_blank">https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/compute-service.html#compute-service-list</a><br>
<br>
There is a retry_on_deadlock decorator on that service_update DB API <br>
though so I'm kind of surprised to still see the deadlock errors, unless <br>
those just get logged while retrying?<br>
<br>
<a href="https://github.com/openstack/nova/blob/stable/queens/nova/db/sqlalchemy/api.py#L566" rel="noreferrer" target="_blank">https://github.com/openstack/nova/blob/stable/queens/nova/db/sqlalchemy/api.py#L566</a><br>
<br>
> <br>
> <br>
> The deadlock message is quite strange, as we have haproxy configured so <br>
> all write requests are handled by one node.<br>
> <br>
> <br>
> There are NO errors in the mysqld.log WHILE creating an instance, but we <br>
> see from time to time aborted connections from nova.<br>
> <br>
> 2019-04-15T14:22:36.232108Z 30616972 [Note] Aborted connection 30616972 <br>
> to db: 'nova' user: 'nova' host: '10.x.y.z' (Got an error reading <br>
> communication packets)<br>
> <br>
> <br>
> <br>
> As I said, all instances are allocated to the same compute node. <br>
> nova-compute.log doesn't show an error while creating the instance.<br>
> <br>
> <br>
> Beside that, we also see messages from nova.scheduler.host_manager on <br>
> all other nodes like (but those messages are _not_ triggered, when an <br>
> instance is spawned.!)<br>
> <br>
> <br>
> 2019-04-15 16:28:47.771 22 INFO nova.scheduler.host_manager <br>
> [req-f92e340e-a88a-44a0-8cad-588390c25bc2 - - - - -] The instance sync <br>
> for host 'xxx' did not match. Re-created its InstanceList.<br>
<br>
Are there any instances on these other hosts? My guess is you're seeing <br>
that after the live migration to another host.<br>
<br>
> <br>
> <br>
> <br>
> Don't know if that may be relevant, but somehow our (currently single) <br>
> AZ is listed several times.<br>
> <br>
> <br>
> # openstack availability zone list<br>
> +------------+-------------+<br>
> | Zone Name  | Zone Status |<br>
> +------------+-------------+<br>
> | internal   | available   |<br>
> | az1 | available           |<br>
> | az1 | available           |<br>
> | az1 | available           |<br>
> | az1 | available           |<br>
> +------------+-------------+<br>
> <br>
> May that be related somehow?<br>
<br>
I believe those are the AZs for other services as well (cinder/neutron). <br>
Specify the --compute option to filter that.<br>
<br>
--<br>
<br>
Another thing to check is placement - are there 8 compute node resource <br>
providers reporting into placement? You can check using the CLI:<br>
<br>
<a href="https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-list" rel="noreferrer" target="_blank">https://docs.openstack.org/osc-placement/latest/cli/index.html#resource-provider-list</a><br>
<br>
In Queens, there should be one resource provider per working compute <br>
node in the cell database's compute_nodes table (the UUIDs should match <br>
as well).<br>
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt<br>
<br>
</blockquote></div>