goSDN issueshttps://code.fbi.h-da.de/danet/gosdn/-/issues2024-01-11T15:21:05Zhttps://code.fbi.h-da.de/danet/gosdn/-/issues/345AddLink crashes goSDN when Link without correct port config is send.2024-01-11T15:21:05ZNeil-Jocelyn ScharkAddLink crashes goSDN when Link without correct port config is send.A Link contains Ports which contain a Configuration. If it is send without one, goSDN crashes hard.
The AddLink endpoint has validation, but the validation seems to be incorrect/broken/not good enough to catch this.A Link contains Ports which contain a Configuration. If it is send without one, goSDN crashes hard.
The AddLink endpoint has validation, but the validation seems to be incorrect/broken/not good enough to catch this.https://code.fbi.h-da.de/danet/gosdn/-/issues/232Northbound API validation2023-11-23T15:13:53ZAndre SterbaNorthbound API validationCurrently it is very easy to crash the controller by simply not providing a needed field via a NBI request.
E.g. create a new entity and don't provide some configuration field.
We should propably add a gRPC middleware that will check if...Currently it is very easy to crash the controller by simply not providing a needed field via a NBI request.
E.g. create a new entity and don't provide some configuration field.
We should propably add a gRPC middleware that will check if all defined fields in the proto definition are actually there and
reject the request if something is missing.
https://github.com/grpc-ecosystem/go-grpc-middleware/tree/master/validator
+
https://github.com/mwitkow/go-proto-validatorshttps://code.fbi.h-da.de/danet/gosdn/-/issues/152Internal Changes representation is not working as expected2023-06-16T09:23:57ZMalte BauchInternal Changes representation is not working as expectedWhile I've been looking into #145 I've discovered a few more bugs with intended changes ONDs, so called Changes in the goSDN environment.
## Description
<!--- Provide a more detailed introduction to the issue itself, and why you conside...While I've been looking into #145 I've discovered a few more bugs with intended changes ONDs, so called Changes in the goSDN environment.
## Description
<!--- Provide a more detailed introduction to the issue itself, and why you consider it to be a bug -->
If we consider the following scenario:
1. request a set for /system/config/hostname with a new hostname(a Change is created)
2. commit the requested Change. the commit is accepted and the Change is pushed to the OND (NOTICE: this Change will not be confirmed)
3. request a get for /system/config/hostname (this results in the device.Model being updated with the new hostname)
Now one would expect that after the defined expiration time, the Change is reset, since no confirm of the change has taken place. But the result is: no actual rollback took place.
Since the reference of the previousState of a Change points directly towards device.Model (see [here](https://code.fbi.h-da.de/danet/gosdn/-/blob/develop/nucleus/principalNetworkDomain.go#L316)), it is impossible to detect a difference between previousState and intendedState in this scenario.
This suggests that it would be necessary that previousState should be a reference to a copy of device.Model(instead of a reference to the actual device.Model) at the time of the initialisation of the Change.
However, this problem raises further questions:
1. What happens if there are multiple Changes and if there are confirms in-between?
2. What happens if the device has been modified from somewhere else?
3. ...
**Additional findings:**
- change.Confirm doesn't stop the timer, therefore a reroll will always be initiated
- If device.Model is empty a delete for the path is triggered
- If for a specific Change a reroll is executed, it is not possible to interact further with that Change. Hence, it is not possible in the further course, e.g., to have all Changes displayed. This is because the errChan is blocking, since it has no reciever (see [here](https://code.fbi.h-da.de/danet/gosdn/-/blob/develop/nucleus/change.go#L134)).
- After a COMMITED change has been rerolled, he keeps his state. Instead it should either be reset to PENDING or even be completly removed.v0.1.0 Codename ThreadbareMalte BauchMartin StiemerlingMalte Bauchhttps://code.fbi.h-da.de/danet/gosdn/-/issues/113CLI and CMD Integration Tests2023-06-16T09:23:57ZGhost UserCLI and CMD Integration Tests## Description
<!--- Provide a more detailed introduction to the issue itself, and why you consider it to be a bug -->
cliIntegration_test.go and cmdIntegration_test.go need to be updated to reflect changes introduced by commit-confirm ...## Description
<!--- Provide a more detailed introduction to the issue itself, and why you consider it to be a bug -->
cliIntegration_test.go and cmdIntegration_test.go need to be updated to reflect changes introduced by commit-confirm mechanic.
## Area of the system
<!-- This might only be one part, but may involve multiple sections !-->
Integration test
## How does this currently work?
<!-- the current process, and any associated business rules !-->
CLI and CMD integration tests do not reflect the latest changes introduced by commit-confirm mechanic.
## What is the desired way of working?
<!-- after the change, what should the process be, and what should the business rules be !-->
The changes should be tested properly.
## Priority/Severity
<!-- Delete as appropriate. The priority and severity assigned may be different to this !-->
- [x] High (This will bring a huge increase in performance/productivity/usability, or is a legislative requirement)
- [ ] Medium (This will bring a good increase in performance/productivity/usability)
- [ ] Low (anything else e.g., trivial, minor improvements)SORT