Custom configuration design proposal #275
Conversation
niket-intc
requested review from
Andrea-Campanella,
se-chris-thach,
mdbalvin,
rad-szulim,
charlesmcchan,
yi-tseng-intel,
ashridatta,
teone,
callumnobleintel,
daniele-moro,
SeanCondon,
pierventre,
cgoea,
emmakenny,
PalashGoelIntel,
palade,
pperycz,
ltalarcz,
jakubsikorski,
sys-orch-approve,
ahalimx86,
johnoloughlin and
garyloug
as code owners
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
There was a problem hiding this comment.
Thank you for your contribution! Please make sure to review our Contributing Guide.
ajaythakurintel
added
the
Proposal
|
|
||
| ***Data-Model*** example of custom-config : | ||
|
|
||
| ```yaml |
There was a problem hiding this comment.
Do we want to add an enum kind to differentiate in the future between different config?
| ``` | ||
| The instance resource data-model has to be updated to include custom-config resource. | ||
|
|
||
| The relationship between an instance and its custom configuration shall be one-to-many. Each instance can be associated with one or more than one pre-created custom configuration. The onboarding manager will create cloud-init file based on number of cloud-init files added by user. We can ristrict the number of cloud-init file that canbe associated to a instance to 5. |
There was a problem hiding this comment.
I believe here we mean many to many, not one to many. Do we want the same config to be usable across different Instances or not?
There was a problem hiding this comment.
Who enforces the limit? Do we want to support multiple cloud-init from the very beginning?
There was a problem hiding this comment.
Ok, I will correct it,
We want to keep it as part of ADR as user might want to split features in multiple cloud-init. @daniele-moro
There was a problem hiding this comment.
I guess we can enforce the limit in Inventory? Shall we restrict the operations to not allow updates (PATCH)? I guess we cannot patch after the provisioning so we cna use the same approach of the LocalAccount
| During provisioning, the Onboarding Manager shall check the instance. If the custom-config contains the cloud-init file, it will be copied along with the existing default EMF EdgeNode cloud-init. Since the custom-config is optional, no action is required if the cloud-init file is not present. There will be no error handling for user cloud-init failures. | ||
|
|
||
| #### 4. Updates to Bulk Import Tool | ||
| The Bulk Import Tool has to be enhances to : |
There was a problem hiding this comment.
| The Bulk Import Tool has to be enhances to : | |
| The Bulk Import Tool has to be enhanced to: |
|
|
||
| #### 4. Updates to Bulk Import Tool | ||
| The Bulk Import Tool has to be enhances to : | ||
| - Include custom-config resourceID in .csv file |
There was a problem hiding this comment.
potentially multiple custom-config?
There was a problem hiding this comment.
I will fix it. I need to think in terms of cli tool also.
There was a problem hiding this comment.
I believe we should work directly in the new CLI and not improving BIT
There was a problem hiding this comment.
in BIT we provide names when possible and we dont expose directly the ids
| note over user : User creates a custom cloud-init config yaml. | ||
|
|
||
| user ->> inv : Create custom-config resource providing cloud-init config yaml. | ||
| note over inv : API does basic yaml validation of the cloud-init config file. |
|
|
||
| The UI shall provide interface to the user during Host registration page to associate or Map the earlier created custom-config. The UI can be similar to that of LocalAccount Page were it shows the list of LocalAccount to associate. | ||
|
|
||
| Once the provisioning is completed, the cloud-init data should be immutable; no edit or delete options should be available. Users should only be able to view the cloud-init configuration under host details. |
Description
This PR presents the design proposal for the custom configuration of EdgeNode.
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: