From 42ccae57ab05ecc8738ab61ee72ad86a7c1feedc Mon Sep 17 00:00:00 2001 From: Gerrit User 4393 <4393@4a232e18-c5a9-48ee-94c0-e04e7cca6543> Date: Wed, 24 Jan 2024 15:50:34 +0000 Subject: [PATCH] Update patch set 1 Patch Set 1: (8 comments) Patch-set: 1 CC: Gerrit User 4393 <4393@4a232e18-c5a9-48ee-94c0-e04e7cca6543> Attention: {"person_ident":"Gerrit User 9708 \u003c9708@4a232e18-c5a9-48ee-94c0-e04e7cca6543\u003e","operation":"ADD","reason":"\u003cGERRIT_ACCOUNT_4393\u003e replied on the change"} --- 8487cb0bd57caf9f881457b38a5e77a6e88733cd | 143 +++++++++++++++++++++++ 1 file changed, 143 insertions(+) diff --git a/8487cb0bd57caf9f881457b38a5e77a6e88733cd b/8487cb0bd57caf9f881457b38a5e77a6e88733cd index b27162323..1ba40260f 100644 --- a/8487cb0bd57caf9f881457b38a5e77a6e88733cd +++ b/8487cb0bd57caf9f881457b38a5e77a6e88733cd @@ -372,6 +372,23 @@ "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" }, + { + "unresolved": true, + "key": { + "uuid": "ecc28e0a_05b68e17", + "filename": "specs/backlog/nova-dynamic-cpus.rst", + "patchSetId": 1 + }, + "lineNbr": 319, + "author": { + "id": 4393 + }, + "writtenOn": "2024-01-24T15:50:34Z", + "side": 1, + "message": "How did this jump from 0 to 4 here?", + "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, { "unresolved": true, "key": { @@ -389,6 +406,23 @@ "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" }, + { + "unresolved": true, + "key": { + "uuid": "580557b4_df01d708", + "filename": "specs/backlog/nova-dynamic-cpus.rst", + "patchSetId": 1 + }, + "lineNbr": 455, + "author": { + "id": 4393 + }, + "writtenOn": "2024-01-24T15:50:34Z", + "side": 1, + "message": "I think the ghost of jaypipes would say that this means you\u0027re using it wrong (i.e. because you\u0027re representing one set of hardware with twice the inventory). Personally I think any plan that goes down that road is a regression from where we\u0027ve been trying to get to with placement and our usage of it.", + "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, { "unresolved": true, "key": { @@ -406,6 +440,115 @@ "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" }, + { + "unresolved": true, + "key": { + "uuid": "026952c2_325f54dc", + "filename": "specs/backlog/nova-dynamic-cpus.rst", + "patchSetId": 1 + }, + "lineNbr": 465, + "author": { + "id": 4393 + }, + "writtenOn": "2024-01-24T15:50:34Z", + "side": 1, + "message": "Maybe I\u0027m missing something, but this seems like it\u0027s representing the same resources with double the inventory. Won\u0027t conductor/scheduler be over-allocating instances for the compute, especially if there\u0027s a flood of boot requests? Put another way, before the compute has a chance to twiddle the inventory to reflect reality after each boot, anything looking at only the placement inventory will not give an accurate picture.", + "parentUuid": "68f5599a_86df508f", + "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, + { + "unresolved": true, + "key": { + "uuid": "43e628af_21e5f5f2", + "filename": "specs/backlog/nova-dynamic-cpus.rst", + "patchSetId": 1 + }, + "lineNbr": 477, + "author": { + "id": 4393 + }, + "writtenOn": "2024-01-24T15:50:34Z", + "side": 1, + "message": "I think this paragraph is really saying \"well, we can\u0027t be positive that an instance will fit, making it less accurate (or more lossy) isn\u0027t bad.\" I don\u0027t think I agree.", + "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, + { + "unresolved": true, + "key": { + "uuid": "fd191732_8cc85566", + "filename": "specs/backlog/nova-dynamic-cpus.rst", + "patchSetId": 1 + }, + "lineNbr": 487, + "author": { + "id": 4393 + }, + "writtenOn": "2024-01-24T15:50:34Z", + "side": 1, + "message": "It also means the compute can get hammered by multiple scheduler/conductor processes asking \"does this fit?\" during a massive boot request storm.", + "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, + { + "unresolved": true, + "key": { + "uuid": "16428a35_fe33b75d", + "filename": "specs/backlog/nova-dynamic-cpus.rst", + "patchSetId": 1 + }, + "lineNbr": 499, + "author": { + "id": 4393 + }, + "writtenOn": "2024-01-24T15:50:34Z", + "side": 1, + "message": "I think this approach would require fully exposing all the compute details so that a conductor can make that decision right?", + "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, + { + "unresolved": true, + "key": { + "uuid": "3a92441b_b1330e9a", + "filename": "specs/backlog/nova-dynamic-cpus.rst", + "patchSetId": 1 + }, + "lineNbr": 511, + "author": { + "id": 4393 + }, + "writtenOn": "2024-01-24T15:50:34Z", + "side": 1, + "message": "\"cpus\" ?", + "range": { + "startLine": 511, + "startChar": 71, + "endLine": 511, + "endChar": 80 + }, + "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, + { + "unresolved": true, + "key": { + "uuid": "9971e461_543ce7cf", + "filename": "specs/backlog/nova-dynamic-cpus.rst", + "patchSetId": 1 + }, + "lineNbr": 570, + "author": { + "id": 4393 + }, + "writtenOn": "2024-01-24T15:50:34Z", + "side": 1, + "message": "I\u0027m not sure how I feel about changing this. For a single-vendor cloud, Nova is just IaaS and multi-tenancy constraints like this are just \"limitations\" to the operator. I agree that we don\u0027t do this sort of thing today, and that doing in the future is a fundamental change in how nova behaves (both from the multitenancy concern _and_ the PoV that we \"don\u0027t do orchestration.\").", + "revId": "8487cb0bd57caf9f881457b38a5e77a6e88733cd", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543" + }, { "unresolved": true, "key": {