| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-05-12 | |||
| 14:31:02 | sean-k-mooney | stephenfin: you used to have a header you added to RST files to forward declare the header level symbols | |
| 14:31:21 | sean-k-mooney | i tought that was in one of the spec templates but i cant find it do you rememebr what it was | |
| 14:31:21 | sean-k-mooney | i tought that was in one of the spec templates but i cant find it do you rememebr what it was | |
| 14:31:46 | sean-k-mooney | it was a comment you put at the top of the file then just a buch of header lines that would not render | |
| 14:31:46 | sean-k-mooney | it was a comment you put at the top of the file then just a buch of header lines that would not render | |
| 14:32:32 | stephenfin | sean-k-mooney: precede the block with .. | |
| 14:32:32 | stephenfin | sean-k-mooney: precede the block with .. | |
| 14:32:35 | stephenfin | that's a comment | |
| 14:32:35 | stephenfin | that's a comment | |
| 14:32:43 | stephenfin | I think the neutron docs use it for license headers | |
| 14:32:43 | stephenfin | I think the neutron docs use it for license headers | |
| 14:32:58 | sean-k-mooney | ah ok we use it for the lisence yes | |
| 14:32:58 | sean-k-mooney | ah ok we use it for the lisence yes | |
| 15:27:06 | melwitt | stephenfin: ack, will put them on my list | |
| 15:27:06 | melwitt | stephenfin: ack, will put them on my list | |
| 15:40:29 | stephenfin | thanks | |
| 15:40:29 | stephenfin | thanks | |
| 16:06:00 | NobodyCam | Good morning Nova folks, anyone have a pointer as to why the nova-python-client would not honor timeout values when the network drops? | |
| 16:06:01 | NobodyCam | Good morning Nova folks, anyone have a pointer as to why the nova-python-client would not honor timeout values when the network drops? | |
| 16:13:26 | sean-k-mooney | maybe the socket hangs at the kernel level or soemthign like that but no i dont know why that would happen | |
| 16:13:26 | sean-k-mooney | maybe the socket hangs at the kernel level or soemthign like that but no i dont know why that would happen | |
| 16:13:56 | sean-k-mooney | NobodyCam: i assume the behavior is if the network drops the nova client just sits there waiting for a respocne that wont come | |
| 16:13:56 | sean-k-mooney | NobodyCam: i assume the behavior is if the network drops the nova client just sits there waiting for a respocne that wont come | |
| 16:14:06 | sean-k-mooney | or are you seeign a different behavior | |
| 16:14:06 | sean-k-mooney | or are you seeign a different behavior | |
| 16:14:49 | NobodyCam | nope that's what I'm seeing | |
| 16:14:49 | NobodyCam | nope that's what I'm seeing | |
| 16:14:58 | NobodyCam | and Good Morning sean-k-mooney | |
| 16:14:58 | NobodyCam | and Good Morning sean-k-mooney | |
| 16:19:11 | sean-k-mooney | NobodyCam: so ya my only guess is the socket is staling on the kernel side. i would have expected any timeout you set to be passed to the request libary and for it to be handeled there | |
| 16:19:11 | sean-k-mooney | NobodyCam: so ya my only guess is the socket is staling on the kernel side. i would have expected any timeout you set to be passed to the request libary and for it to be handeled there | |
| 16:19:42 | sean-k-mooney | we dont start any timers ectra in the nova client to interupt the request ourselves | |
| 16:19:42 | sean-k-mooney | we dont start any timers ectra in the nova client to interupt the request ourselves | |
| 16:19:56 | NobodyCam | ++ makes sense to me | |
| 16:19:56 | NobodyCam | ++ makes sense to me | |
| 16:24:22 | sean-k-mooney | melwitt: you know the nova client better then i do you have any other ideas why NobodyCam issue would happen? | |
| 16:24:22 | sean-k-mooney | melwitt: you know the nova client better then i do you have any other ideas why NobodyCam issue would happen? | |
| 16:27:09 | melwitt | sean-k-mooney: if I understand the question correctly, my answer would be the same as what you said earlier. is it that the "timeout" kwarg is being passed to the novaclient bindings and it's not waiting as long as the specified timeout when there's no response? | |
| 16:27:10 | melwitt | sean-k-mooney: if I understand the question correctly, my answer would be the same as what you said earlier. is it that the "timeout" kwarg is being passed to the novaclient bindings and it's not waiting as long as the specified timeout when there's no response? | |
| 16:28:44 | melwitt | my experience with the requests library is that in the case of a non-response, it will stop waiting after about 30 seconds, even if you've no timeout (None) or a longer timeout | |
| 16:28:44 | melwitt | my experience with the requests library is that in the case of a non-response, it will stop waiting after about 30 seconds, even if you've no timeout (None) or a longer timeout | |
| 16:29:37 | sean-k-mooney | right so we pass the timeout to keystone auth here https://github.com/openstack/python-novaclient/blob/d4399d3d36c456c1001b96178ce9b3e7ec082460/novaclient/client.py#L137-L141 which form its docstring it passes to requests https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/session.py#L292-L295 | |
| 16:29:37 | sean-k-mooney | right so we pass the timeout to keystone auth here https://github.com/openstack/python-novaclient/blob/d4399d3d36c456c1001b96178ce9b3e7ec082460/novaclient/client.py#L137-L141 which form its docstring it passes to requests https://github.com/openstack/keystoneauth/blob/master/keystoneauth1/session.py#L292-L295 | |
| 16:30:57 | melwitt | yeah. I think if you tried a bare requests call for the same thing, you'd see the same behavior with the timeout | |
| 16:30:57 | melwitt | yeah. I think if you tried a bare requests call for the same thing, you'd see the same behavior with the timeout | |
| 16:34:57 | sean-k-mooney | thanks i have skimmed the nova clint code in the past but never really dug into it so just wanted to ensure im not missing anything obvious | |
| 16:34:57 | sean-k-mooney | thanks i have skimmed the nova clint code in the past but never really dug into it so just wanted to ensure im not missing anything obvious | |
| 16:36:26 | melwitt | no, I don't think you're missing anything | |
| 16:36:26 | melwitt | no, I don't think you're missing anything | |
| 16:37:02 | NobodyCam | Thank you both! | |
| 16:37:02 | NobodyCam | Thank you both! | |
| 19:34:08 | openstackgerrit | sean mooney proposed openstack/nova-specs master: [WIP] pci device tracking in placment https://review.opendev.org/c/openstack/nova-specs/+/791047 | |
| 19:34:08 | openstackgerrit | sean mooney proposed openstack/nova-specs master: [WIP] pci device tracking in placment https://review.opendev.org/c/openstack/nova-specs/+/791047 | |
| 19:35:14 | sean-k-mooney | that still pretty incomplete but im finsihing up for the day so said i woudl push what i had | |
| 19:35:14 | sean-k-mooney | that still pretty incomplete but im finsihing up for the day so said i woudl push what i had | |
| 21:04:25 | andrewbogott | Hello all! I have a question about address records. I'm looking at a unit test in trove which mocks an instance address record like this: | |
| 21:04:25 | andrewbogott | Hello all! I have a question about address records. I'm looking at a unit test in trove which mocks an instance address record like this: | |
| 21:04:29 | andrewbogott | https://www.irccloud.com/pastebin/gWoqmguo/ | |
| 21:04:29 | andrewbogott | https://www.irccloud.com/pastebin/gWoqmguo/ | |
| 21:04:36 | andrewbogott | My actual running cloud shows things that look more like this: | |
| 21:04:36 | andrewbogott | My actual running cloud shows things that look more like this: | |
| 21:04:50 | andrewbogott | https://www.irccloud.com/pastebin/mqZwz6TN/ | |
| 21:04:50 | andrewbogott | https://www.irccloud.com/pastebin/mqZwz6TN/ | |
| 21:05:20 | andrewbogott | My question is: did the record ever look like the former, and changed? Or is it possible for it to look either way depending on neutron setup? | |
| 21:05:20 | andrewbogott | My question is: did the record ever look like the former, and changed? Or is it possible for it to look either way depending on neutron setup? | |
| #openstack-nova - 2021-05-13 | |||
| 06:20:43 | openstackgerrit | Tetsuro Nakamura proposed openstack/osc-placement master: Support microversion 1.30 - /reshaper API https://review.opendev.org/c/openstack/osc-placement/+/696663 | |
| 06:20:43 | openstackgerrit | Tetsuro Nakamura proposed openstack/osc-placement master: Support microversion 1.30 - /reshaper API https://review.opendev.org/c/openstack/osc-placement/+/696663 | |
| 06:23:57 | openstackgerrit | Tetsuro Nakamura proposed openstack/osc-placement master: Add "--resource-class" to allocation unset https://review.opendev.org/c/openstack/osc-placement/+/697620 | |
| 06:23:57 | openstackgerrit | Tetsuro Nakamura proposed openstack/osc-placement master: Add "--resource-class" to allocation unset https://review.opendev.org/c/openstack/osc-placement/+/697620 | |
| 06:29:06 | openstackgerrit | Tetsuro Nakamura proposed openstack/osc-placement master: Verify result for inventory set --dry-run https://review.opendev.org/c/openstack/osc-placement/+/680295 | |
| 06:29:06 | openstackgerrit | Tetsuro Nakamura proposed openstack/osc-placement master: Verify result for inventory set --dry-run https://review.opendev.org/c/openstack/osc-placement/+/680295 | |
| 09:03:53 | openstackgerrit | chengsheng proposed openstack/nova master: libvirt: Use improved guest CPU config APIs https://review.opendev.org/c/openstack/nova/+/762330 | |
| 09:19:52 | openstackgerrit | Merged openstack/osc-placement master: setup.cfg: Replace dashes with underscores https://review.opendev.org/c/openstack/osc-placement/+/790630 | |
| 09:19:52 | openstackgerrit | Merged openstack/osc-placement master: setup.cfg: Replace dashes with underscores https://review.opendev.org/c/openstack/osc-placement/+/790630 | |
| 10:04:21 | ignaziocassano | ralonsoh: as you suggested in last chat I fired a new bug 1928299 for train centos7 live migration packet loss .But thy told me is is a duplicate of 1815989 | |
| 10:04:22 | openstack | bug 1928299 in neutron train "centos7 train vm live migration stops network on vm for some minutes" [Medium,Incomplete] https://launchpad.net/bugs/1928299 | |
| 10:04:22 | openstack | bug 1928299 in neutron train "centos7 train vm live migration stops network on vm for some minutes" [Medium,Incomplete] https://launchpad.net/bugs/1928299 | |
| 10:04:22 | ignaziocassano | ralonsoh: as you suggested in last chat I fired a new bug 1928299 for train centos7 live migration packet loss .But thy told me is is a duplicate of 1815989 | |
| 10:05:47 | sean-k-mooney | ignaziocassano: it is a duplicate what you need to do is set the affect release on https://bugs.launchpad.net/neutron/+bug/1815989 | |
| 10:05:49 | openstack | Launchpad bug 1815989 in neutron "OVS drops RARP packets by QEMU upon live-migration causes up to 40s ping pause in Rocky" [Undecided,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) | |
| 10:05:49 | openstack | Launchpad bug 1815989 in neutron "OVS drops RARP packets by QEMU upon live-migration causes up to 40s ping pause in Rocky" [Undecided,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez) | |
| 10:05:49 | sean-k-mooney | ignaziocassano: it is a duplicate what you need to do is set the affect release on https://bugs.launchpad.net/neutron/+bug/1815989 | |
| 10:08:22 | ralonsoh | ignaziocassano, please, try to backport https://review.opendev.org/q/Iee323943ac66e566e5a5e92de1861832e86fc7fc to Ussuri and then Train | |
| 10:08:22 | ralonsoh | ignaziocassano, please, try to backport https://review.opendev.org/q/Iee323943ac66e566e5a5e92de1861832e86fc7fc to Ussuri and then Train | |
| 10:09:15 | ralonsoh | I won't have time until the end for next week | |
| 10:09:15 | ralonsoh | I won't have time until the end for next week | |
| 10:09:45 | ignaziocassano | ralonsoh: I will try soon. Yhks | |
| 10:09:45 | ignaziocassano | ralonsoh: I will try soon. Yhks | |
| 11:04:48 | openstackgerrit | Lee Yarwood proposed openstack/nova master: hardware: Use image_meta.id within get_mem_encryption_constraint https://review.opendev.org/c/openstack/nova/+/790660 | |
| 11:04:48 | openstackgerrit | Lee Yarwood proposed openstack/nova master: image_meta: Provide image_ref as the id when fetching from instance https://review.opendev.org/c/openstack/nova/+/790659 | |
| 11:04:48 | openstack | bug 1928063 in OpenStack Compute (nova) "SEV enabled instance unable to hard reboot" [Undecided,In progress] https://launchpad.net/bugs/1928063 - Assigned to Lee Yarwood (lyarwood) | |
| 11:04:48 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Add regression test for bug #1928063 https://review.opendev.org/c/openstack/nova/+/790658 | |
| 11:48:17 | openstackgerrit | Takashi Natsume proposed openstack/os-traits master: setup.cfg: Replace dashes with underscores https://review.opendev.org/c/openstack/os-traits/+/791133 | |
| 11:48:17 | openstackgerrit | Takashi Natsume proposed openstack/os-traits master: setup.cfg: Replace dashes with underscores https://review.opendev.org/c/openstack/os-traits/+/791133 | |
| 11:54:11 | openstackgerrit | sean mooney proposed openstack/nova master: [compute] always set instnace.host in post_livemigration https://review.opendev.org/c/openstack/nova/+/791135 | |
| 11:54:11 | openstackgerrit | sean mooney proposed openstack/nova master: [compute] always set instnace.host in post_livemigration https://review.opendev.org/c/openstack/nova/+/791135 | |
| 12:03:30 | sean-k-mooney | lyarwood: related to ^ i was thinking that maybe we coudl extend hard reboot to fix some issue if we can detect them | |
| 12:03:30 | sean-k-mooney | lyarwood: related to ^ i was thinking that maybe we coudl extend hard reboot to fix some issue if we can detect them | |
| 12:04:38 | sean-k-mooney | normally hard reboot does nto talk to neutron to bind port and in general i think that shoudl continue to be the case. but what i was thinking is maybe we should check the host in the network info cache if its set and fix the port binding maybe do the same for volumes? | |
| 12:04:38 | sean-k-mooney | normally hard reboot does nto talk to neutron to bind port and in general i think that shoudl continue to be the case. but what i was thinking is maybe we should check the host in the network info cache if its set and fix the port binding maybe do the same for volumes? | |