| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-11-01 | |||
| 16:49:05 | opendevreview | Merged openstack/nova master: Temp disable nova-manage placement heal_allocation testing https://review.opendev.org/c/openstack/nova/+/816156 | |
| 18:20:13 | stephenfin | EugenMayer: Instance names get sanitized (removed unicode, hyphens and periods and truncate to < 64 characters). The sanitized variants are used as the hostname | |
| 18:20:23 | stephenfin | EugenMayer: You can't specify a FQDN though | |
| 18:20:50 | stephenfin | To get that configured, you need to set dns_domain on the network. I think you need to use Designate for that | |
| 19:52:54 | opendevreview | Dan Smith proposed openstack/nova master: WIP: Revert project-specific APIs for servers https://review.opendev.org/c/openstack/nova/+/816206 | |
| 21:30:29 | EugenMayer | stephenfin thank you. Xena has hostnames per instance, but well i;am looking forward to it | |
| 22:58:05 | opendevreview | Merged openstack/nova master: [nova-manage]support extended resource request https://review.opendev.org/c/openstack/nova/+/802060 | |
| 23:11:18 | dinobot | greetings pals, could you please review a little patch fixing a fresh bug in Victoria & Wallaby? | |
| 23:11:29 | dinobot | https://review.opendev.org/c/openstack/nova/+/815923 | |
| 23:11:38 | dinobot | the bug affected me and is quite annoying, so I would love to see it fixed :) | |
| 23:15:11 | artom | dinobot, https://review.opendev.org/c/openstack/nova/+/810849 is doing the same thing in a better awy IMO | |
| 23:15:52 | artom | Maybe try to catch Pierre (the patch author) and see if you can take over his patch to address the feedback on it | |
| 23:16:08 | artom | As he seems to not have looked at it since the -1s | |
| #openstack-nova - 2021-11-02 | |||
| 05:56:11 | frickler | priteau: ^^ | |
| 07:05:56 | opendevreview | Balazs Gibizer proposed openstack/nova master: Revert "Temp disable nova-manage placement heal_allocation testing" https://review.opendev.org/c/openstack/nova/+/816242 | |
| 08:20:01 | bauzas | good morning Nova | |
| 08:21:35 | bauzas | gibi: sent https://review.opendev.org/c/openstack/nova/+/815940 to the gate | |
| 08:51:47 | gibi | bauzas: good morning and thank | |
| 08:51:47 | gibi | 's | |
| 08:52:06 | bauzas | np | |
| 08:52:19 | bauzas | how things went those 2 days ? | |
| 08:52:40 | gibi | nothing signifficant for me but I was mostly off yesterday | |
| 09:08:13 | frickler | kashyap: in case you didn't see it yet: https://gitlab.com/libvirt/libvirt/-/issues/229 | |
| 09:08:22 | kashyap | frickler: Morning | |
| 09:08:57 | kashyap | frickler: Just back after 2 days away from email. I indeed didn't see it. Thanks for filing it! | |
| 09:09:18 | frickler | kashyap: I also tested with a custom built qemu in https://review.opendev.org/c/openstack/devstack/+/815958 , which essentially has tb-size=64M | |
| 09:09:28 | frickler | the failures seem to be unrelated | |
| 09:14:09 | kashyap | frickler: Oh, cool, so you fetched the file and tested it. (I see no failures there; Zuul gave a +1) | |
| 09:14:24 | kashyap | frickler: Did setting it to 64M bring it back to the "previous capacity"? | |
| 09:14:42 | kashyap | (I'm putting it in quotes because, I don't know how many instances you were able to launch before this QEMU change) | |
| 09:20:49 | frickler | kashyap: the failures were in some of the rechecks. the old failures weren't 100% deterministic, it depends on how tempest with -c4 has parallel jobs that all start multiple instances | |
| 09:21:44 | kashyap | frickler: Rigt. Shall we let it run on multiple clouds / setups for a week or so? To rule out it's not the tb-size? | |
| 09:21:48 | kashyap | s/Rigt/Right/ | |
| 09:21:54 | frickler | I based the 64M on looking at a single instance locally with a 128M flavor, qemu then uses a bit more memory than with 4.2, but not too much hopefully, like ~200M instead of 150M | |
| 09:22:40 | frickler | kashyap: I intend to do a couple more rechecks, but there seems to be some issue on the neutron side which makes things unstable | |
| 09:23:22 | frickler | I'm pretty confident by now though that tb-size is the trigger | |
| 09:37:46 | stephenfin | I need to test the 'GET /servers/{server_id}/migrations/{id}' API, meaning I need a way to slow down live migrations so I catch one in the act. Anyone have a suggestion for an easy throttle I can set to do that? | |
| 09:38:09 | stephenfin | (rather than relying on big or busy guests) | |
| 09:39:12 | gibi | stephenfin: limiting bandwidth ? | |
| 09:39:37 | stephenfin | I assume there isn't a nova or libvirt config option I can use for that though? | |
| 09:39:58 | stephenfin | This is a simple DevStack two-node deployment, so I don't have a separate management network :) | |
| 09:39:58 | gibi | there is something in libvirt | |
| 09:40:05 | gibi | as there is virsh migrate-setspeed command in virsh | |
| 09:40:13 | stephenfin | oh, I looked and didn't see anything obvious | |
| 09:41:24 | kashyap | frickler: Do mention the Neutron issue in the change, if / when you get a minute | |
| 09:41:38 | kashyap | frickler: And probably Cc some folks from Neutron who might be able to debug | |
| 09:41:51 | stephenfin | gibi: that's exactly what I wanted. Thanks! | |
| 09:42:04 | kashyap | stephenfin: Yes, migrate-setspeed lets you throttle indeed | |
| 09:42:15 | gibi | stephenfin: cool | |
| 09:51:07 | bauzas | mmmm | |
| 09:51:22 | bauzas | just saw a new "Your Turn" series in Gerrit default dashboard | |
| 09:51:40 | bauzas | what's the "attention:self" query ? | |
| 09:52:00 | bauzas | hah, nevermind, found https://gerrit-review.googlesource.com/Documentation/user-attention-set.html | |
| 09:52:56 | bauzas | interesting | |
| 09:59:25 | gibi | I'm still learning the rules described in ^^ | |
| 10:15:32 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reno for qos-minimum-guaranteed-packet-rate https://review.opendev.org/c/openstack/nova/+/805046 | |
| 10:17:00 | gibi | bauzas: fyi, this is the final patch (the reno) https://review.opendev.org/c/openstack/nova/+/805046 for the https://blueprints.launchpad.net/openstack/?searchtext=qos-minimum-guaranteed-packet-rate blueprint. So we can close that bp soon \o/ | |
| 10:17:38 | bauzas | gibi: wow, this was fast. | |
| 10:18:03 | gibi | bauzas: we only missed the nova-manage part of that bp in xena | |
| 10:18:13 | bauzas | yup, I know | |
| 10:18:17 | bauzas | but still :) | |
| 10:18:30 | gibi | yeah, it is always nice to close out a bp even before M1 | |
| 10:18:34 | bauzas | we discussed this at the PTG, I wasn't expecting the nova-manage patch to land that soon :) | |
| 10:19:02 | gibi | it is thanks to stephenfin and melwitt | |
| 10:24:04 | opendevreview | Balazs Gibizer proposed openstack/nova master: Reno for qos-minimum-guaranteed-packet-rate https://review.opendev.org/c/openstack/nova/+/805046 | |
| 10:26:29 | gibi | bauzas: btw, there is a bug fix for the series (for those part we landed in xena) https://review.opendev.org/c/openstack/nova/+/811396 | |
| 10:28:37 | bauzas | +w | |
| 10:32:03 | opendevreview | Federico Ressi proposed openstack/nova master: Debug Nova APIs call failures https://review.opendev.org/c/openstack/nova/+/806683 | |
| 10:38:03 | lyarwood | frickler: just catching up after a few weeks out, excellent work with the QEMU tb-size issue! | |
| 10:42:29 | kashyap | lyarwood: Yeah, libvirt needs to wire it up now, though | |
| 10:43:21 | kashyap | I'll file a RHEL libvirt RFE - that might get on their triage queue quicker | |
| 10:44:38 | gibi | bauzas: awesome, thank you | |
| 10:50:25 | lyarwood | kashyap: yeah, shame we can't hackaround this in the meantime somehow | |
| 10:50:52 | lyarwood | kashyap: couldn't we pass QEMU args directly through libvirt from Nova in the meantime? | |
| 10:51:04 | kashyap | lyarwood: Definitely, there's QEMU command-line passthrough... | |
| 10:51:07 | kashyap | For libvirt XML | |
| 10:51:19 | lyarwood | second day back and I'm already writing another hackaround | |
| 10:51:22 | kashyap | lyarwood: But wait: | |
| 10:51:42 | kashyap | Nova doesn't have that XML modelling classes for command-line passthrough (for good reasons) :-( | |
| 10:52:01 | kashyap | lyarwood: The only current hack is to upload a custom QEMU build with that built in | |
| 10:52:09 | lyarwood | ewww | |
| 10:52:22 | lyarwood | I'd rather add the logic in Nova with a workaround option tbh | |
| 10:52:29 | lyarwood | than build our own custom QEMU | |
| 10:52:43 | kashyap | lyarwood: I agree, it's nasty to do the custom builds for medium-term | |
| 10:53:33 | kashyap | The logic in Nova would require to wire in these bits, BTW: https://libvirt.org/kbase/qemu-passthrough-security.html | |
| 10:53:43 | kashyap | (Including the namespace at the top) | |
| 10:53:56 | lyarwood | Yup that's easy enough | |
| 10:54:03 | kashyap | And still it requires more edits. I was testing last week | |
| 10:54:55 | kashyap | When using `-accel tcg,tb-size=256`, we should remove "accel=tcg" from `-machine q35,accel=tcg` | |
| 10:55:14 | kashyap | Otherwise QEMU fails to launch | |
| 10:55:37 | kashyap | (I think libvirt uses the latter syntax by default: "-machine ... accel=") | |
| 10:56:03 | kashyap | (Yep, it does. Just verified) | |
| 10:56:19 | ebbex | Is there a option/toggle to disable sending numa_topology from nova-compute? (We have some numascale hardware that submits "Data too long for column 'numa_topology') | |
| 10:57:20 | lyarwood | kashyap: oh fun | |
| 10:58:51 | kashyap | lyarwood: Yeah. For more on the nature of QEMU command-line, see my LWN article: https://lwn.net/SubscriberLink/872321/221e8d48eb609a38/) | |
| 10:59:25 | kashyap | (Especially the "Complexity on the QEMU command line" section) | |
| 11:01:23 | gibi | lyarwood: o/ we can revert the temp disable on the heal_allocation in nova-next the nova-manage support landed during the night. https://review.opendev.org/c/openstack/nova/+/816242 | |
| 11:01:41 | lyarwood | awesome checking | |
| 11:01:44 | gibi | thanks | |
| 11:01:59 | lyarwood | +W'd | |