Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-10-29
15:07:32 gibi OK, so we all the new neutron API extension that breaks existing tempest test we need to temporary disable the test, merge the API extension, merge the tempest adaptation, and then re-enable the test
15:07:43 gibi s/we/with/
15:08:03 gmann yeah, and for any type of bug fix in project if that is blocked by tempest tests
15:08:09 gibi ack
15:19:39 gibi melwitt: hi! I've fixed and replied to your comments in https://review.opendev.org/c/openstack/nova/+/802060 please ignore the nova-next failure for now, it is due and ordering issue, we need to land https://review.opendev.org/c/openstack/neutron/+/805637 (which is on the gate) first. See our discussion with gmann above ^^
16:00:17 opendevreview Merged openstack/nova stable/xena: Reproduce bug 1944759 https://review.opendev.org/c/openstack/nova/+/810910
17:03:35 spatel sean-k-mooney[m] morning
18:35:01 gibi gmann: so far so good, 805637 cleared the check queue and now running in the gate queue
18:53:56 gmann +1
20:04:45 gmann seems ovs multinode job again failing
#openstack-nova - 2021-10-30
05:19:24 gibi an now neutron functional and tempest slow :/
#openstack-nova - 2021-10-31
07:46:17 EugenMayer Good Morning. Using wallaby, creating a snapshot queues, but after some time, the snapshot task just disapears
07:48:17 EugenMayer does a snapshot need swift as a storage? We are using local disks as storage. So no centralized storage
07:55:32 EugenMayer Same happens if i uses openstack server backup create vpn on the cli - i see the job queued, see it in the ui, but then after some time it is gone and i do not see any snapshots
13:21:31 EugenMayer0 Are there any plans to add firecracker as a virtualization type in nova?
13:24:42 sean-k-mooney[m] not currently but i think is an interesting tech stack to consider
13:25:11 sean-k-mooney[m] i dont think it currently has libvirt integration but that might be the quickest way to integrate it
14:18:51 EugenMayer0 libvirt does include firecracker support, doesnt it?
#openstack-nova - 2021-11-01
07:59:53 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: trigger nova-next https://review.opendev.org/c/openstack/nova/+/816127
08:22:21 opendevreview Balazs Gibizer proposed openstack/nova master: [nova-manage]support extended resource request https://review.opendev.org/c/openstack/nova/+/802060
08:23:23 opendevreview Balazs Gibizer proposed openstack/nova master: Reno for qos-minimum-guaranteed-packet-rate https://review.opendev.org/c/openstack/nova/+/805046
08:24:36 opendevreview Balazs Gibizer proposed openstack/nova master: Reno for qos-minimum-guaranteed-packet-rate https://review.opendev.org/c/openstack/nova/+/805046
08:56:36 opendevreview Danil proposed openstack/nova master: Check if the InstanceNUMACell.pcpuset attribute exist prior to relying on it. This change enables support for the VM instances with pinned CPUs (hw:cpu_policy=dedicated) that were created before upgrading the OpenStack Nova to Victoria release. https://review.opendev.org/c/openstack/nova/+/815923
09:33:08 stephenfin gibi: Are you planning to backport that nova-manage command for extended resource requests? Maybe that doesn't make sense, since the neutron feature didn't land in time?
09:33:40 gibi stephenfin: hi! no, it does not make sense as you said, it only adds value if there is the new neutron api extension
09:33:47 stephenfin ack
09:34:03 gibi with the old extension the old nova-manage works OK
09:39:20 lyarwood Morning all \o
09:43:11 gibi lyarwood: welcome back!
09:43:26 lyarwood thanks gibi, good to be back
09:45:25 gibi ahh, sh*t. I think nova-next is broken https://review.opendev.org/c/openstack/neutron/+/805637 landed during the weekend.
09:45:37 gibi we had some ordering issue with the pps patches I think
09:46:25 gibi https://zuul.opendev.org/t/openstack/build/f499bc60c7124acea23b05593405f278/log/job-output.txt#62786
09:46:54 gibi we should have landed https://review.opendev.org/c/openstack/nova/+/802060 before the neutron patch
09:47:48 gibi so now we either turn off the nova-manage placement heal_allocations testing in the post hook in nova-next, or we quickly land https://review.opendev.org/c/openstack/nova/+/802060
09:49:05 lyarwood I can't guarantee that I'll get to the open review today so it might be easier to turn it off, rebase the change onto that while also turning the testing back on etc
09:49:34 gibi lyarwood: stephenfin and melwitt reviewed https://review.opendev.org/c/openstack/nova/+/802060 already so it is close to land
09:49:40 lyarwood ah
09:49:49 gibi so you are off the hook :)
09:49:51 lyarwood it's your call then if you already have two cores on it
09:49:53 stephenfin lyarwood: welcome back o/
09:49:57 lyarwood \o
09:50:38 gibi I will propose the turn off of the test quickly that is easy and we have enough cores online now to land that it quickly
09:50:52 opendevreview Merged openstack/nova stable/train: address open redirect with 3 forward slashes https://review.opendev.org/c/openstack/nova/+/806629
09:56:53 opendevreview Balazs Gibizer proposed openstack/nova master: Temp disable nova-manage placement heal_allocation testing https://review.opendev.org/c/openstack/nova/+/816156
09:57:11 gibi stephenfin, lyarwood: ^^ this hopefully fixes the gate
09:57:49 gibi btw I'm mostly off today as it is a public holiday here, I will be here tomorrow, but I have to take a day of on Wednesday too
10:06:26 lyarwood gibi: ack enjoy :)
10:06:34 gibi thanks
10:14:28 opendevreview Jan Hartkopf proposed openstack/nova master: add support for updating server's user_data https://review.opendev.org/c/openstack/nova/+/816157
10:22:00 opendevreview Jan Hartkopf proposed openstack/python-novaclient master: add support for microversion 2.91 https://review.opendev.org/c/openstack/python-novaclient/+/816158
11:26:57 opendevreview Balazs Gibizer proposed openstack/nova master: Temp disable nova-manage placement heal_allocation testing https://review.opendev.org/c/openstack/nova/+/816156
12:44:46 EugenMayer is there a way to set the DNS server and hostname of an instance in wallaby when booting a cloud init instance?
14:02:00 frickler EugenMayer: did you see https://docs.openstack.org/neutron/latest/admin/config-dns-res.html ? that sets the dns server and the instance receives that information via DHCP. the hostname of an instance is pretty much hardcoded to the name of the instance afaict
14:06:08 EugenMayer frickler seen it, but that is per segment
14:06:29 EugenMayer frickler would have loved to override it for some (very few)
14:41:11 EugenMayer frickler hostname can be done in Xena during server create, but i'am yet forced to use wallaby due to the Xena/OVN metadata issue
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

Earlier   Later