Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-04-29
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: 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:12 openstackgerrit Lee Yarwood proposed openstack/nova master: zuul: Remove nova-dsvm-multinode-base https://review.opendev.org/c/openstack/nova/+/778908
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
10:14:27 lyarwood it didn't make it to the gate this run
10:14:27 lyarwood it didn't make it to the gate this run
10:14:31 sean-k-mooney yep check should do the same
10:14:31 sean-k-mooney yep check should do the same
10:14:48 sean-k-mooney it will speculetlivly merge and then run on the result
10:14:48 sean-k-mooney it will speculetlivly merge and then run on the result
10:15:15 sean-k-mooney its why sometimes test pass locally and fail in the gate
10:15:16 sean-k-mooney its why sometimes test pass locally and fail in the gate
10:15:33 sean-k-mooney and you have to do a local rebase to see the isssues locally
10:15:34 sean-k-mooney and you have to do a local rebase to see the isssues locally
10:16:02 sean-k-mooney could it have just been a timing thing?
10:16:02 sean-k-mooney could it have just been a timing thing?
10:16:23 sean-k-mooney check jobs dont restart if something merges
10:16:24 sean-k-mooney check jobs dont restart if something merges
10:16:24 lyarwood https://zuul.opendev.org/t/openstack/build/02d0c22ca9334a1094782df2f9570c35/log/compute1/logs/screen-n-cpu.txt and req-d017e833-5df2-4c5e-b348-f2625a2a608d is the old flow as it's using loopingcall
10:16:25 lyarwood https://zuul.opendev.org/t/openstack/build/02d0c22ca9334a1094782df2f9570c35/log/compute1/logs/screen-n-cpu.txt and req-d017e833-5df2-4c5e-b348-f2625a2a608d is the old flow as it's using loopingcall
10:16:26 sean-k-mooney unlike gate
10:16:26 sean-k-mooney unlike gate
10:17:40 gibi * gibi clicks
10:18:08 gibi yepp the logs are from the old code
10:18:08 gibi yepp the logs are from the old code
10:18:19 lyarwood anyway it's rebased now
10:18:19 lyarwood anyway it's rebased now
10:18:21 lyarwood so hopefully
10:18:21 lyarwood so hopefully
10:18:37 gibi fingers crossed
10:18:37 gibi fingers crossed
10:19:18 gibi lyarwood: it is a grenade run, so I guess before the upgrade it have to run the old code from Wallaby
10:19:18 gibi lyarwood: it is a grenade run, so I guess before the upgrade it have to run the old code from Wallaby
10:19:34 lyarwood aaaaaaaah
10:19:34 lyarwood aaaaaaaah
10:19:37 lyarwood right
10:19:37 lyarwood right
10:19:42 lyarwood I didn't even think
10:19:42 lyarwood I didn't even think
10:19:55 lyarwood so is this still v to w?
10:19:55 lyarwood so is this still v to w?
10:20:05 gibi I think it is w to master
10:20:05 gibi I think it is w to master
10:20:13 gibi but we only merged the fix to master
10:20:13 gibi but we only merged the fix to master
10:20:19 sean-k-mooney oh ya
10:20:19 sean-k-mooney oh ya
10:20:58 lyarwood we did talk about backporting your change to wallaby
10:20:59 lyarwood we did talk about backporting your change to wallaby
10:21:08 sean-k-mooney well grenade shoudl be wallaby to xena
10:21:08 sean-k-mooney well grenade shoudl be wallaby to xena
10:21:15 lyarwood * lyarwood needs to jump on a call brb
10:21:36 lyarwood sean-k-mooney: yeah I think this is the live migration test between the two
10:21:36 lyarwood sean-k-mooney: yeah I think this is the live migration test between the two
10:21:40 lyarwood sean-k-mooney: with the compute still on w
10:21:40 lyarwood sean-k-mooney: with the compute still on w
10:22:59 sean-k-mooney back porting the change for libvirt events to wallaby would be nice form a downstrem perspecitve too
10:23:00 sean-k-mooney back porting the change for libvirt events to wallaby would be nice form a downstrem perspecitve too
10:23:53 sean-k-mooney we talked about trying that downstream but while i like the idea of doing that i was not personally sure we wanted to diverge form upstream in this case
10:23:53 sean-k-mooney we talked about trying that downstream but while i like the idea of doing that i was not personally sure we wanted to diverge form upstream in this case
10:24:56 gibi lyarwood: the delta between w and current master should be small, so I can fire up the cherry-picks
10:24:56 gibi lyarwood: the delta between w and current master should be small, so I can fire up the cherry-picks
10:29:46 gibi ahh there are already merge conflicts :/
10:29:47 gibi ahh there are already merge conflicts :/
10:36:13 lyarwood yeah that might be my fault sorry
10:36:13 lyarwood yeah that might be my fault sorry
10:36:32 lyarwood actually yeah it is
10:36:33 lyarwood actually yeah it is
10:36:51 lyarwood sean-k-mooney: yeah I did bring it up upstream as well as it's also a bugfix IMHO
10:36:52 lyarwood sean-k-mooney: yeah I did bring it up upstream as well as it's also a bugfix IMHO
10:37:52 gibi it is nobody's fault, we needed those fixes

Earlier   Later