Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-05-12
11:26:23 sean-k-mooney im not currently plannign to work on backporting it. i may in the future but i have some other things i need to work on
11:26:23 sean-k-mooney im not currently plannign to work on backporting it. i may in the future but i have some other things i need to work on
11:28:17 ignaziocassano1 So, what can I do to solve it? Next year we 'll invest money for acquire red hat support, but now we cannot
11:28:17 ignaziocassano1 So, what can I do to solve it? Next year we 'll invest money for acquire red hat support, but now we cannot
11:31:41 sean-k-mooney one option is to try propose the backport yourself or see if rodolfo or others have time to backport it. i generally try to help people regardless of if they are a customer or not but this partical set of bugs has made me consider quiting opentack developemnt and doing something else with my life so not that its finally merged i dont really want to spend more time on it
11:31:41 sean-k-mooney one option is to try propose the backport yourself or see if rodolfo or others have time to backport it. i generally try to help people regardless of if they are a customer or not but this partical set of bugs has made me consider quiting opentack developemnt and doing something else with my life so not that its finally merged i dont really want to spend more time on it
11:34:12 ignaziocassano1 Yes, I understand your position
11:34:12 ignaziocassano1 Yes, I understand your position
11:35:50 jrosser gibi: thanks for the default_log_levels tip, it's working for me now
11:35:50 jrosser gibi: thanks for the default_log_levels tip, it's working for me now
11:36:02 gibi jrosser: cool. happy to help
11:36:02 gibi jrosser: cool. happy to help
12:56:12 kashyap lyarwood: Can you double-confirm: I don't see any use of QEMU's internal snapshots in the code (`qemu-img snapshot ...`)
12:56:12 kashyap lyarwood: Can you double-confirm: I don't see any use of QEMU's internal snapshots in the code (`qemu-img snapshot ...`)
12:56:29 kashyap lyarwood: The only known use was removed way back in 2013 in this commit: 8c985874c7885f31871204d3f83ce547fefc5fb6)
12:56:29 kashyap lyarwood: The only known use was removed way back in 2013 in this commit: 8c985874c7885f31871204d3f83ce547fefc5fb6)
12:56:59 lyarwood kashyap: you mean qcow2 snapshots right?
12:56:59 lyarwood kashyap: you mean qcow2 snapshots right?
12:57:00 kashyap lyarwood: I ask because ... a certain enterprise distro might deprecate internal snapshots (for good reasons)
12:57:00 kashyap lyarwood: I ask because ... a certain enterprise distro might deprecate internal snapshots (for good reasons)
12:57:16 kashyap lyarwood: Yes, exactly. I recall we used to use it; and I don't see any trace of it (good thing)
12:57:16 kashyap lyarwood: Yes, exactly. I recall we used to use it; and I don't see any trace of it (good thing)
13:01:34 lyarwood kashyap: yeah I can't think of any examples where we do
13:01:34 lyarwood kashyap: yeah I can't think of any examples where we do
13:01:48 kashyap lyarwood: Cool; I just checked the code, I don't see any other traces. That's great
13:01:48 kashyap lyarwood: Cool; I just checked the code, I don't see any other traces. That's great
13:01:49 lyarwood kashyap: even the NFS based cinder backends that use qcow2 use backing files
13:01:49 lyarwood kashyap: even the NFS based cinder backends that use qcow2 use backing files
13:01:57 kashyap Sweet
13:01:57 kashyap Sweet
13:02:44 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Create 'nova.tests.fixtures' module https://review.opendev.org/c/openstack/nova/+/790965
13:02:44 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Create 'nova.tests.fixtures' module https://review.opendev.org/c/openstack/nova/+/790965
13:02:45 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Move ConfFixture https://review.opendev.org/c/openstack/nova/+/790966
13:02:45 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Move ConfFixture https://review.opendev.org/c/openstack/nova/+/790966
13:02:46 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Move remaining non-libvirt fixtures https://review.opendev.org/c/openstack/nova/+/790967
13:02:47 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Split external service fixtures out https://review.opendev.org/c/openstack/nova/+/790968
13:02:47 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Move libvirt-specific fixtures https://review.opendev.org/c/openstack/nova/+/790969
13:02:48 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Add os-brick fixture https://review.opendev.org/c/openstack/nova/+/790970
13:02:49 openstackgerrit Stephen Finucane proposed openstack/nova master: WIP: Use jinja2 to generate fake libvirt data https://review.opendev.org/c/openstack/nova/+/790971
14:27:30 stephenfin gibi: melwitt, dansmith: If you folks have time this week, could you queue up the first few patches in the remove-sqlalchemy-migrate series? They're all precusor patches that I'd like to get out of the way before we get into the nitty-gritty of alembic integration https://review.opendev.org/q/topic:%22bp%252Fremove-sqlalchemy-migrate%22+(status:open%20OR%20status:merged)
14:27:30 stephenfin gibi: melwitt, dansmith: If you folks have time this week, could you queue up the first few patches in the remove-sqlalchemy-migrate series? They're all precusor patches that I'd like to get out of the way before we get into the nitty-gritty of alembic integration https://review.opendev.org/q/topic:%22bp%252Fremove-sqlalchemy-migrate%22+(status:open%20OR%20status:merged)
14:27:52 stephenfin (I have patches locally but won't push them yet since they're not _quite_ ready)
14:27:52 stephenfin (I have patches locally but won't push them yet since they're not _quite_ ready)
14:28:58 gibi stephenfin: ack. No promise for this week but I will try
14:28:58 gibi stephenfin: ack. No promise for this week but I will try
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: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

Earlier   Later