Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-03-31
14:47:25 kashyap [quote]
14:47:25 kashyap For AArch64, we now set the ``max`` as the default CPU model; it does the right thing in context of both QEMU TCG (plain emulation) and for KVM (hardware acceleration).
14:47:29 kashyap [/quote]
14:47:59 kashyap stephenfin: So I don't know where you got that 'host-passthrough' bit for AArch64; I'll comment on the change for the record
14:48:21 stephenfin I think that was based on comments from sean-k-mooney
14:48:47 kashyap That's incorrect, I'm afraid
14:51:45 kashyap stephenfin: Unlike x86, AArch64 does not even _have_ a default CPU model. We discussed it at length in this patch here: https://review.opendev.org/c/openstack/nova/+/709494
14:56:11 sean-k-mooney kashyap: not accoundign to the code
14:56:33 kashyap sean-k-mooney: Very well it is; according to the code
14:56:44 kashyap https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L4753
14:56:53 kashyap sean-k-mooney: And see this release note: https://review.opendev.org/c/openstack/nova/+/709494/21/releasenotes/notes/bug-1864588-737c29560effd16e.yaml
14:57:20 kashyap Which I recall distinctly asking to word it that way (because it's truth) :)
15:05:44 sean-k-mooney ill be starting the call soon by the way
15:05:50 sean-k-mooney just fisnihgn a differnt call
15:06:06 sean-k-mooney oh upstream yeah :)
16:56:38 openstackgerrit Lee Yarwood proposed openstack/nova master: Add regression test for bug #1922053 https://review.opendev.org/c/openstack/nova/+/784129
16:56:40 openstack bug 1922053 in OpenStack Compute (nova) "Operators can force up compute services with `done` evacuation migration records still active against the host" [Undecided,New] https://launchpad.net/bugs/1922053
16:56:40 openstackgerrit Lee Yarwood proposed openstack/nova master: WIP api: Reject requests to force up compute when `done` evacuation records exist https://review.opendev.org/c/openstack/nova/+/784130
17:50:50 openstackgerrit Merged openstack/nova master: doc: Use a non-numerical anchor when referencing microversions https://review.opendev.org/c/openstack/nova/+/782696
19:52:12 zigo I'm getting an error 500 when I try to launch my first Wallaby instance:
19:52:12 zigo [pid: 804881|app: 0|req: 34/573] 192.168.101.2 () {32 vars in 646 bytes} [Wed Mar 31 19:49:55 2021] GET /v2.1/flavors/cpu1-ram2-disk5 => generated 88 bytes in 411 msecs (HTTP/1.1 404) 7 headers in 339 bytes (3 switches on core 0)
19:52:12 zigo [pid: 804879|app: 0|req: 54/576] 192.168.101.2 () {32 vars in 614 bytes} [Wed Mar 31 19:49:56 2021] GET /v2.1/flavors => generated 907 bytes in 347 msecs (HTTP/1.1 200) 7 headers in 317 bytes (3 switches on core 0)
19:52:12 zigo [pid: 804880|app: 0|req: 38/577] 192.168.101.2 () {32 vars in 688 bytes} [Wed Mar 31 19:49:56 2021] GET /v2.1/flavors/93025366-9d69-489b-b4e7-f6aca509416f => generated 478 bytes in 345 msecs (HTTP/1.1 200) 7 headers in 317 bytes (3 switches on core 0)
19:52:12 zigo [pid: 804868|app: 0|req: 33/601] 192.168.101.2 () {36 vars in 668 bytes} [Wed Mar 31 19:49:57 2021] POST /v2.1/servers => generated 211 bytes in 3080 msecs (HTTP/1.1 500) 7 headers in 351 bytes (3 switches on core 0)
19:52:20 zigo Any idea what's going on?
19:52:34 zigo It's not as if it was so verbose ... :/
19:57:19 zigo Oh ...
19:57:19 zigo <class 'nova.exception.GlanceConnectionFailed'> (HTTP 500) (Request-ID: req-df3f3de6-e2ba-41a7-b717-67cee688d832)
19:57:54 zigo I know what's going on then. :)
20:31:52 sean-k-mooney :)
20:32:11 sean-k-mooney ya if glance is unhappy then nova will be too
21:04:23 openstackgerrit Rodrigo Barbieri proposed openstack/nova master: [WIP] Error anti-affinity violation on live migrations https://review.opendev.org/c/openstack/nova/+/784166
21:30:37 openstackgerrit Artom Lifshitz proposed openstack/nova master: WIP: Update SRIOV port pci_slot when unshelving https://review.opendev.org/c/openstack/nova/+/784168
21:31:04 artom sean-k-mooney, ^^ \o/
22:09:29 zigo sean-k-mooney: I belive I'm *very* close from booting my first VM with Wallaby. :)
23:10:47 sean-k-mooney artom: i need to digest this and think about it but i _think_ that works. i wpoudl prefer if you were not doing [0] but i get it
23:11:07 artom sean-k-mooney, yeah, there's some questionable code in there, I agree
23:11:19 artom I did mark it as WIP this time ;)
23:11:47 artom I want CI to do a full run to prove out the idea, then we can refine
23:11:49 sean-k-mooney you figured out how to get the requester_id
23:12:04 sean-k-mooney i looked at this a few times and missed that
23:12:10 artom Yeah, by setting it first :P
23:12:32 artom Which makes me think - VMs that got booted before that patch is applied will still have the original bug
23:12:46 artom Because they won't have requester_id on their PCIRequests
23:13:11 sean-k-mooney ture but you coudl do an online migratieon with a nova manage commnd
23:13:26 sean-k-mooney to correalte the exsitng allocation using the pci_slot
23:13:46 sean-k-mooney for currently shelved vms it wont help
23:13:55 sean-k-mooney but for any exisitng vm it would
23:13:56 artom It won't indeed
23:15:02 sean-k-mooney i wonder if gibi had any other logic reated to it being set
23:15:26 sean-k-mooney it was only set for port with resouce request before
23:15:40 sean-k-mooney i dont think it shoudl break anything but its one of teh things we shoudl check
23:16:56 sean-k-mooney anyway ya ill take a look at that again tomrrow
23:17:13 artom Yeah, no rush
23:17:22 artom I was just happy I managed to hax something together
23:18:00 sean-k-mooney yes its similar to what i tred to do before but i was trying to do it without moving settign the requester id
23:18:22 sean-k-mooney but i mean that works
23:19:05 sean-k-mooney i was basically workign the otherway and trying to put the request_id in the vif object in the network infor cache
23:19:10 sean-k-mooney but this is better
23:19:35 sean-k-mooney since it avoid the object change
23:21:43 artom Yeah, this should be backportable
23:26:54 artom And thanks for the requester_id pointer, btw :)
23:27:04 artom If it wasn't for that, I'd still be digging
#openstack-nova - 2021-04-01
00:08:57 ikla can I use ceph for my instance and local disk for ephemeral storage?
00:09:10 ikla appears to be either or
00:09:24 ikla rbd or local
00:10:30 ikla or can I pass a local partition in?
06:58:07 gibi_away sean-k-mooney, artom: about requester_id in InstancePciRequest, this is the past info I have about deciding not to put the flavorid into the requester_id https://review.opendev.org/c/openstack/nova/+/625310/25/nova/pci/request.py#220
07:27:24 gibi bauzas: hi! I've propose and RC2 patch and but a -W on it until next week https://review.opendev.org/c/openstack/releases/+/784201
08:28:24 gibi lyarwood: I put a heavy -1 to https://review.opendev.org/c/openstack/nova/+/784130
08:28:45 sean-k-mooney gibi: we could encode if its the flavorid/port id in the string
08:28:57 sean-k-mooney i do not belive its defined as a uuid
08:29:18 sean-k-mooney so we could do flavor/<uuid> and port/<uuid> if we needed too
08:29:45 sean-k-mooney normally i would say just add a requester_type
08:29:53 sean-k-mooney but that would be a db change
08:29:54 gibi sean-k-mooney: it wasn't filled not becasue we don't know what to put there, we did not put flavor there as nobody uses that information
08:30:19 sean-k-mooney ah yes
08:30:27 sean-k-mooney that makes sense i guess
08:30:32 gibi sean-k-mooney: and there later some source information is also added to the ovo in I292a0e2d840bbf657ba6d0932f9a3decbcb2778f
08:30:37 gibi https://review.opendev.org/c/openstack/nova/+/659101/4/nova/objects/instance_pci_requests.py
08:31:04 sean-k-mooney yes i remember that
08:31:19 gibi I have no issue if somebody starts adding flavorid tehre
08:31:20 gibi there
08:31:41 sean-k-mooney ya i think we can use store the uuid directly
08:31:49 gibi yepp
08:31:54 sean-k-mooney and use that source property to figure it out if we need too
08:32:09 gibi and we can add a fallback to the ovo that if the requester_id is None then it looks up the flavor stored in the instance
08:33:28 sean-k-mooney have you seen artoms change by the way https://review.opendev.org/c/openstack/nova/+/784168
08:33:54 sean-k-mooney i still need to properly review it but at first glance this seams like a workable solution going forward
08:34:20 sean-k-mooney im still debating if we want to add somethign to populate the requeter id for exsiting recoreds
08:34:57 sean-k-mooney possibly as a nova manage command or something on init_host as a seperate patch
08:36:35 sean-k-mooney what i was thinkng was loop over all the claimed devices without requester_id set, then lookup the port info form the network info cache and try and use the pci slot to corralte the pci devices to the ports
08:39:16 gibi sean-k-mooney: haven't looked that review yet
08:42:35 sean-k-mooney its still WIP so not quite ready for review yet but the core chagne is there and the previous patch add a functional repoducer which passes after the change
08:45:20 lyarwood gibi: replied, not sure I agree tbh, seems like a trivial requirement to codify to avoid operators borking things
08:45:43 lyarwood gibi: we had an example downstream of evacuations from 2019 being cleaned up recently in 2021 that spawned this btw
08:46:01 lyarwood gibi: somehow in the iterim the instance(s) had been migrated back to the original host
08:46:19 lyarwood gibi: I assume with manual operator intervention to cleanup instance dirs etc
08:46:36 lyarwood gibi: thankfully no data was lost but I'm just trying to avoid a future situation where we don't get as lucky
08:47:02 lyarwood gibi: and again it's specifically for the force down, evacuate and force up usecase. Outside of that I agree that a periodic or something would be useful

Earlier   Later