Review Checklist

Hello reviewers! 👋 Please follow this checklist when reviewing this Pull Request.

General

• Ensure that the Pull Request has a descriptive title.
• If this is a change that users need to know about, please apply the release notes (needs details) label so that merging is blocked unless the summary release notes document is included.
• If a test is added or modified, there should be a documentation on top of the test to explain what the expected behavior is what the test does.

If a new flag is being introduced:

• Is it really necessary to add this flag?
• Flag names should be clear and intuitive (as far as possible)
• Help text should be descriptive.
• Flag names should use dashes (-) as word separators rather than underscores (_).

If a workflow is added or modified:

• Each item in Jobs should be named in order to mark it as required.
• If the workflow should be required, the maintainer team should be notified.

Bug fixes

• There should be at least one unit or end-to-end test.
• The Pull Request description should include a link to an issue that describes the bug.

Non-trivial changes

• There should be some code comments as to why things are implemented the way they are.

New/Existing features

• Should be documented, either by modifying the existing documentation or creating new documentation.
• New features should have a link to a feature request issue or an RFC that documents the use cases, corner cases and test cases.

Backward compatibility

• Protobuf changes should be wire-compatible.
• Changes to _vt tables and RPCs need to be backward compatible.
• vtctl command output order should be stable and awk-able.
• RPC changes should be compatible with vitess-operator
• If a flag is removed, then it should also be removed from VTop, if used there.

To add on my two cents as one of the main contributors to our planetscale/log library, it'd be easy to repurpose the original PR to just directly use zap, rather than our wrapper. I agree that we shouldn't embed planetscale/log since it's intended to just supply some reasonable defaults that help unify our internal infrastructure demands.

I think it'd be better suited to copy/paste some of the default configs, then have vitess directly use zap. If vitess allowed in it's api for us to pass a *zap.Logger into components, then it'd interop nicely for us internal to PlanetScale since we could then pass in our own *zap.Logger if we wanted to since planetscale/log emits a compatible *zap.Logger.

@EmadMokhtar I apologize for this! The Vitess team didn't realize this could become problematic when reviewing your work. Should we re-open #11960 ?

@EmadMokhtar I apologize for this! The Vitess team didn't realize this could become problematic when reviewing your work. Should we re-open #11960 ?

No worries @mattlord, I introduced another PR that uses Zap logger.