| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-19 | |||
| 17:59:09 | jaypipes | mriedem: gah, never mind. | |
| 17:59:15 | jaypipes | mriedem: sigh... | |
| 17:59:26 | jaypipes | mriedem: was looking in nova/tests/functional/api_samples/ | |
| 17:59:44 | jaypipes | mriedem: have I mentioned I hate these? :) | |
| 18:04:35 | cfriesen | is all quota information now going into the API DB? or will we still put some in the main DB? | |
| 18:05:32 | openstackgerrit | Merged openstack/nova master: Fix 4 doc typos https://review.openstack.org/529084 | |
| 18:06:18 | jaypipes | melwitt: see cfriesen's ? above... | |
| 18:40:25 | openstackgerrit | Merged openstack/python-novaclient master: CommandError is raised for invalid server fields https://review.openstack.org/525110 | |
| 18:51:24 | mriedem | cfriesen: api db | |
| 18:51:54 | mriedem | cfriesen: starting in pike we don't use the usages or reservations tables anymore | |
| 19:01:48 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Support aggregate affinity scheduler filters https://review.openstack.org/529135 | |
| 19:31:02 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Support aggregate affinity scheduler filters https://review.openstack.org/529135 | |
| 20:11:11 | rybridges | So I am seeing errors every time i make a snapshot | |
| 20:11:43 | rybridges | regarldess of whether i use disable_libvirt_livesnapshot = true or disable_libvirt_livesnapshot = false | |
| 20:11:49 | rybridges | the error is the same every time | |
| 20:11:53 | rybridges | it happens on the hypervisor | |
| 20:12:04 | rybridges | this is nova-compute.log https://pastebin.com/WiqYtZzF | |
| 20:13:34 | rybridges | this is the error for libvirt log: https://pastebin.com/4NeSuNvX | |
| 20:14:17 | rybridges | its impossible to take a snapshot on ocata from the horizon ui | |
| 20:14:20 | rybridges | as far as we can tell | |
| 20:18:42 | mriedem | https://www.jrssite.com/wordpress/?p=302 | |
| 20:18:49 | mriedem | https://bugs.launchpad.net/nova/+bug/1381153 | |
| 20:18:50 | openstack | Launchpad bug 1381153 in OpenStack Compute (nova) "Cannot create instance live snapshots in Centos7 (icehouse)" [Undecided,Invalid] | |
| 20:28:19 | cfriesen | mriedem: thanks for the quota answer earlier...in objects.Quotas we're still looking at both the api DB and the main DB. is that left over from Pike? Presumably now we could remove the main DB access? | |
| 20:30:07 | mriedem | cfriesen: that's for the online data migration | |
| 20:30:17 | alee | hi - does anyone know how to force nova to re-fetch images from glance? | |
| 20:30:22 | mriedem | so we can't remove that until people have run through the online data migrations, | |
| 20:30:35 | mriedem | and we have a blocker schema migration in place to enforce that there are no quota limits/classes in the main cell db | |
| 20:30:35 | cfriesen | mriedem: that should have happened in Pike though, right? so we could remove it in Q? | |
| 20:30:49 | mriedem | cfriesen: you'd have to add a blocker migration | |
| 20:31:05 | cfriesen | mriedem: okay | |
| 21:04:45 | openstackgerrit | Ed Leafe proposed openstack/nova master: Make conductor pass and use host_lists https://review.openstack.org/511358 | |
| 21:04:46 | openstackgerrit | Ed Leafe proposed openstack/nova master: Change compute RPC to use alternates for resize https://review.openstack.org/526436 | |
| 21:04:52 | edleafe | mriedem: ^^ should address the functional test failures | |
| 21:06:11 | ludovic | Hi, I 'd like to ask few questions to nova experts: is it exists tips to prioritize evacuation order for instances | |
| 21:06:53 | openstackgerrit | Merged openstack/nova master: Some nit fix in multi_cell_list https://review.openstack.org/527597 | |
| 21:07:15 | openstackgerrit | Merged openstack/nova master: doc: add note about fixing admin-only APIs without a microversion https://review.openstack.org/527421 | |
| 21:07:33 | ludovic | or is it possible to reserve spare nodes ti ensure host-evacuation | |
| 21:08:15 | mriedem | ludovic: no and no, | |
| 21:08:24 | mriedem | you can specify a target host during evacuate, but that doesn't reserve it | |
| 21:08:35 | mriedem | and you evacuate one instance at a time, | |
| 21:08:42 | mriedem | so if there is priority, the caller handles that | |
| 21:10:56 | ludovic | ok, so we can't ensure a good SLA | |
| 21:11:37 | ludovic | of we can't reserve resources to securely evacuate all workload | |
| 21:11:54 | ludovic | the SLA is impacted | |
| 21:15:59 | ludovic | mriedem: does the scheduler propose as a trick to overcome this? | |
| 21:19:07 | mriedem | ludovic: how is this any different than the scheduler correctly picking a host during the initial server create? | |
| 21:19:28 | mriedem | besides reschedules | |
| 21:20:14 | ludovic | excuse-me , maybe can we have a private discussion about the Filter scheduler VS host-evacuate process with HA compute instances ? | |
| 21:20:28 | mriedem | why private? | |
| 21:21:01 | ludovic | in order to not disturb the room | |
| 21:21:11 | ludovic | np | |
| 21:21:48 | ludovic | I'm testing the HA compute instances with tripleo deployment | |
| 21:22:13 | ludovic | so the nova-evacuate pacemaker process is working well | |
| 21:22:35 | ludovic | but i was suprised by the Ram Filter scheduler | |
| 21:24:37 | ludovic | to explain the case , I have two compute Nodes. I have 2 Computes Nodes. The first compute Node with 31 instances ( total RAM allocated = 177152 M) , the second one with 2 instances ( Total RAM allocated = 24576 ) | |
| 21:24:55 | ludovic | RAM of computes Nodes is 196483 (memory_mb) | |
| 21:26:07 | ludovic | The Host-evacuate worked but 5 VMs was on ERROR with insufficient memory (nova-compute log) and on was with NO STATE (No Host found by RAM Filter) | |
| 21:26:24 | ludovic | one | |
| 21:26:37 | ludovic | I expected the same ERROR on these 6 instances | |
| 21:27:04 | ludovic | HOST NOT FOUND or ERROR with insufficient memory | |
| 21:27:44 | mriedem | so you're evacuating the 31 instances on the one compute node to the other compute node with 2 instances? | |
| 21:27:48 | ludovic | So i don't understand the result | |
| 21:28:02 | ludovic | yes | |
| 21:28:08 | mriedem | and 5 of 31 fail | |
| 21:28:13 | ludovic | 6 | |
| 21:28:14 | mriedem | which release? | |
| 21:28:40 | ludovic | 5 with insufficient memory and 1 with no valid host found | |
| 21:28:44 | mriedem | if you're in pike+ and using the FilterScheduler, you should remove the RamFilter | |
| 21:28:46 | ludovic | ocata | |
| 21:29:06 | mriedem | so the problem is, | |
| 21:29:22 | mriedem | the scheduler has a point in time snapshot of the resources from the compute, per request, | |
| 21:29:37 | ludovic | i use ocata for the moment | |
| 21:29:53 | mriedem | and the ram usage doesn't change until one of the evacuations makes it to the compute and claims those resources, and updates the compute node record in the db, which the scheduler will read in the next scheduling attempt | |
| 21:30:21 | mriedem | so the problem is if you're sending all 31 evacuate requests in a for loop, for example, with no time in between for the scheduler to catch up to the changes in the computes, | |
| 21:30:47 | mriedem | the scheduler thinks the compute is fine and sends the instance there, but the claim on the compute might fail because another request claimed those resources in the meantime | |
| 21:31:01 | ludovic | yes exactly | |
| 21:31:18 | mriedem | this should be fixed in pike, | |
| 21:31:35 | mriedem | because in pike, the RamFilter can be removed and the FilterScheduler uses the Placement service to claim the resources during scheduling | |
| 21:32:05 | mriedem | any claim collisions on the compute node in pike due to concurrent requests will be retried up to 3 times | |
| 21:32:35 | mriedem | otherwise what you're hitting is latent behavior | |
| 21:32:36 | ludovic | ah ok so with ocata the process is not enough efficient ? | |
| 21:32:59 | mriedem | correct; the late claim on the compute has always been a known issue with scheduling | |
| 21:33:10 | mriedem | with server create, if you hit this, we would reschedule to another compute | |
| 21:33:16 | mriedem | we don't do reschedules with evacuate though | |
| 21:33:45 | ludovic | But is it possible to influence the evacuate with max_concurrent_build ? | |
| 21:33:49 | ludovic | in nova.conf ? | |
| 21:34:27 | ludovic | by default this parameter is 10 , if we reduce to one ? | |
| 21:36:34 | mriedem | no max_concurrent_build is for server create, not evacuate | |
| 21:36:56 | ludovic | ah ok i understand . | |
| 21:36:58 | mriedem | there is no option like that for limiting evacuates | |
| 21:37:34 | mriedem | that's not to say one couldn't be added, but adding that in queens or pike doesn't make sense when we've solved this part of the problem in the scheduler | |
| 21:38:58 | mriedem | still, it seems reasonable to allow limiting the number of concurrent evacuates on a given compute, since we do that for spawn and live migrate | |
| 21:39:03 | mriedem | i wouldn't be opposed to adding something like that | |
| 21:40:54 | ludovic | ok thank you for your explanations, it's precious for me because I'm testing openstack for a big French Company you know | |
| 21:41:40 | ludovic | And the goal is to see if we can in the future replace the massive usage of WMare with OpenStack you know | |
| 21:41:59 | mriedem | oolala | |
| 21:42:00 | ludovic | near future | |
| 21:42:21 | mriedem | ok. would be cool if you could test this out on a pike deployment. | |
| 21:42:32 | mriedem | to make sure the filter scheduler + placement is correctly handling this for you | |