Mark images for deletion on release deletion

[joshbwlng]

Change-type: minor

---

See: https://balena.fibery.io/Work/Project/Mark-associated-resources-for-deletion-when-a-release-is-deleted-1779

My biggest concern is properly handling a potentially large number of images in the task - analogous to the service install task work.

Note: We can merge this before the delete images endpoint is enabled on the registry as this function is toggled via an env var. Once the delete endpoint is available we can turn this feature on with the env var.

[joshbwlng]

/rebase

[joshbwlng]

We may instead want to generate a wildcard token with delete access to all repos

[otaviojacobi]

@joshbwlng just for my own information, is there any specific reason you chose this schema instead of

Suggested change

	const schema = {
	type: 'object',
	properties: {
	images: {
	type: 'array',
	items: {
	type: 'array',
	items: {
	type: 'string',
	},
	maxItems: 2,
	minItems: 2,
	},
	},
	},
	required: ['images'],
	};
	const schema = {
	type: 'object',
	properties: {
	images: {
	type: 'array',
	items: {
	type: 'object',
	properties: {
	repo: { type: 'string' },
	hash: { type: 'string' },
	},
	required: ['repo', 'hash'],
	additionalProperties: false,
	},
	},
	},
	required: ['images'],
	};

where the properties have explicit naming? (slightly easier to read imo)

[joshbwlng]

Having the named keys does make it easier (I had them in my initial source), but decided to drop them in favor of reducing task DB record size - especially since cascade deletions can lead to a very large number of images being processed here.

[otaviojacobi]

Are all repo/hashes we have here guaranteed to belong to our own registry or could these be images on custom customer registry?

[joshbwlng]

Why would they belong on a custom customer registry? Even if it's balenaMachine the value should point to their respective registry service (REGISTRY2_HOST).

If you're asking if the domain is always guaranteed to match the current value of REGISTRY2_HOST, then that's a no. We have images in production/staging in which the domain is registry2.resin.io for example instead of our current registry2.balena-cloud.com value.

Regardless, the idea is to attempt the deletion using the one and only registry our API has access to. If the response from the registry is 404, well then there's nothing else we can do anyway - the manifest we wanted to get rid of is already gone.

[joshbwlng]

/rebase