kustomize: Kustomize 4.5.3+ breaks remote resources

Describe the bug

I am having a hard time understanding what is going on because some remote bases work and others don’t. I can consistently reproduce the problem with one of our repos but unsure how to datamine more information about what is going on. I tried adding ssh and curl verbose flags but it isn’t getting to that point.

$ kustomize version                                                                                                                                                                                                              
{Version:kustomize/v4.5.4 GitCommit:cf3a452ddd6f83945d39d582243b8592ec627ae3 BuildDate:2022-03-28T23:06:20Z GoOs:darwin GoArch:amd64}
$ kustomize build <my path with many remote bases> --enable-helm                                                                                                                                                                    
Error: accumulating resources: accumulating resources from 'https://dev.azure.com/repo': MalformedYAMLError: yaml: line 27: mapping values are not allowed in this context in File: https://dev.azure.com/<repo>

Yet the same repo works fine with kustomize 4.5.2

$ ~/Downloads/kustomize version                                                                                                                                                                                                  
{Version:kustomize/v4.5.2 GitCommit:9091919699baf1c5a5bf71b32ca73a993e98088b BuildDate:2022-02-09T23:26:42Z GoOs:darwin GoArch:amd64}
$ ~/Downloads/kustomize build <my path with many remote bases> --enable-helm | wc -l                                                                                                                                                                            
    6840

Expected output

The same output as 4.5.2, no errors and the manifests rendered.

Actual output

Error message complaining about mapping contexts.

Kustomize version

$ kustomize version                                                                                                                                                                                                              
{Version:kustomize/v4.5.4 GitCommit:cf3a452ddd6f83945d39d582243b8592ec627ae3 BuildDate:2022-03-28T23:06:20Z GoOs:darwin GoArch:amd64}

Platform

Mac

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 6
Comments: 23 (16 by maintainers)

Most upvoted comments

Btw, thank you @m-Bilal for the thorough investigation and narrowing down what caused the problem. It’s super helpful to have you take some time to work on kustomize!

natasha41575 on Apr 18, 2022

I think we should move these lines: https://github.com/kubernetes-sigs/kustomize/blob/a464ed0c594bc67a1254855d32485d97092f8555/api/internal/target/kusttarget.go#L410-L416

down to inside these two if statements:

https://github.com/kubernetes-sigs/kustomize/blob/a464ed0c594bc67a1254855d32485d97092f8555/api/internal/target/kusttarget.go#L418-L420

https://github.com/kubernetes-sigs/kustomize/blob/a464ed0c594bc67a1254855d32485d97092f8555/api/internal/target/kusttarget.go#L432-L434

This is what I suggested in the PR here https://github.com/kubernetes-sigs/kustomize/pull/4334#discussion_r766959982 so that we don’t break existing workflows, and considering that this is the second regression caused by adding an error check, I’m more convinced that my suggestion in that PR is the safer way to go. It should look like:

if err != nil {
 	if errors.Is(errF, load.ErrorHTTP) { 
 		return nil, errF 
 	} 
 	if kusterr.IsMalformedYAMLError(errF) { // Some error occurred while tyring to decode YAML file 
 		return nil, errF 
 	} 
 	return nil, errors.Wrapf(
 		err, "accumulation err='%s'", errF.Error())
}

This way, we are only improving the error message; we won’t be throwing any errors where we weren’t previously already throwing an error.

@m-Bilal is that clear to you? Would you be able to make that change and verify that #3812 would still be solved?

At some point we should also build up a larger suite of tests with different remote URLs so that we can be more confident about changes like this, but until we have that IMO we should err on the safer side.

natasha41575 on Apr 18, 2022

Same issue here.

The remote resource is reached with: (hosted on Gitlab)

resources:
  - https://mydomain.com/infrastructure/kubernetes/kustomize_bff.git//base?ref=master

And for information, the remote resource looks like that:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
- configmap.yaml
- deployment.yaml
- hpa.yaml
- service.yaml
- stripprefix.yaml
- ingressRoute.yaml

configurations:
- nameReferenceConfiguration.yaml

TheDoubleJo on Apr 6, 2022

A workaround is to use ssh (e.g. git@github.com:...) or prefixing git:: to https urls, (e.g. git::https://github.com/user/repo.git?ref=...)

MarcoPolo on Apr 6, 2022