Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2023-05-23
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
16:45:05 bauzas +1
16:45:06 sean-k-mooney yep
16:45:30 bauzas the brick CVE isn't AFAIK proposed against train now
16:45:31 dansmith so I guess I'll say I'm +1 for EOLing train
16:46:08 bauzas so, honestly, if we want to keep train, let's do the efforts to backport both CVE fixes to train
16:46:13 dansmith are we even sync/importing from train downstream anymore?
16:46:21 bauzas don't look at me, I'm not rushing to do it
16:46:35 sean-k-mooney we are
16:46:51 sean-k-mooney but our last release that will do that is planed for q3
16:47:00 sean-k-mooney so after bobcat is release we wont be
16:47:09 bauzas don't speak redhat greek in this channel please :)
16:47:49 sean-k-mooney well the point being that we will stop consuming form the stable branch anyway in the next few months
16:47:56 dansmith right
16:47:56 sean-k-mooney for our downstream uses
16:48:24 bauzas yeah, but we still don't provide the CVE fixes to it ? :)
16:48:53 sean-k-mooney you know i orgianly wanted use to fix both of those on upstream train right
16:49:08 dansmith sean-k-mooney: so then why didn't you?
16:49:33 sean-k-mooney i asked the peopel that did the backprot to do it
16:49:35 bauzas we all have priorities and I don't blame anyone
16:50:03 bauzas particularly me, since I was owning the backports for the VMDK one and I intentionally skipped the train one
16:50:35 bauzas because it would have required some oslo.utils release number belly dance
16:51:16 bauzas and as a reminder, Extended Maintenance is clear on its intents
16:51:26 dansmith bauzas: exactly
16:51:31 bauzas https://docs.openstack.org/project-team-guide/stable-branches.html#extended-maintenance
16:52:40 bauzas anyway, seems we won't reach a consensus, but I can propose to send an email to openstack-discuss
16:52:52 bauzas we'll see if people argue
16:53:57 bauzas #action bauzas to send an email to -discuss to gauge the freakiness of EOLing stable/train now
16:54:33 bauzas I guess we're done with this hot topic
16:54:54 bauzas #topic Open Discussion
16:54:58 bauzas nothing on the agenda
16:55:16 bauzas is anyone having a thought to share with the team ?
16:56:47 bauzas looks not
16:56:55 bauzas sorry this week I won't save too much of your time
16:56:59 bauzas thanks all
16:57:03 bauzas #endmeeting
16:57:03 opendevmeet Meeting ended Tue May 23 16:57:03 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:57:03 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-23-16.01.html
16:57:03 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-23-16.01.txt
16:57:03 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-05-23-16.01.log.html
16:58:04 gibi thanks
16:58:20 elodilles thanks o/
16:59:35 Uggla_ thx
#openstack-nova - 2023-05-24
14:59:01 opendevreview Merged openstack/nova stable/yoga: Ironic: retry when node not available https://review.opendev.org/c/openstack/nova/+/868010
17:56:02 melwitt dansmith: fyi this is a fix for our subclass signature checker test that detects when volume drivers are not matching the base class https://review.opendev.org/c/openstack/nova/+/883217 I found it wasn't working when I was working on the cve stuff. it would have caught the issue with the wallaby patch
17:57:24 dansmith melwitt: cool
18:21:52 sean-k-mooney melwitt: i didnt know that was a thing
18:22:30 sean-k-mooney i feel like there are proably better ways to detech that if we use mypy
18:22:34 sean-k-mooney to do type checking now
18:23:24 sean-k-mooney with that said im ok with fixing this as is
18:23:39 sean-k-mooney we can likel just do it better with newer tools now
18:37:00 melwitt sean-k-mooney: yeah it was new-ish to me too as I hadn't dug into the volume drivers too much before
18:37:43 melwitt and yeah maybe there's a better way to do it now. the fix was pretty easy tho
18:40:12 sean-k-mooney i havent looked into mypy too much but i think we caoudl annotation the base calses and have it detech if the signirues did not match
18:40:24 sean-k-mooney but that would be a large change anyway
18:40:54 sean-k-mooney espcially since we woudl ahve to enable mypi typeing for the entire file
18:49:30 dansmith please no
18:51:38 sean-k-mooney in the cld classes i think you jsut have to put @overload in the metods so its not that bad
18:51:46 sean-k-mooney but its more work then we need
18:52:20 sean-k-mooney if you declar it an overlaod/override and the signiture does not match it treats it as an error
18:52:38 dansmith do you mean abc?
18:53:01 sean-k-mooney basicaly ya
18:53:13 sean-k-mooney that was how it sued to be done
18:53:29 dansmith yeah, that's the better way, especially for things like this
18:53:31 sean-k-mooney it might still be the way its currently doen
18:54:01 sean-k-mooney i was looking at https://mypy.readthedocs.io/en/stable/class_basics.html#abstract-base-classes-and-multiple-inheritance vs https://mypy.readthedocs.io/en/stable/final_attrs.html#final-methods
18:54:22 sean-k-mooney well https://mypy.readthedocs.io/en/stable/error_code_list.html?highlight=overload#check-calls-to-overloaded-functions-call-overload
18:56:27 sean-k-mooney so there is some checking for overrides in bases https://mypy.readthedocs.io/en/stable/error_code_list.html?highlight=overload#check-validity-of-overrides-override but abstractg base classes is clearer
18:56:41 sean-k-mooney i think the automtaic checking only applies if the types dont match
18:57:00 sean-k-mooney anyway o/
19:05:36 gouthamr o/ dansmith: do you have logs of a multinode job that ran with changes here: https://review.opendev.org/c/openstack/devstack-plugin-ceph/+/882483
19:06:40 dansmith gouthamr: meaning other than the ones linked there?
19:06:50 dansmith oh no, right,
19:06:57 dansmith it wasn't running the multinode job
19:07:47 dansmith gouthamr: but no, that was just me trying to sync up that job definition, I didn't get into any actual diagnosis of if the job was working
19:07:58 gouthamr ah thanks
19:08:40 gouthamr saw your comment: "There are errors from one of the nova computes that indicate that it's not getting access to the ceph cluster properly, which means there is more work to do here."

Earlier   Later