| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-29 | |||
| 17:23:44 | cfriesen | dansmith: agreed. though the practical difference between the two is minimal | |
| 17:24:28 | jaypipes | jmlowe: sorry, had a phone call... ok, sorry, hope you are ready for a stream of opinions coming from me... here goes... | |
| 17:24:49 | dansmith | cfriesen: well, if you're using pause for fast HA, the startup time may differ significantly, but also suspend should survive host reboots, power outages, etc | |
| 17:24:53 | dansmith | cfriesen: but yes, similar | |
| 17:25:09 | jaypipes | jmlowe: a) application state should *never* be saved in a VM disk image. it should always be saved only to a persistent volume that can be attached/detached as needed. | |
| 17:25:58 | jmlowe | great in theory, now fix 40 years of domain specific scientific code | |
| 17:26:13 | jaypipes | jmlowe: b) if you need persistent IP addresses, then those IP addresses should be managed outside of the scope of Nova (i.e. created in Neutron and attached to a Nova VM on boot). Then detached from the VM when no longer needed. | |
| 17:26:25 | jaypipes | jmlowe: like I said, my opinion... :) | |
| 17:27:44 | jmlowe | case in point, most domestic weather forecasting is done with WRF, there is exactly one guy in the world who still knows how it works, he was brought out of retirement at UCAR, there is a new model in the works but I don't think it's ready for primetime yet | |
| 17:27:52 | jaypipes | jmlowe: c) you will end up spending more money and time working around coupled app state and configuration instead of investing the time in decoupling the app configuration and state and treating all your VMs as cattle instead of pets. | |
| 17:29:43 | jaypipes | jmlowe: ok, I'm done with my opinion stream. :) I recognize there are real and unworkaroundble constraints that you and others suffer with. I'm just pointing out my experience and long-term strategy, nothing more. | |
| 17:29:55 | openstackgerrit | Merged openstack/nova stable/pike: Stringify instance UUID https://review.openstack.org/569421 | |
| 17:30:06 | jmlowe | I have thousands of pets, they technically aren't even mine, I'd guess of my ~2400 users 100 have the chops to rework their applications | |
| 17:30:27 | jaypipes | jmlowe: understood. | |
| 17:30:59 | jmlowe | I tackle them one at a time, in a few centuries I will have made major progress | |
| 17:31:07 | jaypipes | heh :) touche. | |
| 17:32:00 | jaypipes | yumapath: you will need to be more specific that "but not able to get things working"./ | |
| 17:32:08 | jaypipes | s/that/than | |
| 17:37:31 | openstackgerrit | Merged openstack/nova stable/queens: Fix shelving a paused instance https://review.openstack.org/569650 | |
| 17:39:13 | mriedem | cfriesen: are you aware of anything in the pci whitelist that must be case sensitive? https://review.openstack.org/#/c/565808/4/nova/pci/utils.py | |
| 17:47:35 | cfriesen | mriedem: not my area of expertise | |
| 17:48:01 | cfriesen | mriedem: our pci guy seems to be away at the moment. | |
| 18:03:21 | mriedem | jmlowe: ok so it sounds like what i expected, the failed live migration was probably before we patched pike to cleanup allocations properly in that case | |
| 18:04:02 | mriedem | jmlowe: any ideas on the ones that don't have allocations at all? | |
| 18:05:04 | jmlowe | I haven't really found a pattern, other than they existed during 16.0 vs our current 16.1 | |
| 18:05:16 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (3) https://review.openstack.org/569320 | |
| 18:05:31 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (4) https://review.openstack.org/570750 | |
| 18:05:50 | openstackgerrit | Takashi NATSUME proposed openstack/nova master: Remove mox in libvirt/test_driver.py (5) https://review.openstack.org/570842 | |
| 18:08:53 | mriedem | jmlowe: did you look at the instance action records for the ones that don't have allocations? | |
| 18:09:25 | jmlowe | http://paste.openstack.org/show/722279/ | |
| 18:10:03 | mriedem | did req-e0d0edd7-74ee-40d0-b538-9f15f0242183 fail? | |
| 18:10:22 | jmlowe | NAFAICT | |
| 18:10:51 | jmlowe | failed ones tended to get double allocations | |
| 18:11:16 | jmlowe | or allocated on the wrong (probably target) host | |
| 18:11:53 | mriedem | can you do a "nova instance-action <server> req-e0d0edd7-74ee-40d0-b538-9f15f0242183" on that same instance from the paste? | |
| 18:12:56 | jmlowe | http://paste.openstack.org/show/722283/ | |
| 18:13:55 | mriedem | do you have any ocata compute services running? | |
| 18:14:02 | jmlowe | no | |
| 18:14:38 | jmlowe | I get the warnings about only have pike won't update allocation in the nova compute logs | |
| 18:14:54 | mriedem | ok yeah that's what i was thinking of | |
| 18:17:04 | efried | jaypipes: Finally finished https://review.openstack.org/#/c/553597/ -- thanks for your patience | |
| 18:19:01 | mriedem | wonder if we have a bug here https://github.com/openstack/nova/blob/stable/pike/nova/compute/manager.py#L5823 | |
| 18:19:47 | mriedem | that should only remove the instance's allocations against the source node after a successful live migration, | |
| 18:19:53 | mriedem | the dest host allocations are created during scheduling | |
| 18:59:37 | jmlowe | mriedem: not exactly the same thing, but along those lines http://paste.openstack.org/show/722290/ | |
| 19:00:35 | jmlowe | something doesn't add up | |
| 19:04:03 | mriedem | is instance 6c4e5035-8a42-4e37-8e90-3ba142ecd5aa running on r06c2b03? | |
| 19:06:05 | openstackgerrit | Merged openstack/nova master: Remove unused function https://review.openstack.org/570865 | |
| 19:07:17 | mriedem | jmlowe: what does "openstack resource provider inventory list b0f5d569-687f-43a2-9bdb-309a29597125" show? | |
| 19:08:29 | mriedem | looking at that allocation output, you have 3 instances running on that host with a total of 126976 memory mb consumed | |
| 19:08:52 | jmlowe | http://paste.openstack.org/show/722293/ | |
| 19:09:46 | mriedem | ok and that says there is 130850 mb total of memory | |
| 19:11:19 | mriedem | jaypipes: efried: should max_unit ever be > total - reserved? | |
| 19:11:41 | dansmith | mriedem: I would think it could be | |
| 19:11:42 | efried | mriedem: I think it should be allowed. | |
| 19:11:59 | dansmith | mriedem: consider the case of ironic | |
| 19:12:03 | dansmith | well, that'd be equal I guess | |
| 19:12:07 | efried | Because you should be able to change total and/or reserved without having to worry about also "fixing" max_unit at the same time. | |
| 19:12:12 | dansmith | yeah | |
| 19:12:18 | mriedem | fine fine | |
| 19:12:35 | dansmith | well, yeah, ironic would be total=1, reserved=1, max_unit=1, total-reserved=0 | |
| 19:12:48 | dansmith | for the cleaning state | |
| 19:14:22 | jmlowe | there are 3 instances running on that host, 158726ec-f09d-443c-a700-cce79cd065e0, 5053ebcc-9145-4297-b60f-f2c74ce95aef, 950be30e-a275-4533-9d42-53df6145545b | |
| 19:14:32 | mriedem | jmlowe: how many servers show up on that host if you do "nova hypervisor-servers r06c2b03"? | |
| 19:14:33 | mriedem | same 3? | |
| 19:14:50 | jmlowe | yep, check nova and virsh | |
| 19:15:13 | jaypipes | efried: np | |
| 19:15:13 | mriedem | ok, i'm not sure why free_ram_mb shows up as -122863 | |
| 19:16:18 | jmlowe | this host did once have a allocation for an instance that wasn't present | |
| 19:16:30 | mriedem | based on my calculations you should have 17mb of free ram on that host | |
| 19:16:50 | mriedem | 130850 total - 3857 reserved - 126976 (sum memory mb of allocations of the 3 instances on that host) | |
| 19:17:24 | jmlowe | Is there some cache somewhere that needs updated? | |
| 19:18:26 | mriedem | don't think so, i'm probably missing something in the free ram calculation in the resource tracker, like what the virt driver computes for overhead | |
| 19:19:03 | mriedem | although the libvirt driver doesn't do anything wrt memory_mb overhead | |
| 19:19:21 | esberglu | melwitt: Not sure if you saw my message last week with the summit | |
| 19:19:32 | esberglu | PowerVM vSCSI CI is enabled | |
| 19:19:46 | esberglu | So you should be able to remove the procedural -2 from https://review.openstack.org/#/c/526094/ | |
| 19:21:59 | mriedem | jmlowe: i see this comment but i'm not sure what it means about policy https://github.com/openstack/nova/blob/stable/pike/nova/compute/resource_tracker.py#L913 | |
| 19:22:16 | mriedem | i assume oversubscription? | |
| 19:22:22 | cfriesen | mriedem: jmlowe: is anything else on that compute node consuming ram outside of openstack/qemu/etc? | |
| 19:22:55 | jmlowe | free shows 82G free | |
| 19:28:36 | cfriesen | jmlowe: I think that's largely irrelevent for 4KB pages since they're only allocated on demand. | |
| 19:29:07 | dansmith | cfriesen: other stuff on the box consuming memory shouldn't be represented in placement in any way | |
| 19:29:13 | dansmith | other than reserved if configured in nova | |
| 19:32:05 | melwitt | esberglu: yep, just need to take a look through and will remove the -2 | |
| 19:32:24 | esberglu | Sounds good thanks | |
| 19:33:00 | cfriesen | libvirt.host.Host.get_memory_mb_used() looks at actual memory usage on the host | |
| 19:33:06 | cfriesen | dansmith: ^ | |
| 19:34:03 | dansmith | cfriesen: right but that shouldn't be what we're reporting as reserved | |
| 19:34:15 | mriedem | what we report as reserved comes from config | |
| 19:34:26 | dansmith | right ^ | |
| 19:34:32 | mriedem | what we report as total comes from nova.virt.libvirt.host.Host.get_memory_mb_total | |
| 19:35:00 | mriedem | what we report as used is based on the instances running on the host via the nova db, not what the driver tells us | |
| 21:00:45 | openstackgerrit | Jay Pipes proposed openstack/nova-specs master: Standardize CPU resource tracking https://review.openstack.org/555081 | |
| 21:03:38 | mriedem | melwitt: not sure if you've thought about it, but we have two things in runway slots that either expire today or tomorrow; was wondering if you wanted to do a 'grace period' extension for those given the summit last week | |
| 21:05:40 | melwitt | mriedem: yeah, I was thinking about something like that. I think it makes sense given the summit week | |
| 21:07:29 | melwitt | maybe just extend all 3 by a week from today? they all have similar original end dates | |
| 21:16:23 | mriedem | sure | |
| 21:25:10 | efried | ++ | |
| 21:27:37 | melwitt | cool, will update | |