| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-05-17 | |||
| 16:21:22 | bauzas | point is, we should only care of os-vif and client releases for placement and nova, that's it | |
| 16:21:40 | bauzas | (for zed-1 I mean) | |
| 16:21:58 | sean-k-mooney | yep | |
| 16:23:06 | bauzas | gmann: btw. this is not going well for https://review.opendev.org/c/openstack/os-vif/+/840020 | |
| 16:23:15 | bauzas | but let's discuss this on open discussion ^ | |
| 16:23:26 | bauzas | and let's continue the agenda | |
| 16:23:35 | bauzas | #topic Review priorities | |
| 16:23:40 | bauzas | #link https://review.opendev.org/q/status:open+(project:openstack/nova+OR+project:openstack/placement+OR+project:openstack/os-traits+OR+project:openstack/os-resource-classes+OR+project:openstack/os-vif+OR+project:openstack/python-novaclient+OR+project:openstack/osc-placement)+label:Review-Priority%252B1 | |
| 16:23:59 | bauzas | #link https://review.opendev.org/c/openstack/project-config/+/837595 Gerrit policy for Review-prio contributors flag. Naming bikeshed in there. | |
| 16:24:08 | bauzas | reviews are welcome on ^ | |
| 16:24:21 | bauzas | I see gibi having concerns on the naming | |
| 16:24:49 | gibi | I have no good suggestion | |
| 16:24:53 | gibi | so feel free to ignore me | |
| 16:27:03 | gibi | my problem on the current naming is that is sounds like a core approves that something is a prioirty | |
| 16:27:19 | gibi | but the aim is instead that the core says "I will review this" | |
| 16:27:33 | bauzas | gibi: I can propose something else | |
| 16:27:39 | bauzas | to unblock the patch | |
| 16:27:52 | bauzas | #link https://docs.openstack.org/nova/latest/contributor/process.html#what-the-review-priority-label-in-gerrit-are-use-for Documentation we already have | |
| 16:27:55 | sean-k-mooney | bauzas: sure go for it | |
| 16:28:24 | bauzas | next topic, | |
| 16:28:34 | bauzas | #topic Stable Branches | |
| 16:28:41 | bauzas | elodilles: I haven't seen you updating the section | |
| 16:28:45 | bauzas | so far, so good ? | |
| 16:29:06 | elodilles | #info ussuri and older branches are still blocked, newer branches should be OK | |
| 16:29:32 | bauzas | I think we said last week, newer branches *are* OK :) | |
| 16:29:35 | elodilles | i haven't got any further with the investigation of ussuri branch :/ | |
| 16:30:10 | elodilles | bauzas: yes, unfortunately nothing news :( | |
| 16:30:15 | bauzas | damn, looks like we have a netsplit at the time of the meeting | |
| 16:30:27 | elodilles | yepp, it seems :S | |
| 16:30:35 | sean-k-mooney | people will be back soon proably | |
| 16:30:55 | bauzas | hopefully yes | |
| 16:31:01 | bauzas | let's continue then | |
| 16:31:01 | sean-k-mooney | looks like mainly NA folks | |
| 16:31:24 | bauzas | sean-k-mooney: yeah, one OFTC server seems to have killed the conns | |
| 16:31:34 | elodilles | nothing more to add for now :X | |
| 16:31:55 | bauzas | elodilles: at one time, we'll need to cut the rope on the older branches | |
| 16:32:38 | elodilles | bauzas: indeed. now ussuri is in bad shape for weeks now... | |
| 16:32:38 | sean-k-mooney | older starting form ? | |
| 16:32:50 | sean-k-mooney | hum | |
| 16:32:52 | bauzas | sean-k-mooney: ussuri | |
| 16:33:00 | sean-k-mooney | so we woudl be droping train and below too | |
| 16:33:23 | elodilles | actually it fails due to multiple intermittent failures | |
| 16:33:27 | bauzas | we need help or some action in order to mitigate the blocker | |
| 16:33:42 | bauzas | elodilles: yup, constant rechecks | |
| 16:33:45 | sean-k-mooney | bauzas: what is the blocker exactly | |
| 16:34:01 | bauzas | the failure ratio is so high it becomes unpractical to merge | |
| 16:34:15 | sean-k-mooney | right but on what issue | |
| 16:34:22 | bauzas | a couple of them | |
| 16:34:29 | bauzas | elodilles: we tracked them, right | |
| 16:34:46 | sean-k-mooney | ok i was wonderign if there was one we shoudl look at specificly | |
| 16:34:57 | elodilles | sean-k-mooney: guest kernel panics, volume timeouts, | |
| 16:35:12 | sean-k-mooney | as in volume detach | |
| 16:35:19 | sean-k-mooney | is it resize related? | |
| 16:35:44 | sean-k-mooney | becasue we noticed today that reize is not suing hte sshable change yet | |
| 16:35:56 | sean-k-mooney | gibi proposed a patch to cover that | |
| 16:36:08 | elodilles | also this bug comes up often: https://bugs.launchpad.net/nova/+bug/1901739 | |
| 16:36:40 | sean-k-mooney | im not familar with that | |
| 16:37:22 | sean-k-mooney | looks like lee fixed that in V but it has not been backported | |
| 16:37:52 | gibi | it is a mix of fixes already due to zuul migration and ubuntu version cahgne | |
| 16:37:55 | gibi | chnage | |
| 16:37:56 | sean-k-mooney | ok we can proably move on but if you have a list elodilles please share | |
| 16:38:48 | elodilles | sean-k-mooney: well it's on the recheck list on this patch: https://review.opendev.org/c/openstack/nova/+/838033 | |
| 16:38:51 | elodilles | :/ | |
| 16:39:28 | sean-k-mooney | can we ask infra to force merge that | |
| 16:39:57 | elodilles | sean-k-mooney: it won't help to other patches, they will need the same rechecks | |
| 16:40:17 | sean-k-mooney | yes i know | |
| 16:40:35 | bauzas | in general, we can try to release the jobs | |
| 16:40:50 | bauzas | in order to merge one specific patch we want | |
| 16:41:05 | gmann | +1, better than force merge | |
| 16:41:05 | elodilles | yes, one way is to decrease the test coverage | |
| 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 | bauzas | but I still remember the magic formula | |
| 16:41:53 | elodilles | gibi: or some volume related tests. though i don't know which is worse :S | |
| 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 | |