| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-03-23 | |||
| 18:00:56 | sean-k-mooney | req-90bd91de-9909-4b0a-a16f-1de245c67834 tempest-SecurityGroupRulesTestJSON-617656270 tempest-SecurityGroupRulesTestJSON-617656270-project-member] 10.209.0.48 "POST /compute/v2.1/os-security-groups" status: 200 | |
| 18:01:06 | sean-k-mooney | so nova was happy with it | |
| 18:03:55 | sean-k-mooney | im not seeing isseu on the neutorn side so im pretty happy this is a one off failure | |
| 18:04:15 | sean-k-mooney | i just have not seen that test fail before at least not that stuck out in my memory | |
| 18:04:40 | sean-k-mooney | so i wanted to check it a little more deeply in case it was a real failure | |
| 21:06:45 | opendevreview | Merged openstack/nova master: Add grenade-skip-level-always to nova https://review.opendev.org/c/openstack/nova/+/875773 | |
| #openstack-nova - 2023-03-24 | |||
| 09:43:05 | Uggla | bauzas, short msg to tell you that I have added a point about virtiofs next features. It would be great to have a short session to discuss that especially with Adri2000 who could be a potential user. | |
| 09:44:56 | Uggla | bauzas, I know it is maybe a bit early, but I guess it could help me to figure out what will be the next topics to address. | |
| 09:51:52 | bauzas | Uggla: yeah, np, for sure | |
| 09:52:13 | Uggla | bauzas, \o/ | |
| 09:52:29 | bauzas | Uggla: as you can see, I eventually didn't really created an agenda, we'll lookup the topics one after the other | |
| 09:52:48 | bauzas | each one after the other one* | |
| 09:53:20 | Uggla | bauzas, maybe for this one it could be good to have a slot. I guess it will be easier to Adri2000 to join. | |
| 09:54:09 | Uggla | bauzas, maybe that could stand right after the manila one ? | |
| 09:55:33 | bauzas | Uggla: in general I ping the courtesy ping list before a topic, to ask them when they have time to discuss | |
| 10:01:01 | Uggla | bauzas, I'm saying that because Adri2000 told me, he will join the manila session. Just to let you know, if it could help you. | |
| 10:01:16 | bauzas | I can discuss with Adrien, np | |
| 10:04:49 | Uggla | bauzas, good so now I jump back to the virtiofs stuff to rework the interfaces because you dislike them. ;) | |
| 14:21:42 | zigo | bauzas: When live-mig fails, I have this in my syslog: https://paste.opendev.org/show/b2sqj6SSBsGOdN2D4phz/ | |
| 14:21:42 | zigo | (sorry, didn't noticed it yesterday) | |
| 14:21:42 | zigo | Does this help a little ? | |
| 14:24:47 | kashyap | zigo: Randomly noticing it here. That's a strange error I've never seen | |
| 14:24:49 | kashyap | internal error: qemu unexpectedly closed the monitor: 2023-03-24T14:19:28.554056Z qemu-system-x86_64: VQ 2 size 0x80 < last_avail_idx 0x83d9 - used_idx 0x0 | |
| 14:26:52 | zigo | kashyap: Yeah, this feels like a libvirt / qemu bug, rather than an issue in Nova... | |
| 14:27:01 | kashyap | The error is definitely coming from QEMU | |
| 14:27:23 | kashyap | zigo: Are you hitting it consistently? What QEMU/libvirt versions? | |
| 14:27:30 | kashyap | Can you post the full guest QEMU invocatoin? | |
| 14:27:38 | kashyap | All of 'em preferably in a bug (if it's reproducible) :-) | |
| 14:28:26 | zigo | qemu: 1:5.2+dfsg-11+deb11u2 | |
| 14:28:26 | zigo | libvirt: 7.0.0 | |
| 14:28:26 | zigo | (this is a plain Debian Bullseye...) | |
| 14:28:59 | zigo | kashyap: When the VM can't live-migrate, it goes back to state MIGRATING to ACTIVE, and I can make it happen again, yes. | |
| 14:29:18 | zigo | kashyap: When the VM can't live-migrate, it goes back from state MIGRATING to ACTIVE, and I can make it happen again, yes. | |
| 14:29:21 | kashyap | Same versions on source and destination hosts? | |
| 14:29:26 | zigo | Yeah. | |
| 14:29:56 | zigo | What's weird is that, on each compute, we run maybe 100+ VMs, and each time, 2 or 3 are stuck, refusing to migrate this way. | |
| 14:31:02 | kashyap | Hm, these bugs need a more systematic debugging. Please file a bug. But it might very well be fixed upstream (I know) | |
| 14:31:13 | kashyap | See this, for example: https://www.mail-archive.com/qemu-devel@nongnu.org/msg441182.html | |
| 14:31:23 | kashyap | A similar error) | |
| 14:33:20 | zigo | Yeah. | |
| 14:33:44 | zigo | Is there a qemu IRC channel? | |
| 14:35:04 | kashyap | Yes | |
| 14:35:08 | kashyap | #qemu, OFTC | |
| 14:35:16 | zigo | Will try. | |
| 16:03:32 | bauzas | tmazur: so you want to have a cross-project session for Horizon ? | |
| 16:08:02 | tmazur | bauzas: it would be nice, but we do not insist. We would like to just clarify things about potential implementation python bindings. It's pretty clear that osc-placement is not the right place for them anyway, and you pointed it in the etherpad. Is something like python-placementclient coming in any reasonable future? | |
| 16:16:20 | vishalmanchanda | bauzas: hello, Can we have a 20-25 mins nova-horizon cross-project session on Tuesday, March 28 at 15 UTC? | |
| 16:17:15 | vishalmanchanda | bauzas: or please suggest some other time slots? | |
| 16:17:25 | bauzas | vishalmanchanda: tmazur: unfortunately Tues 15UTC is already taken https://etherpad.opendev.org/p/nova-bobcat-ptg#L39 | |
| 16:17:26 | vishalmanchanda | that works for nova team | |
| 16:18:02 | vishalmanchanda | Is any other time slot available on Tuesday? | |
| 16:18:24 | bauzas | vishalmanchanda: we could do it ealier, say 1400UTC | |
| 16:18:34 | bauzas | if it takes 30 mins, that would suit | |
| 16:19:57 | vishalmanchanda | bauzas: works for me. tmazur what about you? | |
| 16:21:46 | tmazur | Works for me | |
| 16:24:09 | vishalmanchanda | bauzas: ok, then, please book Tuesday, March 28 at 1400UTC slot for the horizon cross-project session. | |
| 16:24:42 | bauzas | vishalmanchanda: did it : https://etherpad.opendev.org/p/nova-bobcat-ptg#L42 works for you to use our room ? (diablo) | |
| 16:25:27 | vishalmanchanda | bauzas: yeah, horizon team can joins nova room, thanks | |
| 16:25:27 | bauzas | vishalmanchanda: tmazur: agenda for our x-p session is https://etherpad.opendev.org/p/nova-bobcat-ptg#L103 | |
| 16:25:32 | bauzas | all set then | |
| 16:25:42 | bauzas | thanks folks | |
| 16:25:51 | vishalmanchanda | bauzas: great. | |
| 16:25:54 | tmazur | Thanks! | |
| 16:26:02 | vishalmanchanda | thanks:) | |
| 16:26:23 | bauzas | np | |
| 16:26:28 | bauzas | happy to help | |
| #openstack-nova - 2023-03-26 | |||
| 09:43:25 | opendevreview | Takashi Natsume proposed openstack/placement master: Move implemented specs for Xena and Yoga release https://review.opendev.org/c/openstack/placement/+/853730 | |
| 09:43:40 | opendevreview | Takashi Natsume proposed openstack/placement master: Fix a wrong assertion method https://review.opendev.org/c/openstack/placement/+/861489 | |
| 09:44:15 | opendevreview | Takashi Natsume proposed openstack/nova master: Update contributor guide for 2023.2 Bobcat https://review.opendev.org/c/openstack/nova/+/876447 | |
| #openstack-nova - 2023-03-27 | |||
| 11:50:50 | bauzas | fwiw, I'll attend the publicclould vPTG sessions today | |
| 12:51:07 | bauzas | gibi: sean-k-mooney: we need a second core, please https://review.opendev.org/c/openstack/nova/+/875621 | |
| 12:52:00 | sean-k-mooney | we are pas the RC phase so sure. | |
| 12:54:49 | sean-k-mooney | bauzas: by the way we know what az the instance is on in the hostmanager but on in the filters | |
| 12:55:01 | sean-k-mooney | bauzas: that is why we need the new filed | |
| 12:55:34 | bauzas | sean-k-mooney: tbh, before discussing about it, I'd prefer to have a spec | |
| 12:55:41 | bauzas | because I don't understand about the usecase | |
| 12:55:57 | bauzas | (I mean AZ soft affinity) | |
| 12:56:16 | sean-k-mooney | bauzas: mnaser was the first to bring it up | |
| 12:56:18 | bauzas | but ok, if we need to create a field, meh then | |
| 12:56:43 | sean-k-mooney | bauzas: basically the use the cross_az attach option in the vexhost public cloud | |
| 12:56:51 | bauzas | for example, if you see, people don't even know about all the existing config options | |
| 12:57:02 | sean-k-mooney | but they dont force user to set an az when the vm is created | |
| 12:57:05 | bauzas | even if we document it in the config option | |
| 12:57:16 | sean-k-mooney | and then if the user does a rezie it can fail and get reschedulerd | |
| 12:57:26 | bauzas | sean-k-mooney: I think we said before that the fact that Cinder uses AZs is different from Nova | |
| 12:57:46 | sean-k-mooney | thats not true however and also not the problem | |
| 12:57:54 | bauzas | so I'm a bit not happy with the cross_az_attach option | |
| 12:58:13 | sean-k-mooney | the propbelm is we have a config cross_az_attach that changes api/sechduler beahvior in a non discofverable way | |
| 12:58:20 | bauzas | maybe we would rather need to discuss with Cinder what we could do if so | |
| 12:58:42 | sean-k-mooney | right so this is a very very similar situration to the routed networks issue | |
| 12:59:27 | sean-k-mooney | we have an addtional constratint when cross_az_attach=false (like the ip aviablity) which is not currently consider by placement or the schduler | |
| 12:59:44 | bauzas | anyway, going to the vPTG now | |
| 12:59:53 | sean-k-mooney | the correct longterm fix would be too model cinder volume backend avaibality as placmenet aggreates | |
| 13:00:01 | bauzas | sean-k-mooney: yeah, so we should discuss this with Cinder | |
| 13:00:07 | bauzas | indeed | |
| 13:00:13 | bauzas | I agree with ^ | |
| 13:00:32 | sean-k-mooney | ya so that woudl be good to do and i have a usecasue related to this that i would like us to also do | |
| 13:00:37 | sean-k-mooney | ill add it to the adgenda | |
| 13:02:08 | sean-k-mooney | clip notes version is, when using iamges_type RBD i would like to create an aggreate usign the ceph FSID and recored the fsid of cluster the instance is using in the instnace_system_metadta so that we can automatically sechdule ot those in teh came ceph cluster wehn moving RBD backed vms | |
| 13:02:58 | sean-k-mooney | right now we have exactly the same problem that we can select hosts that do not have accces to the cluster based on there local confg | |