| *** elodilles_pto is now known as elodilles | 07:24 | |
| opendevreview | Konrad Gube proposed openstack/nova-specs master: Re-propose using extend volume completion action for 2023.2 https://review.opendev.org/c/openstack/nova-specs/+/877233 | 08:07 |
|---|---|---|
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix trivial doc issues https://review.opendev.org/c/openstack/nova/+/878779 | 10:05 |
| opendevreview | Rajesh Tailor proposed openstack/nova master: Fix trivial doc issues https://review.opendev.org/c/openstack/nova/+/878779 | 12:03 |
| gibi | bauzas: sean-k-mooney: dansmith: gmann: here is my take on the limited lower constraint job https://review.opendev.org/q/topic:limited-lower-constraints-jobs it already can catch the issue I want to catch (see the example DNM patches) | 12:50 |
| gibi | https://review.opendev.org/q/topic:limited-lower-constraints-jobs | 12:50 |
| bauzas | gibi: ack, will look | 12:51 |
| sean-k-mooney | gibi: is there a reason you are stating which packages to restrict | 12:52 |
| sean-k-mooney | gibi: instead of everything in requirements.txt | 12:52 |
| gibi | sean-k-mooney: yes, I wanted to limit the scope of the lower constraint jobs as we know that pulling everythin back can be tricky | 12:53 |
| gibi | we can try to pull back all our direct depts | 12:53 |
| sean-k-mooney | ok so now its only testing other nova deliverables | 12:53 |
| sean-k-mooney | honsetly those are the ones i was the least worried about | 12:54 |
| gibi | funnily in Zed we delivered nova with a wrong os-traits dept | 12:54 |
| gibi | and that triggered my thinking about this job | 12:54 |
| gibi | *wrong minimum os-traits dept | 12:54 |
| sean-k-mooney | for which feature | 12:55 |
| gibi | let me dig it out | 12:55 |
| sean-k-mooney | there was one that i expicty didint want to bump it for shice it was optional | 12:55 |
| sean-k-mooney | although that was os-brick i think not os-traits | 12:55 |
| gibi | sean-k-mooney: this was the fix https://review.opendev.org/c/openstack/nova/+/858280 | 12:56 |
| gibi | we released RC2 due to this ^^ | 12:56 |
| gibi | and we only detected that in time because zigo was eager to package the RC1 | 12:57 |
| sean-k-mooney | did it cause failusre when pci in placment was disabeld | 12:57 |
| sean-k-mooney | becaus if it did not we should not have released an rc2 for that | 12:57 |
| sean-k-mooney | in zed we had already stop including lower constraits in the PTI | 12:58 |
| zigo | gibi: And it's out of luck that I found it (ie: because using sbuild + git-buildpackage with the experimental as overlay only, which takes packages from unstable unless there's a strong hint that the experimental version is needed...) | 12:59 |
| sean-k-mooney | i guess given it broke unit tests it could break packagers workflows | 13:00 |
| sean-k-mooney | but high seams a strech to me | 13:00 |
| sean-k-mooney | gibi: https://github.com/openstack/governance/blob/584e06b0c186d4355d1d51f2d6df96e822253bef/resolutions/20220414-drop-lower-constraints.rst happend in zed | 13:01 |
| gibi | sean-k-mooney: and we dropped lower-constraints as a blanket lower constraints job is very hard to do right do to lack of tooling support | 13:02 |
| gibi | hence my take on a limited scope | 13:02 |
| sean-k-mooney | well to me its value was in direct depencies on things like oslo or any other package we directly use | 13:03 |
| gibi | sean-k-mooney: as I said we can try to extend the current proposal to more direct deps | 13:03 |
| gibi | I'm not sure it will be correct if there as cross dependencies between our direct depts | 13:04 |
| sean-k-mooney | well if its not everythign in requiremetns.txt i find it hard to trust that it works | 13:04 |
| gibi | but we can try | 13:04 |
| gibi | I proved it works for os-traits. see the DNM patch on the top | 13:04 |
| sean-k-mooney | yep but what if we start usign a feature in oslo-utils | 13:05 |
| sean-k-mooney | like the imageinfo json output for the vmdk cve | 13:05 |
| sean-k-mooney | to me the real benifit of lower constraits was to ensure we catch issues when backporting | 13:05 |
| gibi | the possible fault we want to catch with the lower constraint is generic for all our direct (or even indirect) depts. I'm not disagreeing there | 13:06 |
| sean-k-mooney | it also has benifit on master to ensure we are intentional when increaseing version and call it out in release notes | 13:07 |
| sean-k-mooney | well if required like swapping to sqlacmey 2.0 | 13:07 |
| gibi | so I would do a blanket lower constraint job if I could. But I know that it is impossible to do that right. So I started from a small set of depts. If you have suggestions what else to add to the set like oslo-utils or sqlachemy. Then we can try. I think blindly add all the direct dept can lead to problems | 13:11 |
| bauzas | gibi: sean-k-mooney: I think we somehow agreed on last weekly meeting that the job should only check the existing packages by pinning their versions | 13:17 |
| gibi | bauzas: "existing packages" <- this is not well defined. | 13:17 |
| bauzas | gibi: I mean, all of the packages from reqs.txt | 13:19 |
| gibi | see above. I think that is bigger than what we can chew. but we can try | 13:19 |
| gibi | as soon as we have cross dependencies between our direct debt the same problem will appert than what we had with the blanket lower constraint job | 13:20 |
| sean-k-mooney | i would almost prefer to take the opisite approch | 13:23 |
| sean-k-mooney | have an exclude list | 13:23 |
| sean-k-mooney | which we filter out | 13:23 |
| sean-k-mooney | so include all the package by default and then exclude ones we have issues with | 13:23 |
| sean-k-mooney | for example cryptography | 13:24 |
| gibi | sean-k-mooney: I have to think about how can we effectively decide what to filter out | 13:26 |
| sean-k-mooney | for me it would be anything that is normally isntalled form the package manager | 13:27 |
| sean-k-mooney | although with tox we might be abel to avoid that | 13:27 |
| sean-k-mooney | i know in devstack cryptography has been problematic in the past due to the fact its normally already installed in teh vm and we cant remove/upgrade it | 13:28 |
| gibi | sean-k-mooney: the problem is that we have no way to force lower constraints transitively with the pip tooling | 13:29 |
| gibi | so as soon as direct dept has cross dependencies we are lost do the the tooling limits | 13:29 |
| sean-k-mooney | pip takes the first constrait for a given package as the constiat too use | 13:32 |
| sean-k-mooney | at least that used to be the behavior | 13:32 |
| sean-k-mooney | i have not looked in a while. | 13:32 |
| sean-k-mooney | but if you include the modifed requirements fiel with -c before uc i think that will make it work for transitive deps | 13:33 |
| sean-k-mooney | of couse if one of our transitive dep increase its min version then we will have to bump ours | 13:33 |
| sean-k-mooney | sorry direct deps | 13:34 |
| sean-k-mooney | it basically gets problematic becasue pip does not support this usecase | 13:34 |
| gibi | yeah | 13:38 |
| gibi | so I don't want to go big and hit the same wall we had before with the lower constraint job | 13:38 |
| sean-k-mooney | i have +2d the relevent patches but i still dont really like this change | 13:39 |
| gibi | this is the smalles, lowest risk change, that can catch the specific issue we had during Zed | 13:39 |
| gibi | I agree that it does not solve every aspect of the generic issue, but I think it is already useful | 13:40 |
| gibi | I cannot promise I can solve the generic issue either | 13:40 |
| opendevreview | Justas Poderys proposed openstack/nova-specs master: Add support for Napatech LinkVirt SmartNICs https://review.opendev.org/c/openstack/nova-specs/+/859290 | 13:49 |
| bauzas | elodilles: not sure you added some items in the wikipage yet but auniyal wanted to add a topic | 14:53 |
| bauzas | elodilles: he added https://wiki.openstack.org/w/index.php?title=Meetings/Nova&diff=183013&oldid=182963 | 14:55 |
| bauzas | elodilles: so I moved those items into https://wiki.openstack.org/w/index.php?title=Meetings/Nova&diff=next&oldid=183013 | 14:55 |
| elodilles | bauzas: not yet, but i'm about to see if anything needs to be added there, will check it now | 15:13 |
| bauzas | elodilles: I'm done with this so you can do it anytime | 15:18 |
| elodilles | ack, just updated it | 15:19 |
| elodilles | i'll update the Xena etherpad soon, i'm just generating its content | 15:20 |
| elodilles | so that we can discuss xena-em transition based on that on the meeting | 15:21 |
| bauzas | reminder: nova meeting in 18 mins | 15:42 |
| bauzas | #startmeeting nova | 16:00 |
| opendevmeet | Meeting started Tue Apr 11 16:00:21 2023 UTC and is due to finish in 60 minutes. The chair is bauzas. Information about MeetBot at http://wiki.debian.org/MeetBot. | 16:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 16:00 |
| opendevmeet | The meeting name has been set to 'nova' | 16:00 |
| bauzas | heydo heya | 16:00 |
| bauzas | #link https://wiki.openstack.org/wiki/Meetings/Nova#Agenda_for_next_meeting | 16:00 |
| elodilles | o/ | 16:00 |
| gibi | o/ | 16:02 |
| bauzas | hmmmm, | 16:02 |
| bauzas | okay, let's start | 16:03 |
| gibi | what a crowd | 16:03 |
| Uggla | o/ | 16:03 |
| bauzas | thanks Hungary | 16:03 |
| auniyal | o/ | 16:03 |
| bauzas | hah, people arrive :) | 16:03 |
| bauzas | #topic Bugs (stuck/critical) | 16:03 |
| bauzas | #info No Critical bug | 16:03 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 19 new untriaged bugs (-3 since the last meeting) | 16:03 |
| bauzas | unfortunately a new bug just arrived one minute before the meeting started :) | 16:04 |
| bauzas | I haven't created an etherpad since most of the bugs I closed were not really needed to be look | 16:04 |
| bauzas | looked* | 16:04 |
| bauzas | #info Add yourself in the team bug roster if you want to help https://etherpad.opendev.org/p/nova-bug-triage-roster | 16:04 |
| bauzas | gibi: are you able to look at some bug reports this week ? | 16:05 |
| bauzas | I can also continue to look at some of them, like the new mdev one :) | 16:05 |
| gibi | I can try | 16:05 |
| * gibi makes a note | 16:05 | |
| bauzas | gibi: thanks | 16:05 |
| bauzas | #info bug baton is being passed to gibi | 16:05 |
| bauzas | any bug people want to discuss ? | 16:05 |
| * gibi has a new post-it on his monitor now | 16:05 | |
| bauzas | :) | 16:06 |
| bauzas | ok, moving on then | 16:06 |
| bauzas | #topic Gate status | 16:06 |
| bauzas | #link https://bugs.launchpad.net/nova/+bugs?field.tag=gate-failure Nova gate bugs | 16:07 |
| bauzas | #link https://etherpad.opendev.org/p/nova-ci-failures | 16:07 |
| bauzas | it was a short week for me, so I haven't seen any CI issue | 16:07 |
| dansmith | it's not great | 16:07 |
| bauzas | I've seen some gate issues last week indeed | 16:07 |
| dansmith | I'm not sure how much of it is nova's fault, other than the functional failures | 16:07 |
| bauzas | yeah :( | 16:08 |
| bauzas | again, I'll try to look at those this week | 16:08 |
| dansmith | I don't have any specific things to raise, but I can just say it's not great at the moment | 16:08 |
| bauzas | and maybe ping some folks | 16:08 |
| bauzas | dansmith: cool, anyway thanks for having it looked | 16:09 |
| bauzas | #link https://zuul.openstack.org/builds?project=openstack%2Fnova&project=openstack%2Fplacement&pipeline=periodic-weekly Nova&Placement periodic jobs status | 16:09 |
| bauzas | at least for periodic jobs, all of them work :) ^ | 16:09 |
| bauzas | #info Please look at the gate failures and file a bug report with the gate-failure tag. | 16:09 |
| bauzas | #info STOP DOING BLIND RECHECKS aka. 'recheck' https://docs.openstack.org/project-team-guide/testing.html#how-to-handle-test-failures | 16:10 |
| bauzas | moving on then | 16:10 |
| bauzas | #topic Release Planning | 16:10 |
| bauzas | #link https://releases.openstack.org/bobcat/schedule.html | 16:10 |
| bauzas | #link https://review.opendev.org/c/openstack/releases/+/877094 Proposed deadlines for Bobcat | 16:10 |
| bauzas | elodilles: thanks for having reviewed it, I don't know what happened with my agenda :) | 16:10 |
| elodilles | sure, np :] | 16:10 |
| bauzas | elodilles: I'll verify the days again | 16:11 |
| bauzas | and I'll rebase it after this meeting | 16:11 |
| bauzas | #info Bobcat-1 is in 4 weeks | 16:12 |
| bauzas | #topic Review priorities | 16:12 |
| 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:12 |
| bauzas | #info As a reminder, cores eager to review changes can +1 to indicate their interest, +2 for committing to the review | 16:12 |
| bauzas | #topic Stable Branches | 16:12 |
| bauzas | elodilles: your time (and then auniyal's ;) ) | 16:13 |
| elodilles | #link https://review.opendev.org/c/openstack/releases/+/878860 Xena stable branche EM proposal | 16:13 |
| elodilles | #info final Xena release tracking pad: https://etherpad.opendev.org/p/nova-stable-xena-em | 16:13 |
| elodilles | just some summary based on this ^^^ | 16:14 |
| elodilles | we have merged some patches | 16:14 |
| elodilles | but there are still patches that can be reviewed | 16:14 |
| bauzas | yup | 16:14 |
| elodilles | the question is, whether we should not wait anymore and do a final release for stable/xena | 16:15 |
| bauzas | elodilles: honestly I don't know what to review | 16:15 |
| bauzas | I've asked if other folks wanted to merge stuff | 16:15 |
| bauzas | the ones I cared I dared to review | 16:15 |
| elodilles | bauzas: i also haven't find any 'must-have' for stable/xena final release | 16:15 |
| bauzas | gibi: maybe you want some of your xena backported series to be merged before we call out EM ? | 16:16 |
| elodilles | maybe we are ready to do the final release then? | 16:16 |
| gibi | bauzas: I have nothing super pressing | 16:16 |
| bauzas | well, | 16:16 |
| gibi | but if we can merge open patches that sounds good :) | 16:16 |
| elodilles | #info note that we can merge patches AFTER the transition, just cannot do upstream releases anymore | 16:16 |
| gibi | understood ^^ | 16:16 |
| bauzas | yeah, this isn't a priority question | 16:17 |
| bauzas | if people want to release their backports, they NEED to beg for reviews by now | 16:17 |
| elodilles | ++ | 16:17 |
| bauzas | we could merge patches after EM, but then none of the patches would get released | 16:17 |
| bauzas | if people are happy with cherry-picking, this isn't a problem | 16:18 |
| bauzas | but if people rely on pip packages, they may get surprised | 16:18 |
| sean-k-mooney | well we will merge patches after EM | 16:18 |
| sean-k-mooney | but yes it wont get included in an upstream release | 16:18 |
| bauzas | I just wrote that :) | 16:18 |
| sean-k-mooney | well you said could impliying we might not | 16:18 |
| bauzas | anyway, looks to me none of us are telling nay | 16:18 |
| elodilles | but downstream it can be consumed & released ;) | 16:19 |
| sean-k-mooney | exactly | 16:19 |
| bauzas | elodilles: IMHO you're good to go | 16:19 |
| sean-k-mooney | so we still want to continue to merge them after EM | 16:19 |
| bauzas | elodilles: propose the releases patch and auniyal and I will +1 it | 16:19 |
| elodilles | bauzas: ack | 16:20 |
| bauzas | auniyal: you had a subitem | 16:20 |
| bauzas | about yoga and zed branches | 16:20 |
| auniyal | yes bauzas | 16:20 |
| auniyal | #info Please review these backport patches for stable zed and yoga release | 16:20 |
| auniyal | #link https://etherpad.opendev.org/p/release-liaison-PatchesToReview | 16:20 |
| auniyal | thats all :) | 16:20 |
| bauzas | ok thanks auniyal | 16:22 |
| bauzas | stable cores are welcome to review https://etherpad.opendev.org/p/release-liaison-PatchesToReview | 16:22 |
| bauzas | auniyal: when do you plan to propose a stable release for yoga and zed ? | 16:23 |
| auniyal | 20 April | 16:23 |
| bauzas | ack | 16:24 |
| sean-k-mooney | can you take a look at all nova deliverable fi you are doing that | 16:24 |
| bauzas | let's revisit then on next weekly meeting | 16:24 |
| sean-k-mooney | so os-vif, placement ectra | 16:24 |
| sean-k-mooney | not just nova | 16:24 |
| sean-k-mooney | i dont think we have a lot pending for those | 16:24 |
| bauzas | sean-k-mooney: you mean the stable branches ? | 16:25 |
| bauzas | yeah, that doesn't harm | 16:25 |
| auniyal | ack sean-k-mooney, I am making same list for os-vif, placement and os-trait | 16:25 |
| bauzas | auniyal: just use the same tracking etherpad IMHO | 16:25 |
| auniyal | but I share them once I review them | 16:25 |
| auniyal | ack bauzas | 16:25 |
| bauzas | cool thanks | 16:25 |
| sean-k-mooney | cool | 16:25 |
| bauzas | ok, I guess we're done with this topic | 16:25 |
| sean-k-mooney | for what its worth i dont see anythign for os-vif | 16:26 |
| bauzas | thanks elodilles and auniyal for taking care of our eldests | 16:26 |
| elodilles | ++ | 16:26 |
| bauzas | moving on | 16:26 |
| bauzas | actually, | 16:26 |
| bauzas | #topic Open discussion | 16:26 |
| bauzas | there is nothing in the etherpad | 16:27 |
| sean-k-mooney | refrsh | 16:27 |
| bauzas | s/etherpad/wige | 16:27 |
| sean-k-mooney | i added a topic | 16:27 |
| bauzas | heh, I'm used to refresh but I forgot this time | 16:27 |
| bauzas | (sean-k-mooney) hypervisor version weighed. | 16:27 |
| bauzas | go for it then :) | 16:27 |
| sean-k-mooney | so this is pretty simple | 16:27 |
| sean-k-mooney | i would like to add a new scheduler weigher | 16:27 |
| sean-k-mooney | that woudl weigh hosts based on the Hypervisror_version filed in the hoststate object | 16:28 |
| sean-k-mooney | and prefer putting vms on new hosts | 16:28 |
| sean-k-mooney | this will help with upgrades both pratically and with testing | 16:28 |
| dansmith | yeah, I'm not sure who would argue against such behavior, so it sounds like a good idea to me | 16:28 |
| bauzas | me too | 16:28 |
| bauzas | and it's a weigher | 16:29 |
| bauzas | not a filter | 16:29 |
| sean-k-mooney | what i would like to know is shoudl this be a specless bluepint or mini spec liek the pci weigher | 16:29 |
| dansmith | every cloud I've worked with has wanted to move instances towards newer hosts | 16:29 |
| bauzas | sean-k-mooney: do you need to add new fields for the ComputeNode records ? | 16:29 |
| sean-k-mooney | no | 16:29 |
| gibi | does hypervisror_version field something that is always meaningfully comparable? | 16:29 |
| bauzas | I think no | 16:29 |
| sean-k-mooney | no db or object chanbges | 16:29 |
| sean-k-mooney | gibi: that is a good question | 16:29 |
| * bauzas very quickly looks at the existing host states | 16:29 | |
| sean-k-mooney | so initally i was just going to do this for libvirt/qemu | 16:30 |
| sean-k-mooney | for the libvirt driver its the libvirt verison | 16:30 |
| sean-k-mooney | converted to a number | 16:30 |
| sean-k-mooney | so 7.0.0 becomes 700000000 | 16:30 |
| dansmith | it's an integer, so it's certainly easily comparable | 16:30 |
| sean-k-mooney | i dont know if all virt driver are comparibale | 16:30 |
| bauzas | https://github.com/openstack/nova/blob/master/nova/scheduler/host_manager.py#L129 | 16:30 |
| bauzas | at least we have this field | 16:30 |
| dansmith | if someone is not putting something where "bigger means newer" in an integer field, it would be very strange | 16:30 |
| sean-k-mooney | is it an int in the db | 16:31 |
| dansmith | it is | 16:31 |
| * bauzas wonders why we already provide this id | 16:31 | |
| gibi | then it is OK | 16:31 |
| sean-k-mooney | ok then i think it will work for eventying | 16:31 |
| bauzas | s/id/field | 16:31 |
| sean-k-mooney | the weigher just need to return the value as the weight directly | 16:31 |
| sean-k-mooney | and it will be nomalised/multipled like all the rest | 16:32 |
| bauzas | well, then if all the drivers provide this field, and if the HostState already has this, then there is no upgrade question | 16:32 |
| bauzas | so, | 16:32 |
| bauzas | specless blueprint to me | 16:32 |
| bauzas | oh heh, we already query it https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/scheduler/filters/image_props_filter.py#L85 | 16:32 |
| dansmith | seems okay to me if there are no other wrinkles | 16:32 |
| gibi | OK to me too | 16:33 |
| bauzas | so, basically, we already support this field | 16:33 |
| sean-k-mooney | bauzas: we do yes | 16:33 |
| bauzas | definitely a specless bp | 16:33 |
| sean-k-mooney | and we use it in the conductor | 16:33 |
| sean-k-mooney | to prevent live migrating form new to older | 16:33 |
| bauzas | sean-k-mooney: my question was more about the scheduler | 16:33 |
| sean-k-mooney | yep | 16:33 |
| sean-k-mooney | ok ill file the blueprint after the meeting | 16:33 |
| bauzas | I was wondering why we were having a HostState field | 16:33 |
| sean-k-mooney | and ill detail this in the describption | 16:33 |
| bauzas | that was meaning that we were already a filter using it | 16:33 |
| sean-k-mooney | yep i check that already | 16:33 |
| sean-k-mooney | we do | 16:34 |
| bauzas | cool cool | 16:34 |
| bauzas | so, | 16:34 |
| sean-k-mooney | i will file a blueprint and i will ping you the link once done for you to review | 16:34 |
| bauzas | #agreed a blueprint asking to have a weigher using hypervisor_version would be a specless one | 16:35 |
| bauzas | #action sean-k-mooney to ping bauzas once he creates it | 16:35 |
| bauzas | voila | 16:35 |
| bauzas | anything else ? | 16:35 |
| bauzas | if not | 16:36 |
| bauzas | thanks all, | 16:36 |
| bauzas | #endmeeting | 16:36 |
| opendevmeet | Meeting ended Tue Apr 11 16:36:13 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 16:36 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/nova/2023/nova.2023-04-11-16.00.html | 16:36 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/nova/2023/nova.2023-04-11-16.00.txt | 16:36 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/nova/2023/nova.2023-04-11-16.00.log.html | 16:36 |
| gibi | o/ | 16:36 |
| bauzas | hah, https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/scheduler/filters/image_props_filter.py#L84 | 16:36 |
| bauzas | so, basically we even use the hypervisor version value for an image property :) | 16:36 |
| bauzas | this is even not only internal | 16:37 |
| sean-k-mooney | really? that seams wrong | 16:37 |
| bauzas | sean-k-mooney: look above | 16:37 |
| sean-k-mooney | oh i know what this is for | 16:37 |
| sean-k-mooney | this is for hyperv i think | 16:37 |
| sean-k-mooney | they use v1 and v2 like we use machine types | 16:37 |
| bauzas | maybe, but that works too for libvirt | 16:37 |
| sean-k-mooney | https://github.com/openstack/nova/blob/50fdbc752a9ca9c31488140ef2997ed59d861a41/nova/virt/hyperv/hostops.py#L99-L104 | 16:38 |
| sean-k-mooney | i guess no it sused for somethign else | 16:38 |
| sean-k-mooney | i would want this to be a min verion really rather then exact comparison | 16:38 |
| sean-k-mooney | that is not waht it does unfornetly | 16:39 |
| sean-k-mooney | actully return img_prop_predicate.satisfied_by(hyper_ver_str) | 16:40 |
| sean-k-mooney | so that proably is a min version check | 16:41 |
| sean-k-mooney | thats implmented by distutils | 16:41 |
| bauzas | this is | 16:41 |
| bauzas | and https://github.com/openstack/nova/blob/72370a188c0755bc9c864b5a5e4a972077cb8dd6/nova/virt/libvirt/driver.py#L9516 | 16:41 |
| bauzas | if you're an operator, you can create an image requesting for a min libvirt version | 16:41 |
| bauzas | that already exists | 16:41 |
| sean-k-mooney | well that is good to know | 16:42 |
| bauzas | this is bad to me | 16:42 |
| bauzas | but we do support it | 16:42 |
| sean-k-mooney | its bad becasue its leaking backend details | 16:42 |
| bauzas | correct | 16:42 |
| sean-k-mooney | its good if you need to target a version for certen fucntionality | 16:42 |
| sean-k-mooney | it should not be requried if we used traits properly | 16:42 |
| sean-k-mooney | so in the past i can see the usecase | 16:42 |
| bauzas | it was obviously pre-traits | 16:42 |
| sean-k-mooney | ya | 16:43 |
| sean-k-mooney | anyway at least we know the semantic of "it shoudl be sortable" | 16:43 |
| sean-k-mooney | have already been depened on | 16:43 |
| bauzas | yeah, but instead of pinning a specific virt version, we should absract this into abstract versions | 16:43 |
| sean-k-mooney | so that makes the weigher simpler | 16:43 |
| bauzas | semantic versioning I mean | 16:43 |
| sean-k-mooney | ya well to do that we woudl need to change this form an int to string | 16:44 |
| sean-k-mooney | to model that | 16:44 |
| bauzas | but yeah, for your weigher, it just makes the paperwork easy | 16:44 |
| sean-k-mooney | but i dont want to touch that now | 16:44 |
| sean-k-mooney | we can in the future if it makes sense too | 16:44 |
| bauzas | sean-k-mooney: yup, and ideally it should obfuscate the hypervisor specific version | 16:44 |
| sean-k-mooney | i will go do the paperwork and let you knwo when its donw | 16:44 |
| bauzas | cool, I'll approve it once you ping me | 16:44 |
| bauzas | and the weigher seems to me an easy peasy given the existing | 16:45 |
| bauzas | the code change itself should be simple to review :) | 16:45 |
| bauzas | anyway, done for today | 16:46 |
| sean-k-mooney | bauzas: when you have time https://blueprints.launchpad.net/nova/+spec/weigh-host-by-hypervisor-version | 17:06 |
| bauzas | sean-k-mooney: done | 17:07 |
| sean-k-mooney | thanks | 17:08 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (db) https://review.opendev.org/c/openstack/nova/+/831193 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (objects) https://review.opendev.org/c/openstack/nova/+/839401 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (manila abstraction) https://review.opendev.org/c/openstack/nova/+/831194 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (drivers and compute manager part) https://review.opendev.org/c/openstack/nova/+/833090 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Attach Manila shares via virtiofs (api) https://review.opendev.org/c/openstack/nova/+/836830 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Check shares support https://review.opendev.org/c/openstack/nova/+/850499 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add metadata for shares https://review.opendev.org/c/openstack/nova/+/850500 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach notification https://review.opendev.org/c/openstack/nova/+/850501 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach notification https://review.opendev.org/c/openstack/nova/+/851028 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add shares to InstancePayload https://review.opendev.org/c/openstack/nova/+/851029 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add helper methods to attach/detach shares https://review.opendev.org/c/openstack/nova/+/852085 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add libvirt test to ensure metadata are working. https://review.opendev.org/c/openstack/nova/+/852086 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add virt/libvirt error test cases https://review.opendev.org/c/openstack/nova/+/852087 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to reboot method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/854823 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Support rebooting an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/854824 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_attach_error notification https://review.opendev.org/c/openstack/nova/+/860282 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add instance.share_detach_error notification https://review.opendev.org/c/openstack/nova/+/860283 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add share_info parameter to resume method for each driver (driver part) https://review.opendev.org/c/openstack/nova/+/860284 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Support resuming an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/860285 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Add helper methods to rescue/unrescue shares https://review.opendev.org/c/openstack/nova/+/860286 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (driver part) https://review.opendev.org/c/openstack/nova/+/860287 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Support rescuing an instance with shares (compute and API part) https://review.opendev.org/c/openstack/nova/+/860288 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: Docs about Manila shares API usage https://review.opendev.org/c/openstack/nova/+/871642 | 17:49 |
| opendevreview | ribaudr proposed openstack/nova master: The purpose of this patch is to ensure that, in the event of a compute reboot, shares associated with instances are mounted successfully on the compute host during the service initialization process. https://review.opendev.org/c/openstack/nova/+/880075 | 17:49 |
| dansmith | bauzas: I totally missed this, but apparently we should be working to remove hyperv: https://lists.openstack.org/pipermail/openstack-discuss/2022-November/031044.html | 18:54 |
| sean-k-mooney | oh ya | 19:03 |
| sean-k-mooney | i rememebr seeing that | 19:03 |
| sean-k-mooney | so ya we proably should deprecate it this cycle | 19:04 |
| sean-k-mooney | and remove in C | 19:04 |
| sean-k-mooney | ... or D with the new lifecycle | 19:04 |
| sean-k-mooney | that kind of sucks as it proably should have been deprecated in A | 19:04 |
| gmann | if os-win goes away in this cyle then we might need to just remove it ? | 19:05 |
| sean-k-mooney | yep | 19:05 |
| sean-k-mooney | can we retoactivly declare it deprecated for Antelope | 19:05 |
| sean-k-mooney | assuming that happens | 19:05 |
| gmann | humm | 19:05 |
| sean-k-mooney | either way we shoudl declare it deprecated in bobcat | 19:06 |
| sean-k-mooney | and see if we have issues with os-win | 19:06 |
| bauzas | dansmith : we can send a deprecation signal by Bobcat if you want but continue to say it then in C | 19:08 |
| gmann | even TC is reaching out operators if anyone using/have window based customer and can maintain the project/project-deps and will take final call on retirement of os-win in June event or so | 19:10 |
| dansmith | IIRC, we already said that vmware was abandonware right? | 19:10 |
| gmann | but from nova perspective, if we do not/have not seen much interest in hyperV then deprecating ASAP might be good. and if os-win retirement happen in this cycle then removal also in B only | 19:11 |
| dansmith | so I feel like we could do the same for hyperv for the time being and then remove it according to our schedule | 19:11 |
| bauzas | dansmith: yup we deprecated it IIRC | 19:11 |
| gmann | yeah | 19:11 |
| dansmith | yeah, so no need to freak out and yank it early, IMHO, just mark as deprecated, even if it can't run or fails with os-win problems and then we can remove it in D | 19:11 |
| dansmith | the thing that concerns me the most however is the user survey showing 2% of users are using it | 19:12 |
| dansmith | which, deprecation aside, also worries me :) | 19:12 |
| sean-k-mooney | i woudl hope that existing deployment can continue to use the last release of os-win | 19:14 |
| gmann | we can un-deprecate it if anyone come and maintain it. but I am worried that they might see this deprecation way after few cycle when they upgrade it to B and we might hve removed it by then | 19:14 |
| sean-k-mooney | the issue will be with new python releases or its deps | 19:14 |
| sean-k-mooney | well we would not remove it until D | 19:14 |
| sean-k-mooney | unless we are forced to earlier | 19:15 |
| gmann | that is question on how we want to do for supported stable branch, retirement means it goes away from supported releases also and what to tell on hyperV on stable is another challenges | 19:15 |
| sean-k-mooney | we dont test hyperv in the first party ci | 19:15 |
| gmann | yeah | 19:15 |
| sean-k-mooney | so it really only affect stable branches if we fix a bug and want to backport it | 19:15 |
| gmann | yeah, in case of stable broken on any fixes or so | 19:16 |
| gmann | os-win stable is broken and then no way to fix it | 19:17 |
| gmann | but deprecating it now is best we can do | 19:18 |
| gmann | bauzas: dansmith: vmware driver is un-deprecated since victoria https://review.opendev.org/c/openstack/nova/+/742407 | 19:22 |
| sean-k-mooney | gmann: we redeprecated it again | 19:23 |
| dansmith | lol | 19:23 |
| dansmith | it has been so many times | 19:23 |
| gmann | oh | 19:23 |
| gmann | where is the latest deprecation ? | 19:24 |
| sean-k-mooney | maybe im mistaken but i tought we did it in yoga? | 19:24 |
| dansmith | that would have been the next release | 19:24 |
| gmann | I cannot see if we re-deprecated after 742407 | 19:26 |
| sean-k-mooney | hum well ciwatch.mmedvede.net/project?project=nova&time=7+days seams to nolonger be working | 19:26 |
| sean-k-mooney | has the third party ci been maintianed | 19:26 |
| sean-k-mooney | http://207.189.188.190/logs/ | 19:27 |
| sean-k-mooney | im not seeing anything | 19:28 |
| sean-k-mooney | https://review.opendev.org/q/commentby:vmwareminesweeper | 19:28 |
| sean-k-mooney | ok so tehre are comments i gues | 19:28 |
| sean-k-mooney | althouhg im not sure that is recent | 19:29 |
| gmann | yeah, it seems it is not deprecated, I can see a few changes merged also in driver (last merged in Apr 29, 2022) so it is maintained ? :) | 19:31 |
| sean-k-mooney | i think no | 19:35 |
| sean-k-mooney | the undeprecation was condtional on them maintining the ci | 19:35 |
| sean-k-mooney | it looks like it was shut down in april 2022 | 19:35 |
| gmann | this is what i found from melwitt topic in antelope PTG discussion, mark it as "not tested" explicitly https://etherpad.opendev.org/p/nova-antelope-ptg#L216 | 19:37 |
| sean-k-mooney | ah yes i rememebr that | 19:37 |
| sean-k-mooney | we wanted to not use the term deprecated | 19:37 |
| sean-k-mooney | i was looking for that message eiarler by the way | 19:38 |
| gmann | humm, and no removal soon or when we decide to remove then go with deprecation first and then removal ? | 19:38 |
| gmann | ok | 19:38 |
| sean-k-mooney | i think we left it at if it breaks we are not goignt to fix it unless someone comes with a patch | 19:39 |
| gmann | i think for hyperV we can mark it deprecated as its deps going away soon.... | 19:39 |
| gmann | sean-k-mooney: k | 19:39 |
| sean-k-mooney | but no one should deploy new installs with vmware | 19:39 |
| sean-k-mooney | we proably need to actully do what we agreed there since im not seeing either a flag on the dirver or the message | 19:40 |
| sean-k-mooney | in the logs | 19:40 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/863911 | 19:41 |
| sean-k-mooney | we should have merged that | 19:41 |
| sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/863910/1 | 19:41 |
| sean-k-mooney | and that in Antielope | 19:41 |
| sean-k-mooney | i knew stephen had patches for this | 19:41 |
| sean-k-mooney | bauzas: ^ we missed inclucing those | 19:42 |
| sean-k-mooney | gmann: i think we should consider backporting those to stable/antelope | 19:42 |
| gmann | i see | 19:42 |
| gmann | sean-k-mooney: this 'not tested' is good to backport but for HyperV case we need to mark deprecated instead of experimental | 19:43 |
| sean-k-mooney | i would prefer to do that as a third patch just to keep that discussion sperate form addign the warning | 19:44 |
| sean-k-mooney | gmann: from a release note point of view both of these we going to be deprecations | 19:45 |
| gmann | sure, that works fine. and we can backport this 'note tested' warning to reflect the actual things | 19:45 |
| sean-k-mooney | we just didnt want to use that trem in the warning | 19:45 |
| sean-k-mooney | basically we wanted to have the ablity to remove in b or C if needed | 19:46 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!