From 7ca8e93d6fd8a2b1161832d6c25c4229b77fdf00 Mon Sep 17 00:00:00 2001 From: Gerrit User 9545 <9545@4a232e18-c5a9-48ee-94c0-e04e7cca6543> Date: Mon, 13 Nov 2017 13:55:34 +0000 Subject: [PATCH] Update patch set 1 Patch Set 1: (6 comments) Patch-set: 1 Label: Verified=0 --- 4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee | 120 +++++++++++++++++++++++ 1 file changed, 120 insertions(+) diff --git a/4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee b/4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee index 7ecff37..cdb4153 100644 --- a/4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee +++ b/4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee @@ -17,6 +17,24 @@ "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", "unresolved": false }, + { + "key": { + "uuid": "1f485f77_8794eb8c", + "filename": "nova/vms_stats.py", + "patchSetId": 1 + }, + "lineNbr": 93, + "author": { + "id": 9545 + }, + "writtenOn": "2017-11-13T13:55:34Z", + "side": 1, + "message": "\u003e Is this something that we anticipate that might run continuously on a HV?\n\nyup\n\n\u003e Any thought around network stats?\n\nyes, I think it can be easily added as well. But I\u0027m confused with it as like with CPU - I can not come up with a condition for alert about over-use.\n\n\u003e I\u0027m wondering if this output could \"ultimately\" (but maybe not now) be pushed onto a queue for something to consume. Or maybe a output format that some other process could pick up and aggregate/publish?\n\nI think we can put logs to stderr by default and use stdout for json-like messages with stats.\n\nThoughts?\n\nOr simple put/post requests can be used (make the format configurable).", + "parentUuid": "1f485f77_e355f31e", + "revId": "4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", + "unresolved": false + }, { "key": { "uuid": "1f485f77_e35f330c", @@ -52,6 +70,24 @@ "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", "unresolved": false }, + { + "key": { + "uuid": "1f485f77_4c5178d8", + "filename": "nova/vms_stats.py", + "patchSetId": 1 + }, + "lineNbr": 107, + "author": { + "id": 9545 + }, + "writtenOn": "2017-11-13T13:55:34Z", + "side": 1, + "message": "Done", + "parentUuid": "1f485f77_e35f330c", + "revId": "4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", + "unresolved": false + }, { "key": { "uuid": "1f485f77_23730bea", @@ -75,6 +111,30 @@ "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", "unresolved": false }, + { + "key": { + "uuid": "1f485f77_e7dcbf47", + "filename": "nova/vms_stats.py", + "patchSetId": 1 + }, + "lineNbr": 119, + "author": { + "id": 9545 + }, + "writtenOn": "2017-11-13T13:55:34Z", + "side": 1, + "message": "seconds. will update the doc above.", + "parentUuid": "1f485f77_23730bea", + "range": { + "startLine": 115, + "startChar": 3, + "endLine": 119, + "endChar": 46 + }, + "revId": "4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", + "unresolved": false + }, { "key": { "uuid": "1f485f77_23d9cb82", @@ -175,6 +235,24 @@ "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", "unresolved": false }, + { + "key": { + "uuid": "1f485f77_cc5e88e5", + "filename": "nova/vms_stats.py", + "patchSetId": 1 + }, + "lineNbr": 172, + "author": { + "id": 9545 + }, + "writtenOn": "2017-11-13T13:55:34Z", + "side": 1, + "message": "Done", + "parentUuid": "1f485f77_63a903de", + "revId": "4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", + "unresolved": false + }, { "key": { "uuid": "1f485f77_63390340", @@ -198,6 +276,30 @@ "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", "unresolved": false }, + { + "key": { + "uuid": "1f485f77_ac734c80", + "filename": "nova/vms_stats.py", + "patchSetId": 1 + }, + "lineNbr": 270, + "author": { + "id": 9545 + }, + "writtenOn": "2017-11-13T13:55:34Z", + "side": 1, + "message": "Done", + "parentUuid": "1f485f77_63390340", + "range": { + "startLine": 270, + "startChar": 18, + "endLine": 270, + "endChar": 22 + }, + "revId": "4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", + "unresolved": false + }, { "key": { "uuid": "1f485f77_0307ef1e", @@ -215,6 +317,24 @@ "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", "unresolved": false }, + { + "key": { + "uuid": "1f485f77_279bf7c9", + "filename": "nova/vms_stats.py", + "patchSetId": 1 + }, + "lineNbr": 401, + "author": { + "id": 9545 + }, + "writtenOn": "2017-11-13T13:55:34Z", + "side": 1, + "message": "\u003e So, from that I see there is a disk, memory, and cpu thread spawned for each VM. For a Hypervisor that contains say 50 VMs, we\u0027d be having 150 threads spawned/running?\n\nyup. I suppose it should not create a big overhead (cpu\u0026ram load). At least, such behavior, imo, has more positives. I mean in case of \"guestfs\" mode, checking of one VM can take much time and one vm can block others for minutes (for hours?!)\n\n\u003eAlso, with launching the threads together, we could have times when all \"disk\" threads intervals expire together (and thus have a stampede effect). Wonder if there is a way to stagger the threads?\n\nyup, good note. Added a small sleep interval between checking VMs to unsync these.", + "parentUuid": "1f485f77_0307ef1e", + "revId": "4cb3ddaa6dc8b373b03989f1ee97f1b75f6451ee", + "serverId": "4a232e18-c5a9-48ee-94c0-e04e7cca6543", + "unresolved": false + }, { "key": { "uuid": "1f485f77_836f5fc4",