Earlier  
Posted Nick Remark
#openstack-nova - 2024-12-09
12:27:12 opendevreview Balazs Gibizer proposed openstack/nova master: DNM: test with placement ac breadth-first https://review.opendev.org/c/openstack/nova/+/937275
13:32:33 opendevreview Kaloyan Kotlarski proposed openstack/nova master: libvirt: Fetch the available vCPUs from the respective cgroup https://review.opendev.org/c/openstack/nova/+/927474
13:40:39 opendevreview Balazs Gibizer proposed openstack/placement master: Add a global limit on the number of allocation candidates https://review.opendev.org/c/openstack/placement/+/936658
13:40:39 opendevreview Balazs Gibizer proposed openstack/placement master: Factor out allocation candidate generation strategy https://review.opendev.org/c/openstack/placement/+/937273
13:40:40 opendevreview Balazs Gibizer proposed openstack/placement master: Add round-robin candidate generation strategy https://review.opendev.org/c/openstack/placement/+/936832
13:40:40 opendevreview Balazs Gibizer proposed openstack/placement master: DNM: test with breadth-first in tempest https://review.opendev.org/c/openstack/placement/+/937274
15:21:00 opendevreview Merged openstack/nova master: api: Add response body schemas for bare metal node APIs https://review.opendev.org/c/openstack/nova/+/924591
15:23:10 gibi melwitt: the whole https://review.opendev.org/q/topic:%22bug/2070257%22 is ready for review now
15:34:01 opendevreview Stephen Finucane proposed openstack/nova master: trivial: Remove legacy API artifact https://review.opendev.org/c/openstack/nova/+/937377
15:36:48 sean-k-mooney gibi: you have 3 actual patches adn two DNMs to test this in ci with the new order if im readign that right?
15:37:25 sean-k-mooney is the plan to enabel the breadth-first appochec in nova-next or similar?
15:38:17 sean-k-mooney i assume we woudl like to have both tested between the set of jobs we have
15:38:56 sean-k-mooney given the limited useage of nested resouce providers in the upstream gate i doubt we woudl see an observable diffence
15:39:45 sean-k-mooney although i coudl see use eventually chanigng the default fo the placement config option in a future release so setting it in nova-next i think woudl make sesne
15:40:39 sean-k-mooney gibi: if you would like me to be a second review on that i can try and do so next year but i wont have time to do that this week
15:41:03 sean-k-mooney if others feel like they have a better grasp on placmenet that fine too
15:41:35 sean-k-mooney i was hopign melwitt would be one of the reviewer on thsi but i dont know who is next best positioned to review
15:58:49 gibi sean-k-mooney: 3 actual placement patch yes, the DNMs are just running tempest with the fix
15:59:43 gibi sean-k-mooney: I feel this patch will wait for review until the new year, so you will have a chance to look at it
15:59:57 gibi melwitt is already signalled interest
16:00:54 gibi I'm OK to enable this config in nova-next, I think it is pretty safe. But as you noted we don't have much nested coverage in upstream CE
16:00:57 gibi CI
17:23:38 auniyal sean-k-mooney, please have a look at https://review.opendev.org/c/openstack/nova/+/929858 for review
17:24:23 sean-k-mooney sure
17:25:22 auniyal thanks :)
17:44:40 opendevreview Stephen Finucane proposed openstack/nova master: trivial: Remove legacy API artifact https://review.opendev.org/c/openstack/nova/+/937377
17:50:47 sean-k-mooney auniyal: +1.5 comments inline
18:03:20 opendevreview Douglas Viroel proposed openstack/nova-specs master: Add spec for show scheduler hints in server details https://review.opendev.org/c/openstack/nova-specs/+/936140
18:29:09 sean-k-mooney dviroel: ^ i have +2'd the spec but also left some nits that coudl be improved. i am proably +1.6 which is why i rounded up to a +2 instead of down to a +1 but im happy with the over all direction of this
18:41:29 dviroel thanks sean-k-mooney. yeah, there are some implementation/testing details missing in the spec, but mainly because I am not familiar with all nova doc/test details. But for sure I will follow previous implemented API microversions to check all required changes.
18:42:27 sean-k-mooney yep if other are happy with the implict understandign that all standard testing will be added at implemeation time im happy to just review for that when reviewing the code change
18:49:53 opendevreview Merged openstack/nova master: api: Add response body schemas for console auth token APIs https://review.opendev.org/c/openstack/nova/+/924592
19:35:09 opendevreview Merged openstack/nova master: Add instance.share_attach_error notification https://review.opendev.org/c/openstack/nova/+/860282
19:51:58 sean-k-mooney artom: -1 on https://review.opendev.org/c/openstack/nova-specs/+/936775 but i think its mostly ok
19:52:15 artom You wrote me a freaking novel :P
19:52:26 artom Thanks for reading, I'll need to some to ingest all of that
19:52:34 artom *some time
19:53:19 sean-k-mooney main things are we shoudl not use nova in the image property value we shoudl use `compute` and the opt in path for exising instnace does not really work
19:53:29 sean-k-mooney a user can resize to opt in but thats about it
19:53:58 artom Ack on "compute"
19:54:00 sean-k-mooney they could update an image the uploaded and rebuild to it but that lesses data
19:54:15 sean-k-mooney *looses
19:54:45 artom Right - so how do new image properties currently get "synced"? Is the answer "they don't"?
19:54:58 sean-k-mooney i think what you propsoe can be extedned to encypted cidner voluems so if we say we plan to do that in a sepete spec later that fine
19:55:10 sean-k-mooney artom: they dont by design
19:55:26 artom OK, I need to rethink that bit then.
19:55:34 sean-k-mooney we take a snap shot of them and stor them in the instace_system_metadata table wit a img_ prefix
19:56:09 sean-k-mooney i think you can just say the only way to apply this to existing instnace is resize or the nova manage command with the user triggering a hard reboot or simialr
19:56:42 artom Ack
19:57:36 sean-k-mooney the -1 is mainly the nova vs compute thing
19:57:45 melwitt gibi: ack, will look
19:57:45 sean-k-mooney but please read the rest when you have time
19:57:45 artom Yeah
19:57:50 artom Yep
19:58:52 sean-k-mooney i might have time before i go on pto to do another pass but if other are ok with the desgin then you dont strictly need to wait for me to re reivew
19:59:08 sean-k-mooney if its still open when im back ill take another pass early january
20:06:05 artom I don't think anyone's expecting it to merge in 2024. We wanted to at least get a couple of review passes, with maybe a +1 or +2.
20:09:35 abishop hi, cinder guy here who is looking for a "feature liaison" to help me with a feature I'd like to work on for epoxy
20:09:37 abishop in the 2025.1 PTG our teams discussed a possible enhancement to the "Update a volume attachment" API to support cinder's driver assisted volume migration
20:09:39 abishop that turns out to not be feasible for several (cinder) reasons, and so I'm now pursuing an alterntive approach to improving the user experience
20:09:41 abishop it would entail a small enhancement to the "Show a detail of a volume attachment" but that would still require a microversion which means a spec
20:09:43 abishop I have a few liaison questions, starting with what's the epoxy deadline for specs?
20:27:38 artom abishop, you don't necessarily need a feature liaison right off the bat, you could pick up one during spec review. Official deadline is E-2, so Jan 10, but we're trying to get specs posted ASAP and at least looked at before the end of 2024, because otherwise the time because real short.
20:29:21 abishop artom phew, Jan 10 is great news to me and I can post something by mid next week
20:29:58 artom abishop, I don't think bauzas ever posted our "unofficial" timeline, but yeah, get something up ASAP
20:30:03 artom (posted on the ML)
20:30:52 abishop on the ML? I though it would be submitted for review to nova-specs
20:32:38 abishop though I don't know how nova specs transition from proposed to the "approved" directory
20:37:48 artom No no, I was completing my previous sentence: "ever posted on the ML"
20:38:13 artom abishop, they don't, you write them directly under the approved directory. They become approved when they merge.
20:38:47 abishop ah, that makes sense
21:28:42 opendevreview Merged openstack/nova master: Rephrase the help message https://review.opendev.org/c/openstack/nova/+/925207
23:34:43 sean-k-mooney abishop: the unoffical deadlien for specs is thusrday of r-16 december 12th i.e this thursday but that really just because most nova folks will be on pto starting sometime this/next week.
23:35:44 sean-k-mooney https://etherpad.opendev.org/p/r.4f297ee4698e02c16c4007f7ee76b7c1#L204
23:36:29 sean-k-mooney so in theory tomorow is a spec review day, thrusday is the soft freeze and the actul freeze is january 9th
23:36:51 sean-k-mooney i.e. epoxy milestone two https://releases.openstack.org/epoxy/schedule.html#e-2
23:42:54 sean-k-mooney abishop: by the way we are still waitign on cinder folks to weigh in on https://review.opendev.org/c/openstack/nova-specs/+/932653
23:43:26 sean-k-mooney we dont nessiarly have concerns with adding new volume frontend qos types provide the cinder side of it is done first
23:55:06 abishop sean-k-mooney: thank you for the additional details; I'll try to post the spec ASAP (I'm also out for the rest of the year starting next Thu). I don't have any info on the other qos spec, but will see what I can find
23:56:12 sean-k-mooney abishop: as far as im aware the burts qos value are not standardised in cinder so i think they need a cinder spec first to add those
23:56:20 sean-k-mooney im not sure if they have create one since
23:56:48 sean-k-mooney that seams to be the only review the author has so proably now
23:56:50 sean-k-mooney *not
#openstack-nova - 2024-12-10
01:37:49 opendevreview Merged openstack/nova master: api: Add response body schemas for flavor access API https://review.opendev.org/c/openstack/nova/+/924593
02:15:30 opendevreview melanie witt proposed openstack/placement master: Require cchardet>=2.2.0a2 for perfload job https://review.opendev.org/c/openstack/placement/+/937423
05:26:20 opendevreview melanie witt proposed openstack/placement master: Require cchardet>=2.2.0a2 for perfload job https://review.opendev.org/c/openstack/placement/+/937423
05:27:57 opendevreview melanie witt proposed openstack/placement master: Use cchardet>=2.2.0a2 for placement-perfload job https://review.opendev.org/c/openstack/placement/+/937423
09:31:48 opendevreview Amit Uniyal proposed openstack/nova master: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/929858
09:38:13 opendevreview Amit Uniyal proposed openstack/nova master: Update Nova bdm with updated swap info https://review.opendev.org/c/openstack/nova/+/929858
10:34:41 bauzas gibi: I have an appointment today at 5:30pm which means I can't run the nova meeting
10:34:50 bauzas could you run it ?
11:47:28 gibi bauzas: I also have a 1:1 scheduled to 5:30 today so I cannot run the second half of the meeting
11:47:44 gibi but I can do a 30 minutes one
12:42:33 fwiesel bauzas: I forgot to mention last time, that I can't attend this meeting. I'll be hopefully on a plane.
12:57:43 frickler sean-k-mooney: is https://review.opendev.org/c/openstack/nova/+/933365 ready for reviews? ralonsoh made some good progress on the neutron side, so IMO it would be good to get this blocker removed from nova
13:20:32 sean-k-mooney frickler: so i have not really had time to look at this
13:20:51 sean-k-mooney i dont think the removel of lock ustis and going to treading.RLOCK is a generic solution that we can take
13:21:09 sean-k-mooney frickler: i belive that is what neutron were trying yes?
13:22:10 sean-k-mooney it does seam to be passign now but didt we have some issue with it still deadlocking in one run
13:25:08 frickler if more work is needed, I fine with that, too, I just wasn't sure whether I should try to look for reviewers

Earlier   Later