| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-06-22 | |||
| 12:36:47 | bauzas | manuvakery1: if the host is disabled, then the Compute filter will say no | |
| 13:20:27 | noonedeadpunk | bauzas: returning back to the discussion in Vancouver regarding cross-AZ scheduling - I see that topic was mentioned in the etherpad, but I can't recall why that's smth we should not do? | |
| 13:21:11 | bauzas | noonedeadpunk: hmmm, about what exactly ? | |
| 13:21:31 | noonedeadpunk | like having anti-AZ server groups | |
| 13:22:02 | noonedeadpunk | Right now we're trying to implement a cross-AZ scheduling of octavia amphoras by defining AZs in their config. And then mess up with OCtavia flows to ensure it will supply AZ to the scheduler | |
| 13:22:54 | noonedeadpunk | But now I've started thinking if that's correct path at all, and if would be easier to just enable anti-az option (alike to anti-affinity) and nova will handle that | |
| 13:23:19 | bauzas | noonedeadpunk: fortunately, you mean you would use soft-anti-affinity group policy ? | |
| 13:24:32 | noonedeadpunk | well, soft anti-affinity does ensure that VMs will spawn on different computes, but it doesn't care about different AZs, right? | |
| 13:25:24 | noonedeadpunk | So what I was thinking is smth like that, but specifically for cross-AZs spawning of VMs | |
| 13:27:43 | noonedeadpunk | but maybe we should just continue doing that on Octavia side | |
| 13:28:22 | noonedeadpunk | ah, sorry, I meant this etherpad https://etherpad.opendev.org/p/nova-vancouver2023-meet-and-greet | |
| 13:32:00 | bauzas | sorry, was afk for a second | |
| 13:32:27 | bauzas | noonedeadpunk: we also discussed this on the PTG, you can look at my ML email | |
| 13:34:39 | noonedeadpunk | ah, true, failure-domain-anti-affinity | |
| 13:34:46 | bauzas | right | |
| 13:35:50 | noonedeadpunk | but I guess "failure-domain" functionality does not exist yet? | |
| 13:36:34 | noonedeadpunk | another thing that can be "interesting" if we consider storage should be shared between failure domains? As I won't count on that I guess | |
| 13:39:25 | bauzas | noonedeadpunk: tbc, we let operators define their own value of "failure domain" | |
| 13:39:57 | bauzas | in general, this is something larger than a single rack | |
| 13:40:48 | noonedeadpunk | ideally it's smth 30km in between :) | |
| 13:41:20 | bauzas | yeah, or just a DC room | |
| 13:41:38 | bauzas | (as a reminder, I was an operator before joining OpenStack ;) ) | |
| 13:41:56 | bauzas | just because in general, the failures are with A/C or network | |
| 13:42:25 | noonedeadpunk | or fire in DC :D | |
| 13:42:26 | bauzas | so, if the domain is larger than a rack, then it's simple to move instances between hosts | |
| 13:42:45 | bauzas | noonedeadpunk: lollylol (sorry OVH friends ;) ) | |
| 13:43:32 | noonedeadpunk | so, basically, option is: set metadata to aggregate which defines "failure-domain", then for server group provide the metadata and policy failure-domain-anti-affinity (or failure-domain-affinity)? | |
| 13:45:58 | bauzas | noonedeadpunk: what we said during the PTG to Bloomberg is that we could have a new API microversion for an admin saying "I'd want to live-migrate this instance from this server group to another" | |
| 13:46:27 | noonedeadpunk | that is completely different thing I guess? | |
| 13:46:42 | bauzas | and maybe have a new policy too | |
| 13:46:48 | bauzas | noonedeadpunk: https://etherpad.opendev.org/p/vancouver-june2023-nova#L121 | |
| 13:47:26 | noonedeadpunk | ok, yes, I was also talking about that... | |
| 13:47:42 | noonedeadpunk | then I'm slightly confused with live-migration | |
| 13:49:41 | noonedeadpunk | going back to our usecase with Octavia. What could be done instead of having AZ-scheduler in octavia code - just making a call to create 2 VMs withing same server group, and nova would take care of ensuring, they will be spawned on different failure domains | |
| 13:49:51 | noonedeadpunk | (just theoretically) | |
| 13:51:06 | noonedeadpunk | And why I got confused about live migrations, as in our usecase we have completely independent backing storages | |
| 13:51:41 | bauzas | noonedeadpunk: sorry I was quickly explaining about what we discussed with Bloomberg | |
| 13:51:56 | noonedeadpunk | yeah, ok, that makes sense as well :) | |
| 13:52:21 | bauzas | like, given they were using both AZ and server groups, they also wanted to violate their hard policy that they were using for packing instances to the same rack | |
| 13:52:39 | bauzas | basically, because sometimes you want to deprecate a rack :p | |
| 13:52:53 | noonedeadpunk | yeah, yeah, that makes sense as well | |
| 13:53:10 | bauzas | that's also why I provided https://review.opendev.org/c/openstack/nova/+/886232 to help operators to pack instances to hosts :) | |
| 13:53:32 | bauzas | instead of having to create some hard policies, which I utterly dislike :D | |
| 13:53:51 | noonedeadpunk | oh, that is neat | |
| 13:54:15 | noonedeadpunk | and way less complex then metric weighter | |
| 13:57:03 | noonedeadpunk | Also I'm asking as we're working with implementation in Octavia now, but maybe it would be better to switch to this failover-anti-affinity policy implementation in nova instead | |
| 13:57:33 | noonedeadpunk | but ok, I think I got the gist | |
| 14:00:07 | bauzas | noonedeadpunk: we could discuss this on the next vPTG | |
| 17:47:49 | opendevreview | Amit Uniyal proposed openstack/os-vif stable/yoga: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886710 | |
| 18:03:51 | manuvakery1 | bauzas: ok thanks | |
| 18:04:39 | opendevreview | Amit Uniyal proposed openstack/os-vif stable/xena: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886716 | |
| 18:30:21 | opendevreview | Amit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886778 | |
| 18:31:49 | opendevreview | sean mooney proposed openstack/nova master: Remove deprecated AZ filter. https://review.opendev.org/c/openstack/nova/+/886779 | |
| #openstack-nova - 2023-06-23 | |||
| 06:18:08 | opendevreview | Amit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886778 | |
| 06:23:17 | opendevreview | Amit Uniyal proposed openstack/os-vif stable/wallaby: set default qos policy https://review.opendev.org/c/openstack/os-vif/+/886778 | |
| 10:59:53 | opendevreview | sean mooney proposed openstack/nova master: conf: Deprecate AggregateImagePropertiesIsolation opts https://review.opendev.org/c/openstack/nova/+/783396 | |
| 11:47:25 | frickler | gibi: we are hitting https://review.opendev.org/c/openstack/nova/+/871968 on zed, anything we can help to make progress with that backport? | |
| 12:00:33 | gibi | frickler: I double checked that now and it seems it is OK so I +2d it | |
| 12:01:12 | sean-k-mooney | hehe i was about to do the same | |
| 12:01:38 | sean-k-mooney | frickler: so to answer your question appreeantly the answer is ping us :) | |
| 12:01:54 | frickler | oh, I was assuming the CI failure was because it was missing some other backport as basis. that was an easy one, then, thx | |
| 12:02:34 | sean-k-mooney | no the commit gibi asked about was merged when master was zed | |
| 12:15:23 | kashyap | Can anyone unpack this for me: qemu_6.2+dfsg-2ubuntu6.11 -- whta does the "2ubunut 6.11" mean? | |
| 12:15:47 | kashyap | The QEMU package version is 6.2; but what is "2ubuntu6.11"? Some "release" number? | |
| 12:17:02 | frickler | "+dfsg-2" usually is the debian version number and then "ubuntu6.11" is the 11th iteration of the 6th ubuntu patch of that | |
| 12:19:34 | kashyap | frickler: I see; thanks for the decryption; "11th iteration of the 6th ubuntu patch" -- means there really were 5 iterations of the patch that are searchable? | |
| 12:19:41 | kashyap | (Not that I want to find; but just curious) | |
| 12:20:19 | frickler | 1:6.2+dfsg-2ubuntu6 is the version that was released with Jammy, so according to stable policy all updates are patches of that | |
| 12:20:53 | frickler | https://launchpad.net/ubuntu/+source/qemu has some of what you may want to look at | |
| 12:22:12 | frickler | https://launchpad.net/ubuntu/+source/qemu/1:6.2+dfsg-2ubuntu5 is an older iteration from the development cycle it seems | |
| 12:24:16 | kashyap | Yeah, was looking there; thank you | |
| 12:24:23 | frickler | the main canonical developer is available on #ubuntu-server in libera if you have more specific questions | |
| 12:24:29 | kashyap | frickler: The reason I'm asking is - I'm about to bump libvirt/QEMU versions for Bobcat | |
| 12:24:45 | kashyap | Before that I just wanted to send an email to -discuss upstream list w/ it | |
| 12:25:04 | kashyap | The distros we care about are: Debian 12, Ubuntu Jammy (22.04), CentOS 9 Stream -- that's all, yeah? | |
| 12:25:38 | frickler | Not sure about debian 11 vs. 12, 12 may have been to late for bobcat | |
| 12:26:27 | frickler | we don't have it running in opendev yet, even less in devstack | |
| 12:26:33 | kashyap | Oh, so the upstream CI is testing w/ Debian 11? (Cc: sean-k-mooney --^) | |
| 12:26:44 | frickler | for now, yes | |
| 12:26:53 | kashyap | frickler: Good to know, so lemme check Debian 11 | |
| 12:27:00 | frickler | not sure if nova tests on debian at all, though | |
| 12:28:26 | sean-k-mooney | we dont currently but if we are advertisign the next version we are slecting for C and later | |
| 12:28:34 | sean-k-mooney | then we should look at debian 12 i think | |
| 12:28:49 | kashyap | frickler: So that's the Debian-11, right? For libvirt, at least - https://packages.debian.org/source/bullseye/libvirt | |
| 12:29:07 | kashyap | sean-k-mooney: Yeah, for next version definitely Bookworm (12) | |
| 12:29:35 | frickler | there's also https://packages.debian.org/source/bullseye-backports/libvirt which I think could be acceptable | |
| 12:30:16 | frickler | iiuc zigo curates those | |
| 12:30:29 | sean-k-mooney | we basiclaly just need to do a servay of what is in current LTS/Stable to determin our next min libvirt | |
| 12:30:42 | kashyap | Yep | |
| 12:31:01 | kashyap | I'll send out an email something like this from the past - https://lists.openstack.org/pipermail/openstack-discuss/2019-November/010907.html | |
| 12:31:06 | sean-k-mooney | the ones that kashyap will be updating to for this cycle are already known | |
| 12:31:14 | sean-k-mooney | and quite old | |
| 12:32:41 | kashyap | https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L221,#L222 | |
| 12:33:12 | sean-k-mooney | so we will be movign to libvirt 7.0.0 and qemu 5.2.0 we likely should ue libvirt 8.0.0 as the new value for NEXT_MIN_LIBVIRT_VERSION and | |
| 12:33:31 | kashyap | Yes, Jammy has: | |
| 12:33:33 | kashyap | libvirt-daemon: 8.0.0-1ubuntu7.5 -- https://packages.ubuntu.com/jammy-updates/libvirt-daemon | |
| 12:33:37 | kashyap | And: | |
| 12:33:40 | kashyap | qemu-system-x86: 6.2+dfsg-2ubuntu6.11 -- https://packages.ubuntu.com/jammy/qemu-system-x86 | |
| 12:33:55 | kashyap | - CentOS Stream 9: libvirt-daemon-kvm-9.3.0-2.el9.x86_64.rpm - qemu-kvm-8.0.0-4.el9.x86_64.rpm | |
| 12:34:15 | sean-k-mooney | and proably qemu 6.2 | |