proposed Inspection and Provisioning diagram

[wrkode]

This PR addresses issue #258
Please understand that I'm not (yet) strong with Metal3, but would something like the be technically correct?

[wrkode]

@Rozzii could you please review the diagram for technical correctness?

[Rozzii]

Thanks for the contribution @wrkode I will check this soon.

[wrkode]

Thanks for the contribution @wrkode I will check this soon.

@Rozzii did you get a chance to look into it? I'm trying to understand if is technically correct. If correct. I'll propose a better visual and a diagram-as-code option.

[Rozzii]

@wrkode thanks for creating this nice diagram, a few nits:

• Please highlight that the machine object comes from CAPI and that between the Machine and the BMH there is a Metal3Machine object.
• You have mentioned how the inspections is initiated so I would suggest mentioning how the provisioning is initiated (it starts when the image field gets populated)
• There is a typo in the "Start Provisioning" block "etal3" instead of "Metal3"
• If you used draw.io or some other code->image generator please attach the source code also.
• At some point the community has agreed that we would use draw.io but I think that decision was not documented.
  cc @lentzi90 @mboukhalfa @kashifest

[lentzi90]

Thanks for working on this!
To keep things simple, I would advice to focus on just the Baremetal Operator level and the BareMetalHost resource for this diagram and not attempt to include Machines or Metal3Machines. Keeping that in mind, I would change the provisioning section so that the first two boxes are merged into one. There I would put something like

Image information
The spec.image field is filled with information about the desired provisioned state to start the provisioning process. This can be done by the user directly, or a controller such as CAPM3.

In the Store Data box it may be worth mentioning the HardwareData CRD, I'm not sure.

[Rozzii]

Thanks for working on this! To keep things simple, I would advice to focus on just the Baremetal Operator level and the BareMetalHost resource for this diagram and not attempt to include Machines or Metal3Machines. Keeping that in mind, I would change the provisioning section so that the first two boxes are merged into one. There I would put something like

Image information
The spec.image field is filled with information about the desired provisioned state to start the provisioning process. This can be done by the user directly, or a controller such as CAPM3.

In the Store Data box it may be worth mentioning the HardwareData CRD, I'm not sure.

I can get behind this also, then let's skip mentioning Metal3Machine and Machine objects.

[Rozzii]

/ok-to-test

[kashifest]

Thanks for working on this! To keep things simple, I would advice to focus on just the Baremetal Operator level and the BareMetalHost resource for this diagram and not attempt to include Machines or Metal3Machines. Keeping that in mind, I would change the provisioning section so that the first two boxes are merged into one. There I would put something like

Image information
The spec.image field is filled with information about the desired provisioned state to start the provisioning process. This can be done by the user directly, or a controller such as CAPM3.

In the Store Data box it may be worth mentioning the HardwareData CRD, I'm not sure.

+1

[wrkode]

I'll have an updated version soon. thanks for the feedback folks.
for this I've use Excalidraw, but I want to use draw-io, so that I can share code.
expect a new version soon.

[dtantsur]

The diagram is mostly correct (I don't think inspection depends on the online field; there is a typo in metal3), but I'm curious what the purpose of it is. It's not linked in any document, and we probably have documents explaining the similar thing.

[wrkode]

The diagram is mostly correct (I don't think inspection depends on the online field; there is a typo in metal3), but I'm curious what the purpose of it is. It's not linked in any document, and we probably have documents explaining the similar thing.

@dtantsur, I was working against #258, but if you and team find this no more relevant, I can stop and close the PR. please do let me know though.

[Rozzii]

The diagram is mostly correct (I don't think inspection depends on the online field; there is a typo in metal3), but I'm curious what the purpose of it is. It's not linked in any document, and we probably have documents explaining the similar thing.

@dtantsur, I was working against #258, but if you and team find this no more relevant, I can stop and close the PR. please do let me know though.

@dtantsur @wrkode I think the original idea was to have Metal3 specific diagrams, I agree that it has to be part of the user-guide.

[metal3-io-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues will close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[Rozzii]

@wrkode are you still interested to finish this?

[metal3-io-bot]

Stale issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle stale.

/close

[metal3-io-bot]

@metal3-io-bot: Closed this PR.

In response to this:

Stale issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle stale.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.