Describe the bug
When a labinstance referencing a labtemplate with field labNum non numeric is created, the operator crashes.
To Reproduce
Steps to reproduce the behavior:
Create a new labtemplate, setting labNum to any non numeric string
Create a new labinstance, referring to the previously created labtemplate
Check the status of the operator
Expected behavior
The reconciliation should be completed correctly or, alternatively, the insertion of the incorrect labtemplate should fail in the first place.
Yet, I believe that in the longer term it is necessary to develop a cleaner and simpler version of the labtemplate CRD. Then, this field may be no longer necessary
Describe the bug When a labinstance referencing a labtemplate with field
labNum
non numeric is created, the operator crashes.To Reproduce Steps to reproduce the behavior:
labNum
to any non numeric stringExpected behavior The reconciliation should be completed correctly or, alternatively, the insertion of the incorrect labtemplate should fail in the first place.
Additional context In the short term, I would focus on fixing this bug to enable non-numeric values. Apparently, it is due to a mismatch between the CRD definition considering the
labNum
value of type string: https://github.com/netgroup-polito/CrownLabs/blob/630f0eaef444b20714cdb93151bc1bf0f1937871/operators/labInstance-operator/labTemplate/crd/bases/template.crown.team.com_labtemplates.yaml#L47-L48 and the API, wherelabNum
is of type numeric: https://github.com/netgroup-polito/CrownLabs/blob/630f0eaef444b20714cdb93151bc1bf0f1937871/operators/labInstance-operator/labTemplate/api/v1/labtemplate_types.go#L28Yet, I believe that in the longer term it is necessary to develop a cleaner and simpler version of the labtemplate CRD. Then, this field may be no longer necessary