Leo Q
Leo Q
这个是存在的bug, 一致没来得及修来着
我建议将配置项精简为两个配置项： 1. DDL可执行时间 ，可填写类似 8:00-12:00,14:00-18:00 这类的多个时间窗口 2. 临时禁止DDL执行的开关，供管理员在有需要时使用。 可执行时间范围和当前实现比较，配置起来少一个配置项，且可配置多个时间窗口，更加灵活。
确实是很好的想法, 确实可以这样去实现
这一版还是和自动通过结合了, 在这一步之前再做一个处理, 如果 workflow status 是 autoreview_wrong ,那么就提前保存, return , 你看能不能解决你的问题. https://github.com/hhyo/Archery/blob/52ce7595d4b3b6e294b49c4d9a4ce10a0992d60f/sql/utils/workflow_audit.py#L303-L316
可能之前表达的不清晰, 我重复表达下我的建议: 1. 是否自动驳回和是否自动通过是两个逻辑, 自动驳回优先, 先判断是否自动驳回, 再判断是否自动通过, 这样逻辑清晰, 容易理解, 不要混在一起. 2. 驳回还是不驳回, 不适宜放在 `generate_audit_settings` 内, 就如这个函数名字描述的一样, 是生成工单对应的审批流, 是否自动通过, 审核节点是哪些, 等等. 驳回还是不驳回适宜放在 `create_audit` 内. 希望你能理解.
The metric name looks good to me, thanks for your contribution in advance!
@SuperQ the original metric statsd_exporter_metrics_total provides separated counters for each metric type, including counter, gauge, and observer, this could be useful
Here's an example helm value if you want to use it. notable settings: 1. change k8sAppLabelOverride to prevent confusion 2. set forward plugin to forward dns to the cluster coredns...
First, I would like to break down the points of contention into whether we should deploy CoreDNS as a DaemonSet and whether our project should support this deployment method. Kubernetes...
And lastly, I would believe this will not bring the helm chart maintainer much more burden as it’s targeting just deploy CoreDNS to every node. It follows the same configuration...