-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of nits (one misleading log message; one test that could do more). I have a longer-form comment which I'll get to in a sec ..
pkg/cluster/kubernetes/sync_test.go
Outdated
@@ -464,6 +485,18 @@ metadata: | |||
test(t, kube, "", ns1+defs1+defs2+ns3+defs3, false) | |||
}) | |||
|
|||
t.Run("sync adds and GCs skips resources", func(t *testing.T) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test does verify what it claims to; but I think it should also verify that resources are updated (i.e., not ignored) when they have a gc_disabled annotation.
pkg/cluster/kubernetes/sync.go
Outdated
@@ -145,6 +145,11 @@ func (c *Cluster) collectGarbage( | |||
|
|||
switch { | |||
case !ok: // was not recorded as having been staged for application | |||
if res.Policies().Has(policy.DisableGarbageCollect) { | |||
c.logger.Log("info", "not deleting resource; garbage colelction annotation in file", "resource", res.ResourceID()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
c.logger.Log("info", "not deleting resource; garbage colelction annotation in file", "resource", res.ResourceID()) | |
c.logger.Log("info", "not deleting resource; garbage collection disabled by annotation", "resource", res.ResourceID()) |
(typo, and the annotation is in the cluster resource, not the file)
Thinking aloud: I wonder if this could be value of "ignore", instead of its own annotation. Here are the combinations of annotations and effects, when there are both:
There's only three different behaviours there, so they don't operate independently -- one of them is redundant. So you could represent those three possibilities as three values:
One counter-argument is that it's weird to have a three-valued boolean like that (albeit they are only stringly pictures of booleans). wdyt @phillebaba ? |
There would be some benefit with reducing the number of annotations, the risk is that having three values would confuse people. So documentation of the behavior is important. The Does these descriptions match the intended behavior of the different values? Assuming that the end user has enabled GC.
Am I missing something in the description? |
Yes, I agree on both points. There's an opportunity to change the formulation slightly, so long as it's backward-compatible -- say,
Right, that's presupposed. I find it hard to imagine that someone is relying on it not working like that (even I had difficulty getting my head around the fact that it didn't).
I would say "synced from git", since updates in git will still be applied to the cluster. Similarly, in the description of "true". |
OK so I think the goal for this PR should be to make it work as we've settled on above -- are you happy to adjust it, @phillebaba? Alternatively, I could make ignore mean ignore-for-gc-too in another PR, then you could work on top of that. |
I can implement both parts, don't think that is an issue. You are right about going with the multi value annotation solution as it would simplify logic. I have a lot to do at work this week so I can't get this done until the weekend. |
Cool, no worries @phillebaba, any time you lend to this project is appreciated :-) |
I change the behavior so that you disable GC by setting I also added some more info in the FAQ, but i think that getting a single page that documents all annotations as described in #2671 would be great! A table like this would describe the ignore annotations behavior pretty well.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have quibbles only -- this is a neat and incisive PR, thank you. If you have a moment, account for the quibbles as you see fit, and rebase on master. (I'll do the latter in a day or two -- it'll be mechanical anyway).
docs/faq.md
Outdated
@@ -341,6 +341,18 @@ how/where to undo the change (cf [flux#1211](https://github.com/fluxcd/flux/issu | |||
annotation exists in either the cluster or in git, it will be respected, so you may need to remove | |||
it from both places. | |||
|
|||
Additionally when garbage collection is enabled. Flux will not garbage collect resources in the cluster |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Additionally when garbage collection is enabled. Flux will not garbage collect resources in the cluster | |
Additionally, when garbage collection is enabled, Flux will not garbage collect resources in the cluster |
### Can I disable garbage collection for a specific resource? | ||
|
||
Yes. By adding the annotation below to a resource Flux will sync updates from git, but it will not | ||
garbage collect when the resource is removed from git. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
pkg/cluster/kubernetes/sync.go
Outdated
} | ||
|
||
v, ok := res.Policies().Get(policy.Ignore) | ||
if ok && v == "sync_only" { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could do with a constant for this
test(t, kube, ns1+dep1, ns1+dep1, false) | ||
|
||
// sync namespace only but expect deployment to not be GC | ||
test(t, kube, ns1, ns1+dep1, false) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice and simple test case 👍
Change GC behavior to skip GC of resources with ignore policy
This change implements an annotation to disable garbage collection for specific resources.
#2841