| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-17 | |||
| 16:40:50 | bauzas | in order to merge one specific patch we want | |
| 16:41:05 | elodilles | yes, one way is to decrease the test coverage | |
| 16:41:05 | gmann | +1, better than force merge | |
| 16:41:06 | bauzas | we did that in some past | |
| 16:41:19 | sean-k-mooney | ok | |
| 16:41:26 | gibi | here that would mean to cut out devstack based jobs | |
| 16:41:29 | sean-k-mooney | we can make some non voting for now | |
| 16:41:35 | gibi | an rely on unit and functional | |
| 16:41:43 | gibi | *and | |
| 16:41:45 | bauzas | this was ages ago | |
| 16:41:47 | gmann | yeah just for temporary time | |
| 16:41:53 | elodilles | gibi: or some volume related tests. though i don't know which is worse :S | |
| 16:41:53 | bauzas | but I still remember the magic formula | |
| 16:42:22 | gibi | gmann: it would not be temporary if we disable jobs we will never fix tem | |
| 16:42:25 | gibi | them | |
| 16:42:34 | sean-k-mooney | well i asusme we have a limited set of patches that we want to merge and we woudl turn these abck on like droping lc jobs | |
| 16:42:54 | sean-k-mooney | so i was epecting disable patch then revert | |
| 16:43:02 | bauzas | gibi: the idea is to relax the jobs before merging patches we want and then enabling again the jobs | |
| 16:43:19 | gibi | bauzas: and will we do it for every patch we want to merge? | |
| 16:43:21 | bauzas | and see whether the failure ratio drops again | |
| 16:43:23 | gmann | yeah that is what I thought, enabling them again | |
| 16:43:40 | gibi | bauzas: it would work iff we would have patches in queue that fixes those breaks but we dont | |
| 16:43:48 | bauzas | gibi: no, we need to identify a set of patches we'd like to merge in order to help with CI stability | |
| 16:44:01 | gibi | we don't have the fixes :/ | |
| 16:44:33 | gibi | it is not like merge these 5 patches to stabilize ussuri, we don't have those 5 patches ready | |
| 16:44:50 | gibi | we have random patches backported and waiting | |
| 16:44:51 | gmann | humm | |
| 16:45:25 | bauzas | ok, we won't obviously solve this problem by now | |
| 16:45:33 | gmann | one thing to note if we are removing integration tests coverage then it is better to make branch EOL like we did for ocata | |
| 16:45:38 | gibi | so something like: 1) collect the issue to be fixed in ussurit to stabilize CI 2) create fixes for them 3) force merge them 4) profit | |
| 16:45:39 | bauzas | let's state we all know about this problem and we'll figure out the solutions later | |
| 16:45:58 | bauzas | gibi: yeah, sounds 1/ and 2/ are not done yet | |
| 16:45:59 | elodilles | maybe if that "SSHABLE" fix helps things in ussuri we have one, but still we probably have other failures | |
| 16:46:30 | gibi | elodilles: a buncs of SSHABLE already landed, so we should see them help | |
| 16:46:38 | gmann | elodilles: that is again difficult as we are not supposed to use tempest master for ussuri so not all master change will go for ussuri testing | |
| 16:46:43 | bauzas | elodilles: ideally an etherpad of doom may help gathering ideas and feedback | |
| 16:46:48 | gibi | gmann: ahh | |
| 16:46:50 | gibi | that explains | |
| 16:46:55 | gmann | I have patch up to cap tempest for ussuri but that is not merged yet | |
| 16:46:58 | sean-k-mooney | gmann: wait we are not? | |
| 16:47:08 | sean-k-mooney | gmann: temest is ment to be branchless upstream | |
| 16:47:13 | gmann | but we have stopped ussuri support in tempest master | |
| 16:47:31 | sean-k-mooney | hum | |
| 16:47:37 | sean-k-mooney | because of what reason? | |
| 16:47:41 | gmann | sean-k-mooney: yes and master tempest is for SUpported branch and we cannot support EM branches | |
| 16:47:42 | sean-k-mooney | python version ? | |
| 16:48:04 | sean-k-mooney | shoudl that not be a project choice | |
| 16:48:16 | gmann | EM branches - #link https://docs.openstack.org/tempest/latest/stable_branch_support_policy.html | |
| 16:48:17 | sean-k-mooney | tempest should not have to support it | |
| 16:48:42 | sean-k-mooney | but project that support em branches shoudl still be able to choose which tempest to run | |
| 16:48:46 | gmann | sean-k-mooney: we have to pin tempest for EM branch so that using master there can break them anytime | |
| 16:49:06 | gmann | sean-k-mooney: yeah, you can but no guarantee if master tempest will work | |
| 16:49:19 | gmann | as long as it is passing it is ok to use | |
| 16:49:58 | sean-k-mooney | ack | |
| 16:50:12 | sean-k-mooney | so i think i would prefer to keep tempest uncapped until ti breaks | |
| 16:50:14 | elodilles | (well, i guess changes on tempest master can affect not only EM branches, but they are affected most likely) | |
| 16:50:30 | sean-k-mooney | elodilles: well nova uses microversion | |
| 16:50:40 | sean-k-mooney | so it should work form our point of view | |
| 16:50:53 | gmann | elodilles: for supported branches we make sure tempest does not break them but for EM it is not the case | |
| 16:50:57 | sean-k-mooney | chagnes to tempest should not break our stable branches expcti if there ar package dep issues | |
| 16:51:14 | gmann | plan is : by default devstack will cap the tempest in ussuri and project can override it in jobs | |
| 16:51:15 | bauzas | I need to timestop the conversation | |
| 16:51:15 | sean-k-mooney | which i guess is why this was done | |
| 16:51:41 | gmann | yeah, we can discuss it in qa or nova channel after meeting | |
| 16:51:49 | sean-k-mooney | +1 | |
| 16:51:51 | elodilles | +1 | |
| 16:51:52 | bauzas | gmann: sean-k-mooney: gibi: you're all free to continue the conversation after the meeting | |
| 16:51:57 | bauzas | cool | |
| 16:51:57 | gmann | sure | |
| 16:52:01 | bauzas | moving on quickly | |
| 16:52:08 | bauzas | #topic Open discussion | |
| 16:52:21 | bauzas | Uggla: do you want to discuss https://bugs.launchpad.net/nova/+bug/1959186 | |
| 16:52:22 | bauzas | ? | |
| 16:52:44 | bauzas | Uggla: you left this bug with comments on your triage etherpad | |
| 16:52:53 | Uggla | yep | |
| 16:53:18 | Uggla | It appears valid to me, but I would like a crosscheck. | |
| 16:53:26 | sean-k-mooney | i dont think it is | |
| 16:54:02 | sean-k-mooney | there is a long runnign knwon issue that you cant delete in use image form glance if it uses ceph | |
| 16:54:15 | sean-k-mooney | that only happens if you use raw images | |
| 16:54:27 | sean-k-mooney | at that enabel our copy on write shallow clone code path | |
| 16:54:34 | bauzas | sounds at least unrelated to nova | |
| 16:54:42 | sean-k-mooney | which i suspect is what is happening here with the snapshot | |
| 16:54:45 | bauzas | maybe valid but not on our side | |
| 16:54:52 | bauzas | right? | |
| 16:55:21 | dansmith_ | it's really desired behavior even | |
| 16:55:27 | sean-k-mooney | there have been some feature request in this area | |
| 16:55:39 | sean-k-mooney | some peopel woudl like too break the shallow copy | |
| 16:55:44 | dansmith_ | I think it'd be a feature on the glance side, IIRC | |
| 16:56:08 | sean-k-mooney | ya so they have not providded enough info in the bug | |
| 16:56:12 | sean-k-mooney | we do not know the image type | |
| 16:56:21 | dansmith | nova doesn't even know about the linkage after it's created right? so if the link is broken, nova is fine with it | |
| 16:56:21 | sean-k-mooney | to confirm wone way or another | |
| 16:56:39 | sean-k-mooney | am im not sure | |
| 16:57:00 | bauzas | dansmith: hence my point, unrelated to the project | |
| 16:57:04 | bauzas | => Opinion | |
| 16:57:14 | levy14 | have a feature proposal, but not in the agenda yet. may I ask here and gauge interest/feasibility? | |
| 16:57:15 | dansmith | bauzas: yeah | |
| 16:57:24 | sean-k-mooney | there is some metadata on teh image but i dont know if we read that when we create the new vm | |
| 16:57:29 | sean-k-mooney | or tack it on our side | |
| 16:57:43 | bauzas | sean-k-mooney: we can add glance as a service project in the bug report | |