[onboarding-manager<->device discovery]Node Onboarding without SN

[ipsita-npg]

Description

Problem statement:

In the 3.0 release Most of our platform, we have encountered an issue with the handling of serial numbers, from certain hardware manufacturers, specifically ASRock and AAEON. These manufacturers often provide serial numbers that do not conform to the expected pattern, leading to complications in edge node onboarding process.

AsRock Default Serail Number is "To Be Filled by O.E.M"
AAEON UP Squared Pro 7000 / Atom - Unable to provision - serial number is "Default string"

Current Design:
The Device Discovery Agent is responsible for fetching the serial number of devices. It retrieves this information directly using the dmidecode command and it is sent as part of a gRPC request to the Onboarding Manager.
Onboarding Manager expects serial numbers to follow a predefined pattern. When it receives a serial number that does not match this pattern, it throws an error.This error is communicated back to the Device Discovery Agent, indicating that the serial number is invalid.As a result, the edge node provisioning process becomes stuck in the device discovery phase, unable to proceed further due to the invalid serial number.

Fix:
The device discovery agent send the UUID and the serial number(even if improper format).The onboarding manager can proceed with onboarding and provisioning based on the UUID and bypass the serial number validation check, even if it is in the in-correct format.

Unit Testing : Existing unit test cases are failing - In progress
IO and NIO based dev validation is done with real edge node

Fixes # (issue)

Any Newly Introduced Dependencies

Please describe any newly introduced 3rd party dependencies in this change. List their name, license information and how they are used in the project.

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Checklist:

• I agree to use the APACHE-2.0 license for my code changes
• I have not introduced any 3rd party dependency changes
• I have performed a self-review of my code

[osinstom]

Awesome PR description, thanks!

Two questions:

1. Should we fill Serial Number with invalid value If OM finds out it's not set? In that case we will propagate whatever will be set in EN. Make sure to check with the UX team if that's ok. An alternative would be to keep it empty and show "Not set" in UI.
2. What's the impact on the host registration process? Will we enhance documentation to make UUID mandatory in the referenced cases?

[ipsita-npg]

Awesome PR description, thanks!

Two questions:

1. Should we fill Serial Number with invalid value If OM finds out it's not set? In that case we will propagate whatever will be set in EN. Make sure to check with the UX team if that's ok. An alternative would be to keep it empty and show "Not set" in UI.
2. What's the impact on the host registration process? Will we enhance documentation to make UUID mandatory in the referenced cases?

@osinstom : , we are verifying the validity of the patterns on the infra-api and UI sides to ensure that only valid patterns are accepted during host registration via UI. https://github.com/open-edge-platform/infra-core/blob/16cfd45a1820e678390e70126ca663c1be622e6a/apiv2/api/proto/services/v1/services.proto#L1013
The UI strictly enforces UUID-based registration, preventing any incorrect serial patterns from being registered.

This PR is dedicated to improving southbound communication.
During the device discovery phase, if the onboarding manager encounters an invalid serial pattern, it will set empty string "N/A" in the serial number field and proceed with UUID-based registration.

[ipsita-npg]

1. Should we fill Serial Number with invalid value If OM finds out it's not set? In that case we will propagate whatever will be set in EN. Make sure to check with the UX team if that's ok. An alternative would be to keep it empty and show "Not set" in UI.

Awesome PR description, thanks!
Two questions:

1. Should we fill Serial Number with invalid value If OM finds out it's not set? In that case we will propagate whatever will be set in EN. Make sure to check with the UX team if that's ok. An alternative would be to keep it empty and show "Not set" in UI.
2. What's the impact on the host registration process? Will we enhance documentation to make UUID mandatory in the referenced cases?

@osinstom : , we are verifying the validity of the patterns on the infra-api and UI sides to ensure that only valid patterns are accepted during host registration via UI. https://github.com/open-edge-platform/infra-core/blob/16cfd45a1820e678390e70126ca663c1be622e6a/apiv2/api/proto/services/v1/services.proto#L1013 The UI strictly enforces UUID-based registration, preventing any incorrect serial patterns from being registered.

This PR is dedicated to improving southbound communication. During the device discovery phase, if the onboarding manager encounters an invalid serial pattern, it will set empty string "" in the serial number field and proceed with UUID-based registration.

Awesome PR description, thanks!
Two questions:

1. Should we fill Serial Number with invalid value If OM finds out it's not set? In that case we will propagate whatever will be set in EN. Make sure to check with the UX team if that's ok. An alternative would be to keep it empty and show "Not set" in UI.
2. What's the impact on the host registration process? Will we enhance documentation to make UUID mandatory in the referenced cases?

@osinstom : , we are verifying the validity of the patterns on the infra-api and UI sides to ensure that only valid patterns are accepted during host registration via UI. https://github.com/open-edge-platform/infra-core/blob/16cfd45a1820e678390e70126ca663c1be622e6a/apiv2/api/proto/services/v1/services.proto#L1013 The UI strictly enforces UUID-based registration, preventing any incorrect serial patterns from being registered.

This PR is dedicated to improving southbound communication. During the device discovery phase, if the onboarding manager encounters an invalid serial pattern, it will set empty string "" in the serial number field and proceed with UUID-based registration.

In order to streamline the host registration and provisioning process, we will enhance the doc state that user can only use UUID-based host pre-registration if any invalid serial number is retrieved from a node does not fit the serial number pattern.