remove the metadata filter in the sandbox

[moadqassem]

Description

Using a custom endpoint instead of using the default endpoint that hegel adjusts

Why is this needed

The reason behind that is, while using the sandbox in combination with tinkerbell's example workflows. The functions.sh will fail due to lack of information in the retrieved metadata from hegel. The default endpoint filters out all the needed metadata such as plan_slug. This PR removes that filtration criteria.

Also I am not sure, I think we are safe to provide these info(the full hardware spec) to the worker while using the Sandbox setup, as this is mainly used as an example setup not as a production one.

Fixes: #64

How Has This Been Tested?

Yes, it was tested locally by setting the env var in the docker-compose.yml file and batch it in the sandbox setup.

How are existing users impacted? What migration steps/scripts do we need?

Checklist:

I have:

• updated the documentation and/or roadmap (if required)
• added unit or e2e tests
• provided instructions on how to upgrade

[gauravgahlot]

Adding a reference to how CUSTOM_ENDPOINTS are used in Hegel - main.go/#L229.

[gianarb]

I have asked @mmlb about this because I am not really sure what Hegel does :)

[mmlb]

Yep lgtm

[mmlb]

Although maybe the workflows should be updated to hegel's default format? @gianarb should we deprecate workflows in favor of the ones from hub?

[mfranczy]

@gianarb @mmlb seems this breaks tinkerbell actions, for instance rootio expects that metadata output would be scoped to metadata.instance https://github.com/tinkerbell/hub/blob/main/actions/rootio/v1/pkg/types.go/metadata.go#L14, it doesn't expect the whole metadata object to be returned. How do you want to tackle this? I suggest that either the PR should be reverted and appropriate documentation should be added to old(?) workflows to change CUSTOM_ENDPOINTS or the actions should extract only the metadata.instance part from the response and unmarshal then. What do you think?

/cc @moadqassem