Closed jpopelka closed 1 month ago
This issue has been marked as stale because it hasn't seen any activity for the last 60 days.
Stale issues are closed after 14 days, unless the label is removed by a maintainer or someone comments on it.
This is done in order to ensure that open issues are still relevant.
Thank you for your contribution! :unicorn: :rocket: :robot:
(Note: issues labeled with pinned or EPIC are never marked as stale.)
This issue has been marked as stale because it hasn't seen any activity for the last 60 days.
Stale issues are closed after 14 days, unless the label is removed by a maintainer or someone comments on it.
This is done in order to ensure that open issues are still relevant.
Thank you for your contribution! :unicorn: :rocket: :robot:
(Note: issues labeled with pinned or EPIC are never marked as stale.)
In the simple terms, it makes sure that the definition that is to be deployed matches the one that is already deployed. The difference has already manifested few times, e.g., when @majamassarini was adjusting the /dev/shm
for the postgres deployment (bedef2026c84ea00bb329799cc9bef81687fe88d), the change did not get deployed.
not sure
Not really. I would definitely avoid it with the “critical” services (e.g., postgres), last time I tried deploying production with apply=true
the redeployment of everything caused a small downtime.
The apply parameter docs says: "
apply
compares the desired resource definition with the previously supplied resource definition, ignoring properties that are automatically generated.apply
works better with Services thanforce=yes
."I don't quite understand how it's actually different from the default behavior (what are the "properties that are automatically generated"?), but @csomh says it helps when there are properties being removed in the object.
Investigate:
apply=true
?