Decouple metadata / target retrieval from HTTP

[random2442]

At present you make the assumption that metadata and target retrieval will always be over HTTP. Which is a reasonable assumption given the original indented application where the client devices are not under the control of the updater service.

However, for controlled environments, it could be useful, for example, to use pure S3 to retrieve metadata and target data from an S3 bucket via the S3 API and so they can:
(a) maintain stricter control over privacy and security and
(b) remove the un-necessary need to maintain an HTTP server.

To be clear, I am not saying you should implement the S3 calls itself.

But rather I'm saying you should decouple it so that people can plugin a function of their choice that implements the interface. Just like they can do with the signing mechanism.

Edit to add:

Looking at this a little more, the TL;DR appears to be:

You already made an effort to decouple, but then you forgot all about it when coding updater.

Positives:

✅ You have Fetcher which allows an interface (metadata/fetcher/fetcher.go)
✅ You have Config which allows specification of Fetcher implementation (metadata/config/config.go)

Negatives:

❌ updater.go is (sadly) a bit of a mess that makes many hardcoded assumptions that the Fetcher will always be the default fetcher, i.e.:

• No way to pass in a Fetcher
• Large number of http assumptions everywhere (url generation, http error codes etc. etc. etc.)

(Heads-up to #660 )