Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce stricter typing for ConfigMap insights #19

Open
bomoko opened this issue Feb 25, 2024 · 0 comments
Open

Introduce stricter typing for ConfigMap insights #19

bomoko opened this issue Feb 25, 2024 · 0 comments

Comments

@bomoko
Copy link
Collaborator

bomoko commented Feb 25, 2024

Currently, Insights-Remote makes no real distinction between configMap types and will simply send along absolutely anything to the insights-core.

While this is useful from one perspective, it also makes building expectations into the insights-handler difficult, having to handle practically any payload.

It would be good to build the following into the insights-remote

  1. ConfigMaps with multiple entries in their payloads are disallowed. That is, a single file per configMap only.
  2. Since it's already the defacto case, we should restrict configMaps to only those which support binaryPayloads
  3. We should explicitly specify labels for data types that are sent through - that is, inspect info, sboms, etc. This will obviate needless data type identification on the insights-handler side.

Suggestions here are

  1. to explicitly type the CM at creation time - for now this will live in the build-deploy-tool . This should conform to Proposal: standardise on styling for kubernetes labels used by Lagoon lagoon#3597
  2. To explicitly reject untyped configMaps - this is wrapped as a feature flag to support deprecation over multiple versions
  3. Reject any payloads with len > 1
  4. Move to a single payload item, and not passing a map of byte strings.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant