Module output label exceeds 63 char limit length

[nabadger]

Operator Version, Kind and Kubernetes Version

• Operator version: v2
• Kind: Module
• Kubernetes version: 1.27

Output Log

2024-06-05T07:53:34Z    ERROR   Reconcile Module Outputs    {"module": {"name":"a-very-long-module-name-exceeding-the-char-limit","namespace":"default"}, "mgs": "failed to create or update ConfigMap a-very-long-module-name-exceeding-the-char-limt-module-outputs", "error": "ConfigMap \"a-very-long-module-name-exceeding-the-char-limit-module-outputs\" is invalid: metadata.labels: Invalid value: \"a-very-long-module-name-exceeding-the-char-limit\": must be no more than 63 characters"}

Steps To Reproduce

Create a module with a long name exceeding the 63 char limit length.

The name of the module is attached as a label to the generated configmap (which then causes this error).

Expected Behavior

Since the limitation is known ahead of time, it might be a good idea to catch this at the time the module is created?

I don't think it's wise to truncate the name, although that would get around the issue too...

Actual Behavior

The module gets created, but the associated ConfigMap (in our case) does not.

There are errors in the operator log as well as ReconcileModuleOutputs events.

Additional Context

In our case our module names are long because they are auto-generated. In the v1 operator this wasn't an issue since I don't believe the labels were propagated, but they are in the v2.

I can attempt to shorten the module names (but we have lots!) and I've only spotted this issue late on in our migration plan..so it's a bit painful :)

---

In our case, I don't believe we're making use of the module outputs - could they be optional? Or could the labels propagation also be optional?

References

Community Note

• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.
• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request.
• If you are interested in working on this issue or have submitted a pull request, please leave a comment.

[nabadger]

Although more of a feature request, making the outputs optional would really be beneficial to us and help us get of the v1 operator.

Or given we don't use this, can we safely ignore this error for now?

[arybolovlev]

Hi @nabadger,

Thank you for raising this issue. I think we can get rid of this label, it looks a bit redundant since the same information can be obtained from metadata.ownerReferences.

I will work with @jtdoepke on PR to fix this.

[nabadger]

Thanks @arybolovlev

I've also noticed that the outputs for configmaps/secrets get created with empty values for us. I think this because in our case we don't specify the outputs: field in the Module/Workspaces. Do you think it's worth opening a feature-request to skip generation of these resources if no outputs specified?

[arybolovlev]

That is an interesting observation, @nabadger! Could you please raise a new issue for this request? This will be a good step toward a more reliable output solution since now outputs can duplicate which might be a problem on a big scale.

Thanks!