Earlier  
Posted Nick Remark
#openstack-nova - 2023-03-23
17:57:13 sean-k-mooney there are a bunch of faults like that in the nova api
17:57:53 sean-k-mooney although im not sure its the same test
17:59:14 gmann api log might be confusing on NotFound due to negative tests
17:59:26 sean-k-mooney ya i was assumign that too
17:59:38 sean-k-mooney but i was just checkign to see if there are any erference to that est
18:00:18 sean-k-mooney ah found the request id req-90bd91de-9909-4b0a-a16f-1de245c67834
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

Earlier   Later