Grap SVG error and extreme network utilization from console about caldera HOT 3 CLOSED

Ok, some additional data. The repeated calls to the operations and summary API endpoints only happen if you navigate to the operations page, then select an operation off the dropdown menu. If you delete a record or otherwise don't have one already selected the constant reloading doesn't occur.

I've also cut the amount of data it's trying to pull back every time from the operations endpoint somewhat by culling old records I don't need any longer.

from caldera.

Yeah, the overall bandwidth requirement was due in large part to the amount of data returned from the api/v2/operations endpoint combined with a crazy fast polling period. Since I'm still testing this out I had hundreds of test iterations, some of which with hundreds of individual lines. It was like 10 megabytes each time it gets called and easily a hundred times in a minute.

I used some PS scripting to bulk remove (what happened to being able to kill YML files??) that makes the console usable again.

$API_KEY = "xxxxxxxxxxxxxxxxxxxx"
$uri = "https://xxxxxxxxxxxxxxxxxxxxxxxx/api/v2/operations"
$headers = @{
    KEY = $API_KEY
}
$operations = Invoke-RestMethod -Uri $uri -Method GET -Headers $headers

foreach ( $operation in $operations ) {
    # if the operation name field contains the word "test" then remove it 
    #if ($operation.name -match "test") {
    write-output "Removing $($operation.name)"
    $opToRemove = $operation.id 
    $uri = "https://xxxxxxxxxxxxxx/api/v2/operations/$opToRemove"
    Invoke-RestMethod -Uri $uri -Method DELETE -Headers $headers
    write-output ==========
    #}
    #$operation.id 
}

from caldera.

There's an issue with the operations API endpoint returning a ton of data and having a fast polling cycle in the current Magma release.. I've addressed it on my local instance in MAGMA#51. Long term fix should be a process that only polls changes IMO.

from caldera.