Skip to content

Fix no namespace resource found on delete resource k8s #1281

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.

Sign up for GitHub

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

Merged
pipecd-bot merged 3 commits into from
Dec 18, 2020
Merged

Fix no namespace resource found on delete resource k8s #1281

Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6ed83a6
Fix no namespace resource found on delete resource k8s
khanhtc1202 Dec 17, 2020
7334ba5
Rename
khanhtc1202 Dec 18, 2020
789fe98
Fix comment
khanhtc1202 Dec 18, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
13 changes: 11 additions & 2 deletions pkg/app/piped/cloudprovider/kubernetes/kubernetes.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -234,7 +234,7 @@ func (p *provider) ApplyManifest(ctx context.Context, manifest Manifest) error {
return p.initErr
}

return p.kubectl.Apply(ctx, p.input.Namespace, manifest)
return p.kubectl.Apply(ctx, p.getNamespaceForRun(manifest.Key), manifest)
}

// Delete deletes the given resource from Kubernetes cluster.
Expand All @@ -244,7 +244,16 @@ func (p *provider) Delete(ctx context.Context, k ResourceKey) (err error) {
return p.initErr
}

return p.kubectl.Delete(ctx, p.input.Namespace, k)
return p.kubectl.Delete(ctx, p.getNamespaceForRun(k), k)
}

// getNamespaceForRun returns namespace used on kubectl apply/delete commands
// priority: config.KubernetesDeploymentInput > kubernetes.ResourceKey
func (p *provider) getNamespaceForRun(k ResourceKey) string {
if p.input.Namespace != "" {
return p.input.Namespace
}
return k.Namespace

@khanhtc1202 khanhtc1202 Dec 18, 2020

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could get the namespace from ResourceKey ( from manifest files ) or from KubernetesDeploymentInput ( which could be empty on unset currently ). IMO, namespace value from KubernetesDeploymentInput should have a higher priority than the value from ResourceKey, in case of mismatch, the current not found resources to delete error will be raised.
How do you think?

@nakabonne nakabonne Dec 18, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the one in the user-defined manifest should be more prioritized than pipe.yaml when applying.

@nakabonne nakabonne Dec 18, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To be simple, the piped's role is basically just to perform kubectl apply -f manifest.yaml.

@nakabonne nakabonne Dec 18, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... but on the second thought, the case that user clearly defines its namespace in the .pipe.yaml, I'm begging to feel it's better to override the base manifest.

@nghialv nghialv Dec 18, 2020

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One vote from me for taking the namespace value from the Input with higher priority.

@khanhtc1202 khanhtc1202 Dec 18, 2020 •
edited
Loading

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm... but on the second thought, the case that user clearly defines its namespace in the .pipe.yaml, I'm begging to feel it's better to override the base manifest.

yep, I feel the same either. Since the manifest should be treated as a base, and config on .pipe.yaml lay on that base and those who defined the config should be aware of where should the deployment they set will be applied to.

}

func (p *provider) findKubectl(ctx context.Context, version string) (*Kubectl, error) {
Expand Down