rds: Added a verbose option to extract additional debug information#196
rds: Added a verbose option to extract additional debug information#196brenns10 merged 1 commit intooracle-samples:mainfrom
Conversation
oracle-contributor-agreement
Bot
added
the
OCA Verified
Hannibal404
force-pushed
the
rds_verbose
branch
from
1668fda to
f946fb9
Compare
| if args.verbose: | ||
| with open("conn_structure_dump.txt", "a") as f: |
There was a problem hiding this comment.
If this function is to be used within corelens, then it cannot create files at random in the current directory. Corelens output should be controlled by the corelens CLI. Given that corelens is normally run as root, creating a file unexpectedly in the current directory could be dangerous.
I see four possibilities:
- In verbose mode, print the output to stdout, not a new file.
- In verbose mode, print to this file as you currently have it. But change the corelens module so that it passes
verbose=Falsealways. This avoids corelens users getting unexpected output. - Move this verbose output to a new function (with
@redirectable). Call it from the corelens module during verbose mode. Your scripts can call this function separately and use@redirectableto control its output. - Introduce some new API from corelens that allows one corelens module to have multiple output files or output sections.
Honestly, any of these is fine with me.
There was a problem hiding this comment.
Going forward with 2
There was a problem hiding this comment.
I'm not sure that this is resolved - the key point of option 2 was that the corelens module should never enable the verbose mode that creates this file. As of now, it does when the user passes --verbose.
Corelens modules must not create arbitrary output files. All output is controlled by the corelens CLI flags. Corelens modules just print to stdout, which will be redirected accordingly by the CLI.
If a customer runs this module, they should not end up with a root-owned file conn_structure_dump.txt in the working directory. That's unexpected, and it's a bug. If the customer was generating a report with -o, then this file won't get included in the report, because it gets written into the current working directory, not the output directory. And if the customer was printing the output to stdout, then no files should be created at all!
It's okay for this function to be able to create the file if that's what you want for your analysis scripts, but the behavior cannot be exposed via corelens. If you want it exposed via corelens, then it needs to be printed together with the same output stream that the rest of the output goes to, or we'll need to make an API for corelens modules to write output to ancillary files. I'm happy to help with this API if that's what we need.
There was a problem hiding this comment.
simply printing the verbose output now instead of rerouting to a new file
Hannibal404
force-pushed
the
rds_verbose
branch
from
f946fb9 to
775647d
Compare
The "verbose" option is added to the drgn RDS helper to extract data that is not required in general, but can help get the exact state of different objects of an RDS connection if needed. Signed-off-by: Anand Khoje <anand.a.khoje@oracle.com> Signed-off-by: Pradyumn Rahar <pradyumn.rahar@oracle.com>
Hannibal404
force-pushed
the
rds_verbose
branch
from
775647d to
caa59ba
Compare
2 participants
The "verbose" option is added to the drgn RDS helper to extract data that is not required in general, but can help get the exact state of different objects of an RDS connection if needed.