Remove custom endpoints

[chrisdoherty4]

Overview

Custom endpoints force operators to understand the format exported by the backend so they can write a query to extract the data to serve from the custom endpoint.

Removing the custom endpoint configuration is necessary for further refactoring to remove ambiguous data 'export' from the backend and cleans the code up so operators do not need to understand implementation detail.

In removing custom endpoints, the registerCustomEndpoints func was removed also. This in turn rendered many unit tests redundant as they dependend on the func to perform arbitrary configuration for test. The tests themselves made little sense given they configured a mux and didn't really test the application.

The default /metadata endpoint has been hard coded with the other mux configuration.

Next steps

Having removed the custom endpoints, we can refactor the internals as there's no obligation to honor existing 'exports' within the 'backend' code. The intent is to remove ambiguity in the implementation and firm up expectations for each endpoint with respect to where the data comes from (i.e. strip out the ambiguous 'export' from backends in favor of something explicit).

Closes #132

[codecov]

Codecov Report

Merging #131 (b3d33c8) into main (ae4d443) will decrease coverage by 3.44%.
The diff coverage is 100.00%.

❗ Current head b3d33c8 differs from pull request most recent head 8e64abf. Consider uploading reports for the commit 8e64abf to get more accurate results

@@            Coverage Diff             @@
##             main     #131      +/-   ##
==========================================
- Coverage   24.19%   20.74%   -3.45%     
==========================================
  Files           7        7              
  Lines         682      670      -12     
==========================================
- Hits          165      139      -26     
- Misses        494      513      +19     
+ Partials       23       18       -5     

Impacted Files	Coverage Δ
http/server.go	77.14% <100.00%> (ø)
internal/http/api.go
internal/hardware/client.go
internal/hardware/tink.go
internal/hardware/kubernetes.go
internal/http/handlers.go
internal/hardware/export.go
internal/http/server.go
hardware/client.go	0.00% <0.00%> (ø)
... and 5 more

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[displague]

I took a look at this and it looked fine. The one failing check is around a loss of coverage which makes sense with the tested code removal.

I would like @mmlb and @nshalman to weigh-in because the removal of these custom endpoints would have an effect in Equinix Metal were this code in use (metadata /components and /userdata for example).

@chrisdoherty4 Just for clarity, how does this affect Tinkerbell /userdata requests in EC2 mode - are they served from an alternate path? /2009-04-04/user-data

[chrisdoherty4]

how does this affect Tinkerbell /userdata requests in EC2 mode

The /user-data endpoint (part of the EC2 standard) is served in the same way as the other EC2 endpoints. That means this change has no impact on it. The /metadata endpoint is an Equinix specific thing that I'm looking to maintain in the interim but will likely be dropped in the future too.

See https://github.com/tinkerbell/hegel/blob/main/http/handlers.go#L28

I would like @mmlb and @nshalman to weigh-in because the removal of these custom endpoints would have an effect in Equinix Metal were this code in use

@nshalman has advised Equinix plan to take a different direction so Hegel's dominant use-case is Tinkerbell. As such, this and many more draft refactors I've raised are focused on stripping out anything non-standard/Equinix specific.

Ref: https://cloud-native.slack.com/archives/C01SRB41GMT/p1658236374550009

The one failing check is around a loss of coverage which makes sense with the tested code removal.

This is temporary. More PRs are being introduced that break the code apart and test it much more thoroughly. See, for example, https://github.com/tinkerbell/hegel/pull/139/files#diff-b883f935ee0043fd6dff18cec45055d89868c716f4f2332a297f13b74cc8a296

@displague