Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-05-12
10:35:16 sean-k-mooney gibi: right now i really dont like that its different per command
10:35:16 sean-k-mooney gibi: right now i really dont like that its different per command
10:35:27 sean-k-mooney as it make it much harder to use
10:35:27 sean-k-mooney as it make it much harder to use
10:36:09 sean-k-mooney that said i know ironic broke the consitency years ago so its not a new thing
10:36:09 sean-k-mooney that said i know ironic broke the consitency years ago so its not a new thing
10:36:10 gibi I think it is the same for each call . max(server,client)
10:36:10 gibi I think it is the same for each call . max(server,client)
10:36:35 sean-k-mooney gibi: not i mean nova and cinder command wont auto negociate
10:36:35 sean-k-mooney gibi: not i mean nova and cinder command wont auto negociate
10:36:41 sean-k-mooney but ironic and plamcent will
10:36:41 sean-k-mooney but ironic and plamcent will
10:36:47 gibi I see
10:36:47 gibi I see
10:37:04 gibi but if the overall osc change is coming the it will be in sync again
10:37:04 gibi but if the overall osc change is coming the it will be in sync again
10:37:26 sean-k-mooney yes if but there was never a cross project agreement to do that as far as i knew
10:37:26 sean-k-mooney yes if but there was never a cross project agreement to do that as far as i knew
10:37:52 sean-k-mooney but if its happeing then i just hope it gets done this cycle
10:37:52 sean-k-mooney but if its happeing then i just hope it gets done this cycle
10:38:07 sean-k-mooney draging it out over multiple cycle will not be a good ux
10:38:07 sean-k-mooney draging it out over multiple cycle will not be a good ux
10:38:39 sean-k-mooney which is why i was expecting this type of change to be a cross project goal
10:38:39 sean-k-mooney which is why i was expecting this type of change to be a cross project goal
10:38:40 gibi OK, then please propose a revert on the osc patch and lets bring it up on cross project levels
10:38:40 gibi OK, then please propose a revert on the osc patch and lets bring it up on cross project levels
10:39:04 stephenfin I don't think this is a serious issue
10:39:04 stephenfin I don't think this is a serious issue
10:39:16 stephenfin If people don't like it, then they'll let us know
10:39:16 stephenfin If people don't like it, then they'll let us know
10:39:18 gibi It seems it is serious for sean-k-mooney
10:39:18 gibi It seems it is serious for sean-k-mooney
10:39:29 stephenfin Otherwise 🤷
10:39:29 stephenfin Otherwise 🤷
10:41:29 jrosser if i put debug=True in [DEFAULT] of nova.conf (for example) should that be sufficient to then be able to see https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_rabbit.py#L608-L610 in the nova-conductor log file?
10:41:29 jrosser if i put debug=True in [DEFAULT] of nova.conf (for example) should that be sufficient to then be able to see https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/_drivers/impl_rabbit.py#L608-L610 in the nova-conductor log file?
10:41:37 sean-k-mooney i just dont want to have to explain in our downstream doc and to customer why openstack server create and openstack resource provider list work differently
10:41:37 sean-k-mooney i just dont want to have to explain in our downstream doc and to customer why openstack server create and openstack resource provider list work differently
10:42:24 sean-k-mooney jrosser: am im not sure i thought that was only for the nova log level
10:42:24 sean-k-mooney jrosser: am im not sure i thought that was only for the nova log level
10:42:36 sean-k-mooney but maybe its everything
10:42:36 sean-k-mooney but maybe its everything
10:43:05 jrosser sean-k-mooney: yeah, i'm not seeing those and am struggling to find how to enable oslo.messaging debug in the context of a nova service
10:43:05 jrosser sean-k-mooney: yeah, i'm not seeing those and am struggling to find how to enable oslo.messaging debug in the context of a nova service
10:44:24 gibi jrosser: I think you need this config https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_log_levels
10:44:24 gibi jrosser: I think you need this config https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.default_log_levels
10:44:46 gibi there the oslo.messaging is set to INFO by default
10:44:46 gibi there the oslo.messaging is set to INFO by default
10:44:51 gibi so you have to change that
10:44:51 gibi so you have to change that
10:45:01 jrosser ah! let me try that
10:45:01 jrosser ah! let me try that
11:18:45 ignaziocassano1 ralonsoh looking at this bug https://bugzilla.redhat.com/show_bug.cgi?id=1917675 seems redhat released patches only for rhel8 ....so Think for centos8
11:18:46 ignaziocassano1 ralonsoh looking at this bug https://bugzilla.redhat.com/show_bug.cgi?id=1917675 seems redhat released patches only for rhel8 ....so Think for centos8
11:18:46 openstack bugzilla.redhat.com bug 1917675 in openstack-nova "Nova evacuate fails due to timeout waiting for a network-vif-plugged event for instance" [Urgent,On_qa] - Assigned to smooney
11:18:46 openstack bugzilla.redhat.com bug 1917675 in openstack-nova "Nova evacuate fails due to timeout waiting for a network-vif-plugged event for instance" [Urgent,On_qa] - Assigned to smooney
11:19:19 ignaziocassano1 I am using centos7
11:19:19 ignaziocassano1 I am using centos7
11:20:02 sean-k-mooney you are using packages from RDO not form Redhat
11:20:02 sean-k-mooney you are using packages from RDO not form Redhat
11:20:31 sean-k-mooney ignaziocassano1: and RDO support train on 7 and 8
11:20:31 sean-k-mooney ignaziocassano1: and RDO support train on 7 and 8
11:21:05 ignaziocassano1 Yes, I wonder if they will be' released on rdo for centos 7
11:21:07 ignaziocassano1 Yes, I wonder if they will be' released on rdo for centos 7
11:21:18 sean-k-mooney the RDO packages and the OSP packages are not the same
11:21:18 sean-k-mooney the RDO packages and the OSP packages are not the same
11:21:35 sean-k-mooney ignaziocassano1: yes still have an automated build for train on centos7 so it should be eventually
11:21:35 sean-k-mooney ignaziocassano1: yes still have an automated build for train on centos7 so it should be eventually
11:21:40 sean-k-mooney if we backport it upstream
11:21:40 sean-k-mooney if we backport it upstream
11:22:39 ignaziocassano1 Patching manually seems do not work
11:22:39 ignaziocassano1 Patching manually seems do not work
11:23:55 ignaziocassano1 Will you backport them on rdo centos 7?
11:23:55 ignaziocassano1 Will you backport them on rdo centos 7?
11:24:45 ignaziocassano1 I would like to migrate on train on centos7 then try to upgrade to centos 8
11:24:45 ignaziocassano1 I would like to migrate on train on centos7 then try to upgrade to centos 8
11:25:33 ignaziocassano1 I think it is a solution for not reinstall all
11:25:33 ignaziocassano1 I think it is a solution for not reinstall all
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)

Earlier   Later