|
Yeah, it's OK by me. There's an outside chance we get a confused call from a customer running directory-per-db because the watchdog didn't watch all their volumes, but we can deal with that via human interaction. We should make sure the documentation indicates the limitation wrt directory-per-db and close this ticket.
|
|
alyson.cabral, schwerin during our 6-six week review, we came across a goal in the "Move Storage Node Watchdog to community" scope that said the watchdog should be restricted to only a specific configuration. I would prefer not to add additional restrictions on the watchdog since it is more work to add them. Adding these restrictions would break existing customers using the watchdog for instance. Also, given that the watchdog is opt-in instead of enabled by default (which we considered during scoping), I think there is no need to restrict when it can be enabled by customers. Is it ok to close this ticket as "Won't Fix"?
- Watchdog already supports non-wiredtiger. There is a test for in-memory for instance.
- Journaling is optional and the watchdog only watchs the journal if journaling is enabled.
- Directory Per DB - it is irrelevant to the watchdog if directory-per-db is on. If users move databases to other volumes and replace the directories with symlinks, the watchdog will miss those alternate volumes though.
- logging and auditing are only considered if they output to a directory, they are ignored otherwise. This conditional logic already exists in the watchdog.
|