docs: config#375
Conversation
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| cpu: 0 | ||
| memory: 0 | ||
| storage: 0 | ||
| deployment: |
There was a problem hiding this comment.
What is this relating to specifically? Provider deployment?
There was a problem hiding this comment.
That section is related to those flags: link
As I understand, it is settings for tenant workloads (how the provider deploys leases to K8s), not the provider’s own deployment.
| max_retries: 40 | ||
| retry_period: 4s | ||
| retry_period_jitter: 15s | ||
| healthcheck_period: 10s |
There was a problem hiding this comment.
health check is performed by readiness/liveness probes. What is this specifically setting?
There was a problem hiding this comment.
This corresponds to that flag: link
This is not K8s readiness/liveness probes, but the check conducted by the deployment against tenant workloads.
| gateway: | ||
| listen_address: "0.0.0.0:8443" | ||
| grpc_listen_address: "0.0.0.0:8444" | ||
| tls: { cert: "", key: "" } |
There was a problem hiding this comment.
Suggestion: tls.cert and tls.key
| cert_issuer: | ||
| enabled: false | ||
|
|
||
| # ... other sections |
There was a problem hiding this comment.
Future Gateway API settings
| | Scenario | Best fit | | ||
| |----------|----------| | ||
| | **Single cluster** | ConfigMap + K8s watch | | ||
| | **Multi-cluster, minimal infra** | S3 + poll | |
There was a problem hiding this comment.
I'm not sure I understand the multi-cluster setup in this context. Does it mean a shared configuration between providers?
There was a problem hiding this comment.
I can imagine an operator that has two providers in physicality different clusters.
Or a single provider, but with worker nodes in the different k8s clusters.
Why I am separating this, because K8S config maps works only within the same cluster, and it is the simplest and k8s native solution that I would consider in case we go with single cluster appproach.
| YAML format with subsections per module (like inventory operator). | ||
|
|
||
| <details> | ||
| <summary>Expand to see config example</summary> |
There was a problem hiding this comment.
This config example is general, not precise, but it shows how the future config format may look like
2 participants
It will be easier to review my proposal in PR format