kpt live init automatically add resourcegroup.yaml to a .gitignore file

[apeabody]

I recommend kpt live init automatically add resourcegroup.yaml to a .gitignore file for better compatibility with ConfigSync.

Reference: https://github.com/GoogleContainerTools/kpt/pull/3172

[droot]

Thanks for filing the issue @apeabody .

[droot]

Two options here:

1. Automatically add to .gitignore if present (with an option to disable this behavior)
2. Asking user and then doing it [This might be more disruptive if users are invoking in an unattended workflow]

So option 1) is more desirable.

/cc @mortent

[mortent]

I'm not sure if we want to automatically add the resourcegroup.yaml file to .gitignore. The reason we write the inventory information to a local file when running kpt live init, is because we want this information to be checked into git with the rest of the configuration such that every apply uses the same inventory. I agree that interoperability between kpt live and Config Sync should be better..

What is the use-case for running kpt live init if you want to sync it to the cluster with Config Sync?

[apeabody]

Hi @mortent - The use case I've see is to allow kpt live apply --dry-run before checking into the git repo. Cheers!

[mortent]

@apeabody Thanks for clarifying. I think using kpt live apply --dry-run as a way to verify changes is a good example of where we should have better interoperability between kpt and Config Sync. In this case though, using the inventory information from kpt live init will only provide the "correct" feedback if the package has not already been synced through Config Sync since there is no existing inventory in the cluster. However, if the package has already been installed through Config Sync, using kpt in this way to verify will lead to incorrect results since kpt will use the incorrect inventory.

The correct way we should handle this, is probably by letting users run kpt live apply --dry-run and provide the name and namespace (for RepoSyncs) so that kpt can actually find the same inventory object as is used by Config Sync.

[apeabody]

Thanks @mortent - In this particular example the package would be new and not previously synced through Config Sync, however I'm sure there are use cases for dry-run of updated packages as well.