Open triffer opened 1 year ago
This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
If you think that I work incorrectly, kindly raise an issue with the problem.
/lifecycle stale
This issue or PR has been automatically closed due to the lack of activity. Thank you for your contributions.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, the issue is closedYou can:
/reopen
/remove-lifecycle stale
If you think that I work incorrectly, kindly raise an issue with the problem.
/close
@kyma-bot: Closing this issue.
This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
If you think that I work incorrectly, kindly raise an issue with the problem.
/lifecycle stale
Description The origin of this is the Operational Awarness workshop item #11.b. The assumption is, that if there is sidecar injection enabled or disabled in a namespace, all pods in the namespace should have a sidecar or no sidecar. There is the scenario where the Injection-label is changed or removed while workloads were already deployed. This might result in a communication issue between workloads. It should also be taken into account that the injection can be controlled by a label at pod level.
The proposed mitigation options were:
Reasons The state of the sidecars in the namespace should be consistent with the configurations of the injection of the namespace. A customer might not be aware that changing this configuration requires a restart of the already deployed pods.
DoD:
Attachments