kustomize integration

[annp1987]

Hi Everyone,

Currently, we can adding labels, changing namespace of manifest before apply them. But I'm not sure there is possible to manipulate manifest from kustomize build then apply it? Do you have any advice?

[johnsonj]

• rough proposal for integration

@annp1987 - Should we assign this bug to you?

[annp1987]

@johnsonj ,
Please assign this bug to me. Its my pleasure. :-)

[annp1987]

/cc annp1987

[johnsonj]

Thanks @annp1987 ! Let me know if you have any questions/want an early review

[annp1987]

Thanks @johnsonj. Could you have a early review for kustomize integration at https://github.com/annp1987/kubebuilder-declarative-pattern/tree/intergrate_with_krusty?

[johnsonj]

Hey @annp1987 - sorry for the delay. Your change looks right on track. I don't have any major structural comments. I'm excited to see this one land!

This likely goes without saying, but you will need to keep track of the original filesystem paths and use them when you write to the in memory filesystem (fSys.WriteFile)

[annp1987]

Thanks @johnsonj. I've just create a PR. Could you take a look at it?

[johnsonj]

#66 added the initial support for this feature. We still need tests, documentation, and potentially more feature work for this to be closed out.

[johnsonj]

There's additional open issues highlighted in @atoato88's comment

[rajansandeep]

Adding further to @atoato88's comment, if an operator has Kustomize enabled (for example CoreDNS-operator to include the configMapGenerator), we can just parse the final yaml built by the kustomization.yaml, instead of trying to parse all the files present in the version folder.

[johnsonj]

As it is today, the transformation process relies on being able to parse everything as a Kubernetes object. For example, we have a private registry transform that will go patch all of the image registries. That's something we would like to keep.

We could make the file loading code more flexible:

kubebuilder-declarative-pattern/pkg/patterns/declarative/pkg/manifest/objects.go

Line 292 in bbf1fb2

func ParseObjects(ctx context.Context, manifest string) (*Objects, error) {

For example, we could change Objects to hold onto parsable Kubernetes types as it does today and keep the rest as plaintext/blobs.

type Objects struct {
  Items []*Object
  Blobs [][]byte
}

[somtochiama]

/assign

[somtochiama]

@johnsonj how do we know when to change the Objects or when to keep as blobs?

[johnsonj]

@somtochiama If it can be parsed into an unstructured.Unstructured then it should be an Object. Otherwise, Blob

[somtochiama]

@rajansandeep Are you suggesting that we do https://github.com/kubernetes-sigs/kubebuilder-declarative-pattern/blob/master/pkg/patterns/declarative/reconciler.go#L136 before building the deployment objects?

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.