Earlier  
Posted Nick Remark
#openstack-nova - 2023-08-14
19:45:32 opendevreview Ghanshyam proposed openstack/nova master: DNM: testing https://review.opendev.org/c/openstack/nova/+/891347
20:01:43 opendevreview Dan Smith proposed openstack/nova master: Avoid lazy-loading in resize and rebuild/evacuate https://review.opendev.org/c/openstack/nova/+/891336
20:01:43 opendevreview Dan Smith proposed openstack/nova master: Remove two lazy loads on every server show https://review.opendev.org/c/openstack/nova/+/891352
20:50:06 opendevreview Merged openstack/nova master: Fix up inconsistent max_count argument in o-d-ms https://review.opendev.org/c/openstack/nova/+/888470
21:15:49 opendevreview Dan Smith proposed openstack/nova master: Avoid lazy-loading in resize and rebuild/evacuate https://review.opendev.org/c/openstack/nova/+/891336
21:15:50 opendevreview Dan Smith proposed openstack/nova master: Remove a lazy load on every server show https://review.opendev.org/c/openstack/nova/+/891352
22:52:27 opendevreview Dan Smith proposed openstack/nova master: Remove a lazy load on every server show https://review.opendev.org/c/openstack/nova/+/891352
#openstack-nova - 2023-08-15
10:01:52 gibi sean-k-mooney: as we really like shelve/unshelve to clean up messy situations this bugfix probably very useful https://review.opendev.org/q/topic:bug%252F2025480
10:12:08 kevko Hi everyone, i would like to ask if someone can approve this blueprint proposed by my colleaguage Viktor Krivak, we already have a code implemented but waiting for specs approval , so we can send patches to gerrit...could someone look into please ? https://review.opendev.org/c/openstack/nova-specs/+/890779 , thank you very much
10:13:17 kevko ^^ it's solution for az-affinity and anti-az-affinity which can be also used by octavia to reach better high-availability as amphoras will be spread across AZs
10:14:14 gibi kevko: we reached nova spec freeze for 2023.2 (bobcat) on 6th of July https://releases.openstack.org/bobcat/schedule.html#b-nova-spec-freeze
10:14:46 gibi this is why you don't get attention on the spec
10:14:59 kevko hmm, does it mean that this can be approved for caracal only right ?
10:15:17 gibi kevko: yes
10:15:25 gibi kevko: you can see the caracal schedule here https://releases.openstack.org/caracal/schedule.html
10:16:00 kevko hmm, can we push patchsets for this to gerrit and mark as DNM for example, we would like to see zull results etc ...
10:16:27 gibi kevko: yes, you can do that
10:16:39 kevko (because i read somewhere that it's "forbidden" to push the code if spec is not approved ... so i am better asking )
10:16:47 gibi kevko: that will help the spec reviewers as well to see not just the spec proposal but the resulting implementation
10:17:11 gibi kevko: if you can point me to the place where it was written then I will be happy to fix that
10:18:01 kevko let me find it
10:35:13 kevko https://github.com/openstack/nova-specs/blob/master/specs/2023.2-template.rst
10:39:57 kevko Gibi, so question is when we can except that new directory for caracal release will be available for specs repo to move spec for caracal ?
10:45:52 kevko Gibi, can we create directory for 2024.1 specs now ?
11:36:56 gibi kevko: which part of the spec template suggested that you should not push code for review?
11:36:59 gibi I see
11:37:01 gibi "You should aim to get your spec approved before writing your code. While you are free to write prototypes and code before getting your spec approved, its possible that the outcome of the spec review process leads you towards a fundamentally different solution than you first envisaged."
11:37:52 kevko yep ..maybe misunderstood ..
11:39:45 gibi kevko: it is basically a warning that we might ask you during the spec review to change the direction of the spec and therefore you might need to rewrite the code
11:40:22 gibi on the directory question. Technically we could propose the directory right now
11:46:06 gibi kevko: you can propose a similar patch to https://review.opendev.org/c/openstack/nova-specs/+/872068 to create the 2024.1 directory
11:49:16 kevko gibi Thank you, I really appreciate it :), then if the spec will be in right directory, can we expect that someone will check the spec even if now it's bobcat cycle ? or we will wait until december ?
12:17:58 opendevreview Michal Arbet proposed openstack/nova-specs master: Create specs directory for 2024.1 Caracal https://review.opendev.org/c/openstack/nova-specs/+/891468
12:20:42 opendevreview Michal Arbet proposed openstack/nova-specs master: Add availability zone-aware affinity filter to the scheduler https://review.opendev.org/c/openstack/nova-specs/+/890779
12:32:47 gibi kevko: to be honest right now is vacation period, then we will be busy finishing the content for the bobcat release. So I would not expect much review on caracal spec until the bobcat release is done in early october.
12:46:30 kevko gibi understand, that's apity
12:46:33 kevko a pity
13:11:17 sean-k-mooney kevko: i would expect it to get attention in mid september
13:11:22 sean-k-mooney it wont be december
13:11:58 sean-k-mooney but we will be busy with release work for then ext 3-4 weeks and thats where most of the attention will be focused until rc1 is released
13:13:11 sean-k-mooney gibi: like i s a strong statement for using shelve to recover but it works surpising well in may siturations
13:19:44 kevko sean-k-mooney: well, it would be nice if you just read it and leave some comment ...but on the other side ...i understand
13:20:27 kevko point is that my colleguage as implementator can work on it ...and it will not work on it until some comment will be left in review :D
13:22:03 sean-k-mooney i can try and take a look in general i dont think we can do what you want however
13:22:48 sean-k-mooney kevko: we cant do az affintiy or anti affintiy at the sechduelr filter level without some majoyr chages as the az is already select before the scheduler runs
13:23:12 sean-k-mooney doing this in the filters has been rejected in the past on 2 ocations for that very reason
13:23:30 sean-k-mooney the az is set in the build request in the api before the rpc to the schduler
13:23:47 sean-k-mooney so unless the spec adresses that it wont work
13:29:56 opendevreview Bence Romsics proposed openstack/nova master: Do not untrack resources of a server being unshelved https://review.opendev.org/c/openstack/nova/+/890406
14:21:22 opendevreview Dan Smith proposed openstack/nova master: Log excessive lazy-loading behavior https://review.opendev.org/c/openstack/nova/+/891340
14:21:23 opendevreview Dan Smith proposed openstack/nova master: Avoid lazy-loading in resize and rebuild/evacuate https://review.opendev.org/c/openstack/nova/+/891336
14:21:23 opendevreview Dan Smith proposed openstack/nova master: Remove a lazy load on every server show https://review.opendev.org/c/openstack/nova/+/891352
15:31:29 gibi nova meeting will start in 30 mins here. I will be your host stoday in bauzas' absense and I will not try to do a full meeting if not needed :)
16:00:41 gibi #startmeeting nova
16:00:41 opendevmeet Meeting started Tue Aug 15 16:00:41 2023 UTC and is due to finish in 60 minutes. The chair is gibi. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:00:41 opendevmeet Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:00:41 opendevmeet The meeting name has been set to 'nova'
16:00:44 gibi o/
16:00:46 dansmith o/
16:01:45 elodilles o/
16:02:10 gibi OK, lets get started
16:02:16 gibi this will be a sort meeting
16:02:25 gibi #topic Bugs (stuck/critical)
16:02:40 gibi I don't see any critical bugs
16:03:03 gibi #link https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New 40 new untriaged bugs (+0 since the last meeting)
16:03:46 gibi based on the roster elodilles had the baton for a long time
16:04:09 elodilles yepp o:) i've tried to triage some bugs :)
16:04:13 gibi thanks
16:04:16 elodilles np
16:04:39 gibi I think we can let that baton be on PTO until bauzas is back
16:04:55 elodilles ++
16:05:09 gibi at least I don't know where to assign it
16:05:12 gibi so
16:05:15 gibi #info bug baton is PTO
16:05:19 gibi #info bug baton is on PTO
16:05:34 gibi do we have any bugs that needs discussion?
16:06:07 gmann o/
16:06:19 elodilles i don't have any to mention (though feel free to look for the bugs if i misjudged any of them)
16:07:31 gibi #topic Gate status
16:07:38 dansmith hoo boy
16:07:56 dansmith things are definitely improving but we still have work to do
16:08:22 dansmith this isn't really gate status, but one thing I've noticed while looking at countless gate logs is that we've had a bunch of lazy-loads sneak in,
16:08:36 dansmith up to five per object one after another for several operations
16:08:46 gmann at least less timeout and oom i think
16:08:53 dansmith I started work on making them visible and have been squashing them here: https://review.opendev.org/q/topic:reduce-lazy-loads
16:09:21 gibi dansmith: nice
16:09:37 gibi is there any specific issue we need to discuss?
16:09:37 dansmith I dunno how others feel, but I think 1 lazy load per object per service should be enough, and any time we need to lazy-load more than one thing, we probably should have pre-queried for the thing
16:09:53 gibi dansmith: in general I agree
16:10:05 gibi especially if we always do the two lazy loads unconditionally
16:10:11 dansmith so while it's not really clearly stability-related, doing this will reduce our load on rabbit, the db, and conductor which I'm sure will help gate performance
16:10:16 dansmith yeah
16:10:25 gibi I agree
16:10:41 dansmith the other gate failure I know of, which I haven't seen much since discussing with melwitt, was the ceph job seeming to hang n-cpu
16:10:52 dansmith I think she was looking at it but I don't know if there was any outcome
16:11:20 gibi OK
16:11:27 gibi thanks for the update
16:11:41 dansmith and then aside from that, plenty of small things but nothing large enough to be specifically noteworthy on its own that I know of
16:12:41 gibi I started to look into https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_1fe/889992/2/gate/nova-tox-functional-py39/1fefb65/testr_results.html on Friday but no real breakthrough yet
16:12:49 dansmith cool

Earlier   Later