-
Notifications
You must be signed in to change notification settings - Fork 7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix no RESOURCE with the name NAME found
#4871
Fix no RESOURCE with the name NAME found
#4871
Conversation
a740989
to
368f85d
Compare
368f85d
to
000296d
Compare
This seems like a good approach to the problem. I'll start testing this with a few charts tomorrow. Thanks for the fix, @distorhead! |
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.
one small change, otherwise works as expected when tested manually.
000296d
to
e675db2
Compare
e675db2
to
d01441b
Compare
I'll bring this ticket up in today's dev call since I'm not entirely sure if there may be some cases where we do not want to delete newly created resources. |
Note, AppVeyor is currently always failing. We can ignore this as it's unrelated to the PR. |
^^ yes thank you :) currently working on that in #4897 |
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 is a breaking change. It is incredibly valuable functionality but I propose we put this functionality behind a feature flag on helm upgrade
@michelleN I think that's a great idea. I'm also feeling incredibly wary about introducing anything related to resource deletion by default, especially on upgrade. Hiding this functionality behind a feature flag would allow users to opt into this (destructive) behaviour with little risk for users who aren't hitting this edge case. Good suggestion. 👍 |
Ok, I see your point. What option name do you propose? Does Some thoughts:
In total:
|
We're currently looking at the resource upgrade strategy for Helm 3. It may be a 3-way merge patch, or it could be something different. Either way we are certainly looking into ways to improve the current upgrade strategy, but we don't have any news or reports to share at this time.
|
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.
removing "approved" status for the time being
13af1a1
to
d6fa8da
Compare
@fbcbarbosa Merged your addition, thanks! Also rebased whole branch on the upstream master. |
Signed-off-by: Timofey Kirillov <timofey.kirillov@flant.com>
b871cc6
to
b252376
Compare
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.
needs another maintainer to review, but code LGTM.
I am working on reviewing this and testing manually |
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 is looking good! Just one nit that won't block merging. I'll come back and give it a green check once I do some manual testing with it
// and creates resources that don't already exists, updates resources that have been modified | ||
// in the target configuration and deletes resources from the current configuration that are | ||
// not present in the target configuration. | ||
// | ||
// Namespace will set the namespaces. | ||
func (c *Client) Update(namespace string, originalReader, targetReader io.Reader, force bool, recreate bool, timeout int64, shouldWait bool) error { | ||
func (c *Client) UpdateWithOptions(namespace string, originalReader, targetReader io.Reader, opts UpdateOptions) error { |
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 reads much cleaner and avoids breaking API changes when we need to add other things. Thanks for the great refactor!
…update Signed-off-by: Timofey Kirillov <timofey.kirillov@flant.com>
Signed-off-by: Timofey Kirillov <timofey.kirillov@flant.com>
b252376
to
a8145d6
Compare
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.
Ok, manual testing on this looks good! Thanks for all of the hard work
This ports the functionality of cleanup on fail to v3 as introduced in helm#4871. This has been tested manually and would be a good candidate for a new acceptance test. Signed-off-by: Taylor Thomas <taylor.thomas@microsoft.com>
This is the fix for only one particular, but important case.
The case when a new resource has been added to the chart and there is an error in the chart, which leads to release failure. In this case after first failed release upgrade new resource will be created in the cluster. On the next release upgrade there will be the error:
no RESOURCE with the name NAME found
for this newly created resource from the previous release upgrade.The root of this problem is in the side effect of the first release process. Release invariant says: if resouce exists in the kubernetes cluster, then it should exist in the release storage. But this invariant has been broken by helm itself -- because helm created new resources as side effect and not adopted them into release storage.
To maintain release invariant for such case during release upgrade operation all newly successfully created resources will be deleted in the case of an error in the subsequent resources update.