ahgittin commented on PR #1389:
URL: https://github.com/apache/brooklyn-server/pull/1389#issuecomment-1560901120
@jcabrerizo You are right, this makes a huge difference, and I agree with
you it's the correct balance where we do it.
In fact I've extended it a bit, and tidied, in 2d6e8cdc40, as follows:
Use this in a few more places:
* exclude detail from tasks when doing a recursive/children lookup
* filter output fields in tasks when detail is excluded
* filter output fields from children and recursive task requests by default
* filter output fields for selected sensors (name starts with "internal")
when doing a batch read of sensors (this affects the workflow cache which
contains all output)
* also filter various `content...` fields used by the `http` workflow step
And some tidying/tweaks:
* change name of methods and params - call it filterOutputFields instead of
suppressOutput (to me, suppress hints at security)
* expose the capability on the generic resolver (used for the sensors above)
* when doing the filter, don't bother if it's short/trivial, and if it's not
a string include the type for info
* change implementation of filter to run even if suppress secrets is false
* (in UI, remove one redundant activities call)
I did a simple test by adding these lines to the `SimpleBlueprintTest` then
attaching a UI and looking at network size:
```
WorkflowYamlTest.addWorkflowTypes(mgmt);
Application app1 = runTestOnBlueprint("services: [ { type: " +
WorkflowSoftwareProcess.class.getName() + ", location: localhost } ]");
WorkflowBasicTest.runWorkflow(app1.getChildren().iterator().next(),
Strings.lines("steps:",
" - ssh aws cloudformation describe-stacks"), "cfn");
WorkflowBasicTest.runWorkflow(app1.getChildren().iterator().next(),
Strings.lines("steps:",
" - ssh aws cloudformation describe-stacks"), "cfn2");
WorkflowBasicTest.runWorkflow(app1.getChildren().iterator().next(),
Strings.lines("steps:",
" - ssh aws cloudformation describe-stacks"), "cfn3");
```
The impact is huge:
* 3 med size workflows - call to list - reduced from 126kb to 2kb
* recursive task call for the above - from 25k to 5k
* sensor batch read - from 120k to 2k
* details of 1 workflow - 42kb to access (unchanged)
It doesn't address the huge size of persistence but I will add a section to
the docs on workflow for that.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@brooklyn.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
