| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2023-05-23 | |||
| 16:19:27 | bauzas | possibly | |
| 16:19:43 | bauzas | I just saw the blip, not the whole Thanos universe clap | |
| 16:21:01 | opendevreview | Merged openstack/nova stable/wallaby: fup: Print message logging uncaught nova-manage exceptions https://review.opendev.org/c/openstack/nova/+/877334 | |
| 16:21:39 | bauzas | doh, can't query https://zuul.openstack.org/builds?skip=0 with job=centos | |
| 16:21:49 | bauzas | and I don't know if it supports regexs | |
| 16:22:46 | bauzas | anyway | |
| 16:22:59 | bauzas | my Zuul query foo is rusty, so moving on | |
| 16:23:15 | bauzas | and I'll lurk #openstack-qa meanwhile | |
| 16:23:26 | bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | |
| 16:23:30 | bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | |
| 16:23:35 | bauzas | that's it for gate | |
| 16:23:40 | bauzas | #topic Release Planning | |
| 16:23:43 | bauzas | #link https://releases.openstack.org/bobcat/schedule.html | |
| 16:23:47 | bauzas | #info Nova deadlines are set in the above schedule | |
| 16:23:54 | bauzas | worth saying now : | |
| 16:23:58 | bauzas | #info Nova spec review day in two weeks | |
| 16:24:03 | bauzas | you're all noticed | |
| 16:24:29 | bauzas | take your pens and your paper, and write your best poetry | |
| 16:25:16 | bauzas | spec freeze will only be on the first week of July | |
| 16:25:32 | bauzas | noted ? | |
| 16:26:06 | bauzas | so, | |
| 16:26:15 | bauzas | #topic pPTG Planning | |
| 16:26:26 | gibi | pPTG? | |
| 16:26:33 | gibi | physical? partial? | |
| 16:26:33 | bauzas | I will be quick, I have two questions, one related to the other | |
| 16:26:44 | bauzas | gibi: hah, both :p | |
| 16:26:49 | gibi | ppPTG | |
| 16:26:59 | bauzas | Who will be at the pPTG in Vancouver ? | |
| 16:27:03 | bauzas | and related, | |
| 16:27:08 | bauzas | #link https://ptg.opendev.org/ptg.html Should we book some table for the PTG ? | |
| 16:27:35 | bauzas | I've got one email from the Foundation asking to whether I would want to book a table | |
| 16:27:43 | bauzas | and honestly, I don't know what to do | |
| 16:27:56 | bauzas | the Forum will compete with the PTG | |
| 16:28:05 | gibi | book a table, then might be unused | |
| 16:28:37 | bauzas | the whole 2 days ? works for me | |
| 16:28:54 | bauzas | at least I'd have a spot to sit down | |
| 16:29:00 | gibi | :) | |
| 16:29:22 | gibi | I think that is the exact reason to publish where to find the PTL | |
| 16:29:47 | bauzas | that's a bit premature but I should start to gather information about topics that people wanna bring at the PTG and who could be present | |
| 16:30:26 | bauzas | and if some people that are NOT at the PTG wanna chime on such topics, that would give us some insight too | |
| 16:30:54 | bauzas | #action bauzas to prepare a PTG etherpad for calling about topics and attendace | |
| 16:31:13 | bauzas | that's it, I wanted to keep it short | |
| 16:31:21 | bauzas | #topic Review priorities | |
| 16:31:26 | 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+OR+label:Review-Priority%252B2) | |
| 16:31:30 | bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | |
| 16:32:06 | bauzas | #topic Stable Branches | |
| 16:32:10 | bauzas | elodilles: your turn ! | |
| 16:32:14 | elodilles | o/ | |
| 16:32:16 | elodilles | #info stable nova release patches merged on Wednesday: 2023.1 Antelope (27.1.0), Zed (26.2.0), Yoga (25.2.0) | |
| 16:32:22 | bauzas | huzzah | |
| 16:32:26 | elodilles | so these have been released ^^^ \o/ | |
| 16:32:38 | elodilles | #info stable/wallaby is unblocked as gmann's nova-ceph-multistore job fix has merged (thanks!) -- https://review.opendev.org/871920 | |
| 16:32:54 | bauzas | those include the CVE 2023-2088 fixes, I'm happy to have them now :) | |
| 16:33:07 | elodilles | bauzas: yepp | |
| 16:33:12 | bauzas | huzzah again | |
| 16:33:19 | elodilles | :] | |
| 16:33:19 | bauzas | about the ceph-multistore problem | |
| 16:33:32 | elodilles | yepp-yepp | |
| 16:33:36 | elodilles | #info stable/train is blocked by failing openstacksdk-functional-devstack job | |
| 16:33:42 | bauzas | doh | |
| 16:33:54 | elodilles | this is probably because of heat's stable/train eol | |
| 16:34:18 | elodilles | i'm looking at multiple ways of possibilities to unblock the gate | |
| 16:34:33 | elodilles | will see which is the best / working :P | |
| 16:34:47 | elodilles | and the general info: | |
| 16:34:53 | elodilles | #info stable branch status / gate failures tracking etherpad: https://etherpad.opendev.org/p/nova-stable-branch-ci | |
| 16:35:01 | elodilles | EOM | |
| 16:35:41 | bauzas | about Train, given some parts of the universe started to EOL it | |
| 16:35:51 | bauzas | then, my question is, should we copy them ? | |
| 16:36:05 | elodilles | heat EOL'd their ussuri as well | |
| 16:36:08 | bauzas | I know that my paycheck comes partly from Train, but that's still a question to me | |
| 16:36:33 | elodilles | bauzas: i still say that until we can merge patches (hehh) we can keep it open o:) | |
| 16:37:42 | bauzas | stable/train also doesn't include the previous CVE fix you know ;) | |
| 16:38:08 | elodilles | hmmm, i forgot that | |
| 16:38:23 | elodilles | though there are some who still wanted rocky to accept patches ;) | |
| 16:38:48 | bauzas | I'm not only talking of the brick CVE | |
| 16:38:57 | bauzas | I'm also taking of the VMDK CVE | |
| 16:39:24 | bauzas | if people want to risk their lifes, I'm OK | |
| 16:39:37 | elodilles | good point | |
| 16:39:44 | bauzas | but that is still two serious security flaws that haven't been fixed | |
| 16:39:45 | elodilles | i cannot ague with that | |
| 16:39:57 | sean-k-mooney | i would may keep it alive for a few more months and ask operators at the summit | |
| 16:40:15 | sean-k-mooney | but i could see use retiring it after bobcat in either case | |
| 16:40:30 | dansmith | I'm fine (and prefer) to keep branches available, but if we're maintaining part of it but not backporting critical CVEs it really sends a mixed message | |
| 16:40:45 | bauzas | dansmith: that's my whole point | |
| 16:40:46 | dansmith | mixed and confusing I would say | |
| 16:40:57 | elodilles | dansmith: true | |
| 16:41:57 | sean-k-mooney | the vmdk cve however makes me more inclided to say we should be keeping train | |
| 16:41:59 | bauzas | dansmith: we can't reasonably say we're open to keep a branch open and accept backports if the most critical ones aren't done | |
| 16:42:35 | sean-k-mooney | we fixed it downstream in our train based product but it causes a lot fo pain because it had a bug that would have been caught if we fixed it upstream instead | |
| 16:42:40 | dansmith | bauzas: I just like the branches to be open over tags personally, but if people see "last commit X days ago" they're likely to assume that some of those commits are critical fixes | |
| 16:42:42 | bauzas | sean-k-mooney: train doesn't include the vmdk fix | |
| 16:42:48 | sean-k-mooney | i know | |
| 16:42:55 | bauzas | ah, missed your poiint | |
| 16:43:18 | bauzas | sean-k-mooney: truly, we missed something downstream because we lacked some upstream backport | |
| 16:43:23 | sean-k-mooney | if we had fixed the cve via the upstream backport process it would have caught the missing patch we had downstream | |
| 16:43:57 | bauzas | but the upstream branch isn't really arguably in a good shape if the two most major CVEs that I know since a decade aren't fixed | |
| 16:44:11 | sean-k-mooney | well they could be fixed | |
| 16:44:26 | sean-k-mooney | we just dont have peopel volentering to fix it | |
| 16:44:32 | bauzas | sean-k-mooney: true, and this hadn't been done because of the way we manage our dependencies upstream is tough | |
| 16:44:50 | dansmith | right the point is that we're not meant to be maintaining these.. so we either need to do it, or stop *signaling* that we're doing it | |