EIM API design #1308
EIM API design #1308
Conversation
damiankopyto
requested review from
Ram-srini,
SushilLakra,
cjnolan,
garyloug,
guptagunjan,
hyunsun,
johnoloughlin,
krishnajs,
palade,
rranjan3,
scottmbaker,
shankarsrinivas1,
soniabha-intc and
sys-orch-approve
as code owners
There was a problem hiding this comment.
smth to check with other ADR owners - will inventory resources be also reduced/adjusted to support certain scenarios (so we have a different inventory image per scenario?) this could break backward compatibility of the host manager. thus. probably inventory will be generic for all scenarios .. (???)
|
|
||
| - Onboarding service APIs | ||
|
|
||
| It is assumed that provisioning/instance creation and creation of associated resources related to provisioning is not needed. |
There was a problem hiding this comment.
It needs double checking if this scenario can work without instance creation. I can see that onboarding manager performs operations on the instance resource (other that creating it). https://github.com/open-edge-platform/infra-onboarding/blob/ad4c18d82cbcc237b5b7ba622b27b4294c559a38/onboarding-manager/internal/handlers/controller/reconcilers/instance.go If the instance resource is missing, the onboarding manager may break unless its logic is adjusted to support onboarding without provisioning and instance manipulation.
There was a problem hiding this comment.
Yes - the assumption made here was that we will have a "smaller" onboarding manager that will not do anything provisioning related, but let's check in with the team.
There was a problem hiding this comment.
probably this should be same onboarding manager with an option to turn off provisioning like stated in another ADR. so there is no need to maintain separate OMs. But lets check with others.
There was a problem hiding this comment.
Based on current discussions, sounds like vpro scenario needs instance resource to support day2 OS updates in future.
| 1. User pre-registers host via the orch-cli using the *host service* EIM API (by providing the UUID and/or Serial No.) - there is no need to create an instance, or allocate EN to site since there is no EN management outside of vPRO related actions. | ||
| 2. User provisions own OS onto the EN manually and installs the Device Activation Agent (DAA), the agent communicates with the scaled back version of Onboarding Manager. | ||
| 3. If the information from ENs DAA matches the information provided at pre-registration (Serial/UUID) the scaled back version of the Onboarding Manager changes the status of the EN to onboarded in the *host resource* (host_status) in the inventory and creates/responds to the DAA on the EN with credentials for the PMA agent. | ||
| 4. User installs the PMA agent, and PMA agent waits for credentials. Remote Provisiong Client (RPC) is also installed. |
There was a problem hiding this comment.
Just wonder if this step cannot be automated ..
There was a problem hiding this comment.
I expect the installation of agents/EN to be somewhat automated, but in this description wanted to just focus on the actions/flow.
There was a problem hiding this comment.
Sure, this is actually out of scope for this particular ADR - if this is manual or automated.
There was a problem hiding this comment.
BTW I see that it could be handled by installer script:
Description
This PR provides detailed design for EIM decomposed API
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: