You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Questions to answer, and things to consider, during this POC
1. Should zone_sync be enabled by default?
No, we do not want to enable the functionality if it's not used.
2. Can it be secure, by default? (Current implementation of Headless Services does not use TLS)
-- yes, TLS cert(s) to secure communication between NIC Pods (NGINX Plus zones) need to be handled by a user
-- adding TLS functionality would likely break current implementation (via Zone Sync ConfigMaps - TBD)
-- TBD
3. Do we require a flag/cli argument?
Yes. We want to be explicit. Add validation.
4. Should this capability be toggled dynamically? (i.e. when enabling capabilities that take advantage of this)
No. See above - we want to be explicit, validate and "fail fast".
5. What would be the effort to decouple this capability from our OIDC implementation
6. Do we need to refactor logic of current rate limiting where we divide by replicas?
Yes, for OSS and N+. TBD. The current implementation will still be used for OSS.
7. Identify independent functionality that needs to be in place to avoid one large change
-- zone sync configured without TLS support - focus on zone sync functionality and testing, for example the rate limiting
-- add TLS configuration - regression testing
-- TBD
8. Identify if a TMA is required
Yes, it will be required. See communication between NGINX instances (NIC - pods)
Questions to answer, and things to consider, during this POC
zone_sync
be enabled by default?The text was updated successfully, but these errors were encountered: