-
Notifications
You must be signed in to change notification settings - Fork 16
Add FIDESOPS__DEV_MODE for Easier SaaS Request Debugging #363
Conversation
- No retries - Exceptions are not caught; entire traceback is logged. - Details of saas requests are logged - path, headers, body.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will make iterating on SaaS connectors so much easier, very excited to get this one in!
Re: hot reloading, I'm all for it. I don't foresee a scenario where wouldn't want it, unless anyone sees differently? |
well hot reloading can be a little annoying if you're running multiple privacy requests at a time and uploading the results to a local folder. The sar results themselves trigger a reloading, which can prevent the other privacy requests from executing. This came up when we were testing too many connections getting opened up in fidesops. To be clear, I'm not introducing hot reloading, it's just that hot reloading already looks at the "DEV_MODE" variable. I'm proposing having hot reloading look at HOT_RELOAD and dev mode look at DEV_MODE. |
… to not get mixed up with other services.
…On Python 3 '{}'.format(b'abc') produces "b'abc'", not 'abc'; use '{!r}'.format(b'abc') if this is desired behavior
| `LOG_PII` | False | If this is set to "True", pii values will display unmasked in log output. This variable should always be set to "False" in production systems.| | ||
| `DEV_MODE` | False | If "True", the fidesops server will run with hot-reloading of files. This variable should always be set to "False" in production systems.| | ||
| `FIDESOPS_LOG_PII` | False | If this is set to "True", pii values will display unmasked in log output. This variable should always be set to "False" in production systems. | ||
| `FIDESOPS_HOT_RELOAD` | False | If "True", the fidesops server will run with hot-reloading of files. This variable should always be set to "False" in production systems.| |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm pretty sure hot reloading
is a well understood term, but it might be good to add a sentence explaining that just in case?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good suggestion
src/fidesops/core/config.py
Outdated
f"Startup configuration: reloading = {hot_reloading}, dev_mode = {dev_mode}" | ||
) | ||
logger.warning( | ||
f'Startup configuration: pii logging = {os.getenv("FIDESOPS_LOG_PII") == "True"}' |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should these only warn under certain circumstances? For instance if log pii, dev mode or hot reloading is true? In theory if those aren't true, there's nothing to warn about
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I mean, up to you, I like seeing the "Startup configuration" regardless of whether it's true or false, we could change it to be a logger.info?
raise ConnectionException(f"Operational Error connecting to '{self.key}'.") | ||
except Exception as exc: # pylint: disable=W0703 | ||
if config.dev_mode: # pylint: disable=R1720 | ||
raise exc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We probably still want to log here which key Fidesops is failing to connect to, unless it appears in the stack trace?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good improvement, that probably won't be in the trace without adding it.
@@ -178,14 +178,17 @@ class FidesopsConfig(FidesSettings): | |||
execution: ExecutionSettings | |||
|
|||
is_test_mode: bool = os.getenv("TESTING") == "True" | |||
hot_reloading: bool = os.getenv("DEV_MODE") == "True" | |||
hot_reloading: bool = os.getenv("FIDESOPS_HOT_RELOAD") == "True" | |||
dev_mode: bool = os.getenv("FIDESOPS_DEV_MODE") == "True" | |||
|
|||
class Config: # pylint: disable=C0115 | |||
case_sensitive = True |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we'll need to add env_prefix = FIDESOPS_
for this to work being able to reference these vars as FIDESOPS_VAR_NAME
? We should use FIDESOPS__
as the prefix though, since that's consistent with the sub-sections above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added an extra underscore, I was following the FIDESOPS_CONFIG_PATH variable, so I've updated that to also have double underscores.
… adjusts existing FIDESOPS__CONFIG_PATH. - Explain hot reloading. - When logging original exception for saas requests, also log the key.
thanks for your comments @seanpreston |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like everyone's had a chance to comment on so we're ready to merge!
Adding DEV_MODE for easier debugging of SaaS requests
Adding DEV_MODE for easier debugging of SaaS requests
Purpose
It sounds like most devs have to do some adjusting of their local environment during development to help with debugging. We intentionally suppress a lot of details that would help with troubleshooting.
In the shell, do
export FIDESOPS__DEV_MODE="TRUE"
. Runmake server
and then run a traversal that has saas requests via postman.This gives you:
Changes
Up for discussion - this is something that is useful for me during debugging, but others may not want this behavior. We might add a follow-up ticket for logging more database details too, this is just because we've been focused on saas details lately.
Checklist
Run Unsafe PR Checks
label has been applied, and checks have passed, if this PR touches any external servicesTicket
Fixes #