Update asset-syncer delete to use namespace.

[absoludity]

Ref #1521
Follows #1532, and updates the delete command to include the repo namespace.

Note that I've updated the schema slightly, so that both charts and chartfiles tables use a composite foreign key to the repos table. This means that we can let postgres handle the cascading delete (much simpler [1]) and data integrity generally, while still allowing us to reference the relationship in any table.

[1] I wrote the test first and actually found that the existing code was deleting related charts but not the chart files. Didn't look into why, but the new code fixed it.

[andresmgot]

LGTM

I guess that the schema change is the one causing the error. It seems that the call to get a chart version is failing (from the screenshots) so you may need to update something in the assetsvc.

[absoludity]

LGTM

I guess that the schema change is the one causing the error. It seems that the call to get a chart version is failing (from the screenshots) so you may need to update something in the assetsvc.

The chart files table was empty. Checking one of the syncs, I was seeing:

time="2020-02-24T05:12:16Z" level=info msg="values.schema.json not found" name=joomla version=0.5.5
time="2020-02-24T05:12:16Z" level=error msg="failed to import files" error="pq: insert or update on table \"files\" violates foreign key constraint \"files_repo_name_fkey\"" name=joomla version=0.5.5
time="2020-02-24T05:12:16Z" level=info msg="Stored repository update in cache" url="https://charts.bitnami.com/bitnami"
time="2020-02-24T05:12:16Z" level=info msg="Successfully added the chart repository bitnami to database"

Checking the db logs, it turned out I wasn't sending the namespace when importing files. Oddly, the sync succeeds because the worker just logs the error rather than having some form of failure: https://github.com/kubeapps/kubeapps/blob/master/cmd/asset-syncer/utils.go#L327

Let me know if you remember why... it'd be much nicer if that had failed.

[andresmgot]

Let me know if you remember why... it'd be much nicer if that had failed.

As mentioned in the call, I think the only reason to not fail at that time is to not abort the whole execution just if one asset fails to be imported but yes, we could at least change the exit code at that point.