Update patch set 1
Patch Set 1: (6 comments) Patch-set: 1 Label: Verified=0
This commit is contained in:
Gerrit User 9545
Gerrit Code Review
parent
fd2332ee6e
commit
7ca8e93d6f
|
|
@ -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",
|
||||
|
|
|
|||
Loading…
Reference in New Issue