| gmann | sure. but I am sure we will continue spending time every time and always find solution :P just joking | 00:00 |
|---|---|---|
| gmann | we means except me :) | 00:00 |
| melwitt | hehe | 00:00 |
| *** gmann is now known as gmann_afk | 00:07 | |
| *** gmann_afk is now known as gmann | 01:11 | |
| opendevreview | melanie witt proposed openstack/nova master: Add logic to enforce local api and db limits https://review.opendev.org/c/openstack/nova/+/712139 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/c/openstack/nova/+/712142 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/c/openstack/nova/+/712143 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Update limit APIs https://review.opendev.org/c/openstack/nova/+/712707 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/c/openstack/nova/+/712749 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/c/openstack/nova/+/713301 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/c/openstack/nova/+/615180 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271 | 05:49 |
| opendevreview | melanie witt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/c/openstack/nova/+/712142 | 06:53 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/c/openstack/nova/+/712143 | 06:53 |
| opendevreview | melanie witt proposed openstack/nova master: Update limit APIs https://review.opendev.org/c/openstack/nova/+/712707 | 06:53 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/c/openstack/nova/+/712749 | 06:53 |
| opendevreview | melanie witt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/c/openstack/nova/+/713301 | 06:53 |
| opendevreview | melanie witt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/c/openstack/nova/+/615180 | 06:53 |
| opendevreview | melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498 | 06:53 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499 | 06:53 |
| opendevreview | melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271 | 06:53 |
| opendevreview | melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498 | 06:56 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499 | 06:56 |
| opendevreview | melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271 | 06:56 |
| bauzas | good morning Nova | 07:21 |
| *** frickler_ is now known as frickler | 07:25 | |
| gibi | bauzas: good Friday | 07:30 |
| bauzas | indeed | 07:30 |
| bauzas | gibi: looks like the nvme osbrick issue is now fixed | 07:48 |
| gibi | bauzas: os-brick 5.0.1 with the nvme fix and global requirements has been bumped https://review.opendev.org/c/openstack/releases/+/812048/1/deliverables/xena/os-brick.yaml | 07:48 |
| gibi | heh | 07:49 |
| gibi | we looked at it at the same time :D | 07:49 |
| bauzas | the xena backport is now merged https://review.opendev.org/c/openstack/os-brick/+/812010 | 07:49 |
| bauzas | yeah | 07:49 |
| bauzas | I call that "friends" :p | 07:49 |
| gibi | :) | 07:49 |
| bauzas | ok, so should we do something with our requirements ? | 07:50 |
| bauzas | elodilles: thoughts on touching our reqs so close to GA ? | 07:50 |
| gibi | upper constraints are coming from global | 07:50 |
| gibi | an as far as I remember reqs repo hasn't been branched to xena yet | 07:51 |
| gibi | so the merged global req bump is applied to Xena automatically | 07:52 |
| gibi | the only question is, do we want to blacklist os-brick 5.0.0 | 07:52 |
| bauzas | ah good point | 07:52 |
| gibi | and I think we agreed with lyarwood that this is a narrow scoped issue so we don't need to blacklist | 07:52 |
| bauzas | about the merge | 07:52 |
| bauzas | gibi: yeah I think so | 07:53 |
| gibi | then I think we are done | 07:53 |
| bauzas | so let it be | 07:53 |
| bauzas | yeah | 07:53 |
| gibi | it was a nice bug as we needed to do nothing to fix it :D | 07:53 |
| gibi | <3 cinder | 07:53 |
| bauzas | ++ | 07:53 |
| opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Add PCI VPD Capability Handling https://review.opendev.org/c/openstack/nova/+/808199 | 08:59 |
| opendevreview | Dmitrii Shcherbakov proposed openstack/nova master: [yoga] Support remote-managed SmartNIC DPU ports https://review.opendev.org/c/openstack/nova/+/812111 | 08:59 |
| elodilles | bauzas: sorry, missed your question. but yes, as gibi said, it comes from openstack/requirements and RFE was granted for os-brick ( http://lists.openstack.org/pipermail/openstack-discuss/2021-September/025155.html ) | 09:34 |
| lyarwood | bauzas: would you mind hitting https://review.opendev.org/c/openstack/nova/+/811713 and https://review.opendev.org/c/openstack/nova/+/811716 today? | 09:41 |
| opendevreview | Elod Illes proposed openstack/nova stable/ussuri: [stable-only] Pin virtualenv and setuptools https://review.opendev.org/c/openstack/nova/+/810461 | 09:47 |
| kashyap | dmitriis: Hi, from #virt here :) Thanks for reworking the patch and splitting it out. | 09:57 |
| kashyap | Reviewer time is a bit limited these days, so please don't hesitate to re-ping here if you don't get any input in a bit | 09:58 |
| dmitriis | kashyap: ack, will do. Appreciate that it's Xena release time so I'll circle back some time after it's out. | 10:02 |
| opendevreview | Merged openstack/os-traits master: Change minversion of tox to 3.18.0 https://review.opendev.org/c/openstack/os-traits/+/791973 | 10:10 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Enable min pps tempest testing in nova-next https://review.opendev.org/c/openstack/nova/+/811748 | 10:24 |
| lyarwood | tgif++ side_effect != side_effects | 10:52 |
| gibi | +1 on Friday | 10:53 |
| opendevreview | Lee Yarwood proposed openstack/nova master: Add regression test for bug #1937084 https://review.opendev.org/c/openstack/nova/+/812126 | 11:32 |
| opendevreview | Lee Yarwood proposed openstack/nova master: block_device: Ignore VolumeAttachmentNotFound during detach https://review.opendev.org/c/openstack/nova/+/812127 | 11:32 |
| opendevreview | Balazs Gibizer proposed openstack/nova master: Enable min pps tempest testing in nova-next https://review.opendev.org/c/openstack/nova/+/811748 | 12:04 |
| opendevreview | Takashi Natsume proposed openstack/nova master: Update min supported service version for Yoga https://review.opendev.org/c/openstack/nova/+/809932 | 13:09 |
| gmann | melwitt: nova-grenade-multinode passing on stable/train with the devstack fix but devsdtack fix hitting the novnc failure in stable/stein https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_c3f/812092/1/check/tempest-full-py3/c3fde5e/testr_results.html | 13:53 |
| gmann | are those known one? | 13:53 |
| gmann | or gibi lyarwood elodilles ^^ you know about novnc issue ? | 14:17 |
| gibi | does not ring a bell but let me grep a bit | 14:18 |
| elodilles | haven't seen that before | 14:19 |
| gmann | it seems circular deps, nova stable/stein hitting jsonschema issue which devstack fix but there we are hitting novnc | 14:19 |
| opendevreview | Ghanshyam proposed openstack/nova stable/stein: DNM: testing jsonschema version fix https://review.opendev.org/c/openstack/nova/+/812142 | 14:21 |
| gibi | gmann: I found on other hits recently about this | 14:23 |
| gibi | gmann: I see that novncproxy says it is invalid / expired token https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_c3f/812092/1/check/tempest-full-py3/c3fde5e/controller/logs/screen-n-novnc-cell1.txt | 14:25 |
| gibi | but I don't know why | 14:26 |
| gibi | the token should not be expired based on the timestamps in the nova-api and novnc proxy logs | 14:26 |
| gmann | k | 14:29 |
| gibi | I don't see anything else | 14:31 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Enable auto-generation of API DB migrations https://review.opendev.org/c/openstack/nova/+/812144 | 14:34 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove unused build_requests columns https://review.opendev.org/c/openstack/nova/+/812145 | 14:34 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove legacy placement models https://review.opendev.org/c/openstack/nova/+/812146 | 14:34 |
| opendevreview | Stephen Finucane proposed openstack/nova master: objects: Stop querying the main DB for keypairs https://review.opendev.org/c/openstack/nova/+/812147 | 14:34 |
| opendevreview | Stephen Finucane proposed openstack/nova master: objects: Remove 'bandwidth' fields from notifications https://review.opendev.org/c/openstack/nova/+/812148 | 14:34 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove models that were moved to the API database https://review.opendev.org/c/openstack/nova/+/812149 | 14:34 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove models for removed services, features https://review.opendev.org/c/openstack/nova/+/812150 | 14:34 |
| opendevreview | Stephen Finucane proposed openstack/nova master: db: Remove nova-network models https://review.opendev.org/c/openstack/nova/+/812151 | 14:34 |
| opendevreview | Stephen Finucane proposed openstack/nova master: WIP: objects: Prepare for Instance, InstanceList v3 https://review.opendev.org/c/openstack/nova/+/812152 | 14:34 |
| opendevreview | Stephen Finucane proposed openstack/nova master: WIP: objects: Add Instance, InstanceList v3 https://review.opendev.org/c/openstack/nova/+/812153 | 14:34 |
| stephenfin | FYI, those patches are me stress testing the alembic infrastructure and fixing things I find along the way. Would be useful to merge early in Yoga (i.e. starting next week?) to give us loads of time to resolve any potential fallout :) | 14:42 |
| gibi | stephenfin: ack, good point | 14:48 |
| *** tbachman is now known as Guest1503 | 14:54 | |
| spatel | Folk, not sure what i should look for but we have same hardware on both cloud but local storage showing different result - https://paste.opendev.org/show/809727/ | 15:06 |
| spatel | I don't have any option configure here on both clouddisk_cachemodes = | 15:09 |
| artom_ | bauzas, around? Does https://bugs.launchpad.net/nova/+bug/1944947 and the fix at https://review.opendev.org/c/openstack/nova/+/810849 qualify as a review-priority bug? | 15:12 |
| bauzas | still there | 15:12 |
| artom_ | Seems pretty important to be able to restart hw:cpu_policy=dedicated instances after an upgrade :) | 15:12 |
| *** artom_ is now known as artom | 15:13 | |
| bauzas | artom: any bug seems to me nice to review | 15:13 |
| bauzas | so +1 on R-P labeling | 15:13 |
| artom | priteau, btw, are you good to continue the patch above? ^^ It's basically just missing unit tests | 15:13 |
| artom | Or would you want someone more experienced with Nova to take over? | 15:13 |
| bauzas | well, we can mentor priteau, I'm sure :) | 15:14 |
| priteau | Hi artom. Sorry, been quite busy so I haven't looked into it yet. | 15:14 |
| bauzas | any new contributor is appreciated :) | 15:14 |
| bauzas | (even if pierre isn't exactly new to me :D ) | 15:14 |
| priteau | I can try to add unit tests, if I can't figure it out I'll ask for help | 15:15 |
| artom | bauzas, yep, I'm happy either way, just interested in keeping things moving | 15:15 |
| bauzas | priteau: sure, you are 1 hour away from my usual time, so you can ping me for help | 15:16 |
| bauzas | I could redirect | 15:16 |
| priteau | bauzas: Actually I live in France now ;-) | 15:16 |
| bauzas | heh, I see the French mafia growing | 15:16 |
| priteau | I've actually thought about an issue with the whole migration approach (including the existing function) | 15:16 |
| priteau | It updates the object but not the version number field | 15:17 |
| priteau | Is this likely to be an issue? | 15:17 |
| priteau | With the existing code, a pinned instance started on Ussuri would have a 1.4 InstanceNUMACell object | 15:18 |
| artom | priteau, that's an excellent question, actually. I suspect there's magic in the ovo code that does it automatically? | 15:18 |
| * artom calls forth dansmith | 15:18 | |
| * dansmith reads | 15:19 | |
| bauzas | well, I need more context | 15:19 |
| dansmith | I'm not sure what the question is | 15:20 |
| bauzas | we only update the object is something remotable is added | 15:20 |
| bauzas | the object version* | 15:20 |
| artom | dansmith, the context is https://review.opendev.org/c/openstack/nova/+/810849/2/nova/objects/instance_numa.py, and the question is, won't that leave the InstanceNUMACell as version 1.4 in the DB, even if we added the pcpuset and migrated to 1.5 | 15:20 |
| bauzas | artom: is the pcpuset attribute a ovo field ? | 15:21 |
| artom | It's a SetOfIntegersField | 15:21 |
| bauzas | lemme find this object | 15:21 |
| bauzas | the whole module is too large | 15:22 |
| bauzas | ok, I see it | 15:22 |
| bauzas | so, yeah this field exists | 15:22 |
| bauzas | why should we bump the object version ? | 15:22 |
| dansmith | artom: you're asking if you deserialize, tweak and re-serialize, if you'll serialize the 1.4 version that came from the original thing? | 15:22 |
| artom | dansmith, aye | 15:23 |
| artom | Tweak specifically by adding the field that was added in the 1.5 version | 15:23 |
| bauzas | artom: then the remote object won't get it | 15:23 |
| dansmith | no, when you deserialize an object, it becomes a 1.5, which is why you have to be compatible with your object changes | 15:24 |
| dansmith | the new field will be unset because it came from a 1.4, but when you re-serialize it, you'll use the current version unless you ask for an older one (like conductor does when it backports changes for you) | 15:24 |
| priteau | I've just looked at a production system with pinned-instances launched on Train, the system now being on Victoria. The InstanceNUMACell objects are actually showing "nova_object.version": "1.6" | 15:24 |
| priteau | So it looks OK | 15:25 |
| bauzas | wait | 15:25 |
| bauzas | you lost me | 15:25 |
| artom | priteau, cool, so you confirmed in a real system the mechanism that dansmith explained \o/ | 15:25 |
| bauzas | who's on 1.5 (or later) and who's on 1.4 ? | 15:25 |
| dansmith | bauzas: Who is on first | 15:25 |
| * bauzas gets an headache | 15:26 | |
| bauzas | dansmith: that's what I'm asking | 15:26 |
| bauzas | but it looks it works, so meh | 15:26 |
| priteau | 1.4 are pre-Victoria objects. 1.5, actually none because 1.6 was also introduced in Victoria. Any instance launched or restarted on Victoria gets 1.6 (but only for cpu_policy=dedicated, which is the problem) | 15:27 |
| dansmith | artom: I might actually be wrong here, I' | 15:27 |
| priteau | Anyway, there is no problem with the version number, I just wasn't aware of the nova magic | 15:27 |
| dansmith | I'm looking hang on | 15:27 |
| bauzas | priteau: so, you're asking about what would happen with an old compute and a Victoria conductor or compute, I guess | 15:28 |
| bauzas | dansmith explained it very pretty well | 15:28 |
| bauzas | when you serialize, you add the object version | 15:28 |
| bauzas | so any reader getting the serialized object would know the version and creates a new object based on the compatibility methods we provide | 15:29 |
| bauzas | keeping in mind that obj 1.X doesn't know what to do with 1.y if y > x | 15:30 |
| dansmith | soooo, | 15:30 |
| dansmith | I'm actually not sure this behaves the way I thought.. I don't actually know that it matters, but I think it might be different | 15:30 |
| dansmith | it looks like we _will_ preserve the inbound version that we got from the serialized form when we re-serialize, | 15:31 |
| dansmith | which I think we do for the purposes of not up-leveling objects if we're newer than others in the cluster | 15:31 |
| dansmith | i.e. to avoid a new conductor up-leveling an old version that an api sent to it, knowing an old compute will need the old version | 15:32 |
| dansmith | and also I guess to avoid upleveling something in the database when we load/save it if we're not ready to roll everyone forward yet | 15:32 |
| dansmith | but, the behavior you notice is not the version, it's whether or not the field sticks, which is what I was focusing on, and I think it will, even though that doesn't match the version | 15:32 |
| dansmith | meaningm | 15:32 |
| artom | dansmith, wouldn't upleveling not be a problem because we have code to make it compatible to old versions? | 15:33 |
| dansmith | if you store the object with the new field, it will serialize the new field even if the version is wrong, and a newer node will still pull it out because it doesn't know which version the field belongs to | 15:33 |
| artom | So if the conductor uplevels something, then an old compute loads, it will automatically downlevel for that compute? | 15:33 |
| dansmith | artom: well, I picked conductor because it was easy, but imagine two computes talking | 15:34 |
| dansmith | so I'm not actually sure I can explain priteau's observation of the new versions | 15:35 |
| dansmith | that's how I recalled it working, but I can't back that up with references to the code purely in the deserialization/serialization stuff | 15:36 |
| priteau | These instances were live migrated after the Victoria upgrade, could it explain it? | 15:36 |
| dansmith | do we recreate the numa objects as part of another operation? yeah, like live migration | 15:36 |
| dansmith | this is the test that proves that we don't automatically uplevel it: https://github.com/openstack/oslo.versionedobjects/blob/e7b6d52aa4b1b40e68a21a122c09b968d5959b0e/oslo_versionedobjects/tests/test_objects.py#L778-L785 | 15:38 |
| dansmith | which isn't how I remembered it, but re-reading that test jogs my memory about why | 15:38 |
| dansmith | so I think technically that operation should do something like object.VERSION = ObjectClass.VERSION when it goes to save it out | 15:40 |
| artom | So the upleveling happens at serialization then? | 15:46 |
| artom | Or some other operation like live migration, as you've said | 15:46 |
| dansmith | it doesn't | 15:47 |
| artom | But not at de-serialization, at any rate | 15:47 |
| dansmith | I'm thinking live migrations create new numa stuff for the new host and that's how those got updated | 15:47 |
| dansmith | in the past, we've done things like "load and save the object to update it" which would run routines to do updates, but they are probably saving the objects back with the old version but including the updates :/ | 15:48 |
| dansmith | I can't find any VERSION updating going on in the tree right now | 15:48 |
| dansmith | like for online data migrations I mean | 15:48 |
| dansmith | technically it probably hasn't mattered, because who (besides artom and priteau) would notice that the version was wrong if the data was right? :) | 15:49 |
| artom | Yeah, maybe it's an academic debate - if it does the right thing... | 15:49 |
| artom | Which it appears to do | 15:50 |
| priteau | I just wanted to check it wouldn't break anything if the version number was not updated | 15:50 |
| dansmith | well, we shouldn't store the version incorrectly just because that's going to be confusing, but yeah the object would still load with the data we wanted so in practice it hasn't mattered | 15:50 |
| dansmith | priteau: right, but we should fix it to update the version though | 15:50 |
| priteau | I will leave that to you if you don't mind :D | 15:52 |
| dansmith | artom: do you want me to do that or will you? | 15:52 |
| artom | dansmith, do what? What priteau said, "fix it to update the version though"? | 15:53 |
| artom | Wouldn't that be within priteau own's patch? | 15:53 |
| artom | Well, maybe not, since the on-load migration is pre-existing... | 15:53 |
| dansmith | artom: I said it, but no, the code that claims to migrate is already in the tree | 15:53 |
| dansmith | right | 15:53 |
| artom | He's just fixin it | 15:53 |
| dansmith | right | 15:53 |
| dansmith | looks like there are several _migrate_* cases in instance_numa.py | 15:54 |
| artom | And probably elsewhere... | 15:54 |
| dansmith | maybe, not sure | 15:54 |
| dansmith | if you do it I can review/+2 but ... :) | 15:54 |
| artom | I mean, the hint of a +2 from dansmith on a PS1 is pretty alluring... | 15:55 |
| dansmith | well, if you get it right in PS1.. :P | 15:55 |
| artom | Crazier things have happened | 15:56 |
| dansmith | let me write you a diff to start, hang on | 15:56 |
| dansmith | I think this should be unified instead of done in multiple places like it is, so something like this: https://termbin.com/iawkf | 15:58 |
| dansmith | oh, you know what, | 15:59 |
| dansmith | the other migrate routine is for non-ovo migrations, | 15:59 |
| dansmith | which is different, so probably no need to break out that helper function anyway | 15:59 |
| dansmith | so just the one line VERSION thing plus an assert in whatever tests this and you're probably good | 16:00 |
| artom | Oh I see (I think), your initial thought was "have any on-load migration call to a helper that updates version to latest" | 16:02 |
| dansmith | yeah, because I thought there were at least two, | 16:02 |
| dansmith | but that's because I didn't read | 16:02 |
| * bauzas gave up and TGIF so bye and thanks all for the fish | 16:02 | |
| artom | Yeah makes sense | 16:04 |
| artom | My stomach is requiring food, I think lunch first, patch after | 16:04 |
| dansmith | I +2 that ordering | 16:04 |
| artom | \o/ | 16:05 |
| *** tbachman is now known as Guest1510 | 16:16 | |
| melwitt | gmann: no I was not aware of the novnc fail, I will look at it | 16:48 |
| gmann | melwitt: thanks. | 16:52 |
| -opendevstatus- NOTICE: The review.opendev.org Gerrit server has become unreachable as of approximately 19:10 UTC due to a networking issue in the provider, but should be reachable again shortly | 19:45 | |
| melwitt | gmann: just to update you, I know what is wrong but I don't find how it's happening yet. tl;dr is the "path" in the vnc proxy is wrong and doesn't contain the token (so it's not even validating a token). according to all of the config files I looked at, it should be working. so there is something I'm missing so far | 20:00 |
| melwitt | this is an example of how the path is supposed to look: https://zuul.opendev.org/t/openstack/build/2a183ce6e15f4ab08d31190d4d286a7b/log/controller/logs/screen-n-novnc-cell1.txt#11 | 20:01 |
| melwitt | and this is the bad one that's failing: https://zuul.opendev.org/t/openstack/build/9234f33acf1247cdb995416ca9389240/log/controller/logs/screen-n-novnc-cell1.txt#13 | 20:01 |
| melwitt | this is where it would pick up the "path" variable https://github.com/novnc/noVNC/blob/v0.4/vnc_auto.html#L106 | 20:04 |
| opendevreview | melanie witt proposed openstack/nova master: Add logic to enforce local api and db limits https://review.opendev.org/c/openstack/nova/+/712139 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: Enforce api and db limits https://review.opendev.org/c/openstack/nova/+/712142 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota_class APIs for db and api limits https://review.opendev.org/c/openstack/nova/+/712143 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: Update limit APIs https://review.opendev.org/c/openstack/nova/+/712707 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota sets APIs https://review.opendev.org/c/openstack/nova/+/712749 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: Tell oslo.limit how to count nova resources https://review.opendev.org/c/openstack/nova/+/713301 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: Enforce resource limits using oslo.limit https://review.opendev.org/c/openstack/nova/+/615180 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: Add legacy limits and usage to placement unified limits https://review.opendev.org/c/openstack/nova/+/713498 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: Update quota apis with keystone limits and usage https://review.opendev.org/c/openstack/nova/+/713499 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: Add reno for unified limits https://review.opendev.org/c/openstack/nova/+/715271 | 22:45 |
| opendevreview | melanie witt proposed openstack/nova master: DNM Run against unmerged oslo.limit changes https://review.opendev.org/c/openstack/nova/+/812236 | 22:45 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!