| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2021-04-28 | |||
| 22:00:26 | andrewbogott | "ok now restart your conductor" | |
| 22:00:26 | andrewbogott | "ok now restart your conductor" | |
| 22:00:27 | dansmith | not sure that needs a fix | |
| 22:00:27 | dansmith | not sure that needs a fix | |
| 22:00:56 | andrewbogott | d'you think the conductor would've refreshed its state eventually? | |
| 22:00:56 | andrewbogott | d'you think the conductor would've refreshed its state eventually? | |
| 22:01:17 | clarkb | gmann: fungi mentioned it could possibly be an openstack(client|sdk) regression where it isn't passing that info properly | |
| 22:01:17 | dansmith | no, all the nodes will hold that value in memory until restart, that's kinda the point | |
| 22:01:17 | dansmith | no, all the nodes will hold that value in memory until restart, that's kinda the point | |
| 22:01:17 | clarkb | gmann: fungi mentioned it could possibly be an openstack(client|sdk) regression where it isn't passing that info properly | |
| 22:01:28 | dansmith | API and scheduler will do the same | |
| 22:01:28 | dansmith | API and scheduler will do the same | |
| 22:01:46 | dansmith | it's just that restarting an api worker will resolve it, whereas computes are dependent on the conductors for it | |
| 22:01:46 | dansmith | it's just that restarting an api worker will resolve it, whereas computes are dependent on the conductors for it | |
| 22:03:21 | andrewbogott | It's really the conductor's job to provide /current/ database state though isn't it? | |
| 22:03:21 | andrewbogott | It's really the conductor's job to provide /current/ database state though isn't it? | |
| 22:03:40 | andrewbogott | Are there reasons why we would want the conductor to not re-read for every query? (Other than performance) | |
| 22:03:40 | andrewbogott | Are there reasons why we would want the conductor to not re-read for every query? (Other than performance) | |
| 22:04:16 | dansmith | yeah, it's expensive, and it also controls conductor's RPC pin, which we don't want to shift at runtime unless you restart or HUP it | |
| 22:04:16 | dansmith | yeah, it's expensive, and it also controls conductor's RPC pin, which we don't want to shift at runtime unless you restart or HUP it | |
| 22:05:43 | dansmith | the conductor also translates things according to the version pin and the versions supported by the compute that is asking for a thing | |
| 22:05:43 | dansmith | the conductor also translates things according to the version pin and the versions supported by the compute that is asking for a thing | |
| 22:05:47 | dansmith | it's not just a transparent proxy | |
| 22:05:47 | dansmith | it's not just a transparent proxy | |
| 22:06:00 | andrewbogott | hmmmm | |
| 22:06:00 | andrewbogott | hmmmm | |
| 22:06:49 | andrewbogott | So really it should be pushed -- when a service is deleted it should force some kind of reload (rather than the conductor re-reading the db periodically) | |
| 22:06:49 | andrewbogott | So really it should be pushed -- when a service is deleted it should force some kind of reload (rather than the conductor re-reading the db periodically) | |
| 22:06:59 | andrewbogott | that sounds like a pain to implement for a tiny gain | |
| 22:06:59 | andrewbogott | that sounds like a pain to implement for a tiny gain | |
| 22:07:44 | dansmith | you want to fan-out to every service in the cluster every time a service is deleted just in case some of them need to re-calculate the min version? | |
| 22:07:45 | dansmith | you want to fan-out to every service in the cluster every time a service is deleted just in case some of them need to re-calculate the min version? | |
| 22:07:50 | dansmith | seems like a lot of pain for little gain | |
| 22:07:50 | dansmith | seems like a lot of pain for little gain | |
| 22:07:56 | dansmith | or maybe that's what you meant. | |
| 22:07:56 | dansmith | or maybe that's what you meant. | |
| 22:08:07 | andrewbogott | yeah, a lot of pain | |
| 22:08:07 | andrewbogott | yeah, a lot of pain | |
| 22:09:18 | andrewbogott | So a real bug but not one that's worth fixing | |
| 22:09:18 | andrewbogott | So a real bug but not one that's worth fixing | |
| 22:09:37 | openstackgerrit | Dmitrii Shcherbakov proposed openstack/nova-specs master: Introduce Transport Nodes https://review.opendev.org/c/openstack/nova-specs/+/787458 | |
| 22:10:24 | andrewbogott | dansmith: I need to run -- thanks again for getting me unstuck! | |
| 22:10:24 | andrewbogott | dansmith: I need to run -- thanks again for getting me unstuck! | |
| 22:15:41 | dansmith | yup | |
| 22:15:42 | dansmith | yup | |
| #openstack-nova - 2021-04-29 | |||
| 00:34:11 | brinzhang | gibi, gmann: the nova-grenade-multinode task always failed, is there a bug tracing? | |
| 00:34:11 | brinzhang | gibi, gmann: the nova-grenade-multinode task always failed, is there a bug tracing? | |
| 00:34:59 | brinzhang | https://zuul.opendev.org/t/openstack/builds?job_name=nova-grenade-multinode | |
| 00:34:59 | brinzhang | https://zuul.opendev.org/t/openstack/builds?job_name=nova-grenade-multinode | |
| 00:52:38 | gmann | brinzhang: i see error 'Failed to start rtslib-fb-targetctl.service: Unit rtslib-fb-targetctl.service is not loaded properly: Exec format error.' | |
| 00:52:38 | gmann | brinzhang: i see error 'Failed to start rtslib-fb-targetctl.service: Unit rtslib-fb-targetctl.service is not loaded properly: Exec format error.' | |
| 00:52:47 | gmann | but that is passing sometime | |
| 00:52:47 | gmann | but that is passing sometime | |
| 00:52:51 | gmann | not 100% failure | |
| 00:52:52 | gmann | not 100% failure | |
| 00:53:18 | gmann | clarkb: ^^ are you aware of this error - https://zuul.opendev.org/t/openstack/build/599cfa422a0648168c8b00a27fbd3114/log/logs/grenade.sh.txt#46891-46912 | |
| 00:53:18 | gmann | clarkb: ^^ are you aware of this error - https://zuul.opendev.org/t/openstack/build/599cfa422a0648168c8b00a27fbd3114/log/logs/grenade.sh.txt#46891-46912 | |
| 00:55:33 | gmann | brinzhang: if you see, there are some passing job also on master gate https://zuul.opendev.org/t/openstack/builds?job_name=nova-grenade-multinode | |
| 00:55:33 | gmann | brinzhang: if you see, there are some passing job also on master gate https://zuul.opendev.org/t/openstack/builds?job_name=nova-grenade-multinode | |
| 00:56:05 | gmann | but yes, it is happening more frequently | |
| 00:56:05 | gmann | but yes, it is happening more frequently | |
| 01:18:13 | brinzhang_ | gmann: yes, there are always failed in https://review.opendev.org/c/openstack/nova/+/764292 | |
| 01:18:13 | brinzhang_ | gmann: yes, there are always failed in https://review.opendev.org/c/openstack/nova/+/764292 | |
| 01:21:42 | gmann | brinzhang_: this one https://askubuntu.com/questions/1334619/failed-to-start-rtslib-fb-targetctl-service | |
| 01:21:42 | gmann | brinzhang_: this one https://askubuntu.com/questions/1334619/failed-to-start-rtslib-fb-targetctl-service | |
| 01:26:46 | brinzhang_ | gmann: ok, it seems there is no answer with this question | |
| 01:26:47 | brinzhang_ | gmann: ok, it seems there is no answer with this question | |
| 03:56:39 | openstackgerrit | Xinran WANG proposed openstack/nova-specs master: Repropose smartnic support spec https://review.opendev.org/c/openstack/nova-specs/+/783632 | |
| 05:22:39 | erbarr | hi, is there an issue with configdrive and ussuri? | |
| 05:22:39 | erbarr | hi, is there an issue with configdrive and ussuri? | |
| 07:10:58 | gibi | gmann, brinzhang: https://review.opendev.org/c/openstack/devstack/+/788429 should have fixed the grenade issue | |
| 07:10:58 | gibi | gmann, brinzhang: https://review.opendev.org/c/openstack/devstack/+/788429 should have fixed the grenade issue | |
| 07:11:22 | gibi | gmann, brinzhang: and when this https://review.opendev.org/c/openstack/nova/+/778885 finally lands | |
| 07:11:22 | gibi | gmann, brinzhang: and when this https://review.opendev.org/c/openstack/nova/+/778885 finally lands | |
| 07:11:43 | gibi | we don't need to pin ISCSI_HELPER any more | |
| 07:11:43 | gibi | we don't need to pin ISCSI_HELPER any more | |
| 08:09:21 | brinzhang | gibi: ack | |
| 08:09:21 | brinzhang | gibi: ack | |
| 10:08:12 | openstackgerrit | Lee Yarwood proposed openstack/nova master: zuul: Remove nova-dsvm-multinode-base https://review.opendev.org/c/openstack/nova/+/778908 | |
| 10:08:12 | openstackgerrit | Lee Yarwood proposed openstack/nova master: zuul: Replace grenade and nova-grenade-multinode with grenade-multinode https://review.opendev.org/c/openstack/nova/+/778885 | |
| 10:08:12 | openstackgerrit | Lee Yarwood proposed openstack/nova master: zuul: Remove nova-dsvm-multinode-base https://review.opendev.org/c/openstack/nova/+/778908 | |
| 10:08:12 | openstackgerrit | Lee Yarwood proposed openstack/nova master: zuul: Replace grenade and nova-grenade-multinode with grenade-multinode https://review.opendev.org/c/openstack/nova/+/778885 | |
| 10:08:55 | lyarwood | gibi: ^ that series was still using the older detach flow and seeing errors, I've rebased to pickup your new code and hopefully that should allow it to pass | |
| 10:08:56 | lyarwood | gibi: ^ that series was still using the older detach flow and seeing errors, I've rebased to pickup your new code and hopefully that should allow it to pass | |
| 10:09:37 | gibi | hm, I thought zuul rebases the patches | |
| 10:09:37 | gibi | hm, I thought zuul rebases the patches | |
| 10:09:52 | gibi | before running the tests | |
| 10:09:52 | gibi | before running the tests | |
| 10:10:24 | gibi | anyhow I +Ad them | |
| 10:10:24 | gibi | anyhow I +Ad them | |
| 10:13:25 | sean-k-mooney | gibi: zuul merges the patch with the head of master and if you use depends on in the same repor it merged with that too | |
| 10:13:25 | sean-k-mooney | gibi: zuul merges the patch with the head of master and if you use depends on in the same repor it merged with that too | |
| 10:13:37 | sean-k-mooney | gibi: so not a rebase but similar | |
| 10:13:37 | sean-k-mooney | gibi: so not a rebase but similar | |
| 10:13:46 | gibi | then it should have picked up my detach fixes | |
| 10:13:46 | gibi | then it should have picked up my detach fixes | |
| 10:14:12 | lyarwood | AFAICT it didn't | |
| 10:14:13 | lyarwood | AFAICT it didn't | |
| 10:14:20 | lyarwood | this is just in the check queue btw | |
| 10:14:20 | lyarwood | this is just in the check queue btw | |