docs: create a flow diagram of the Ignition services

[cadejacobson]

While looking through the Ignition booting documentation, I was attempting to piece together how each service interacts with each other and ended up creating a flowchart of the ordering of some of the services. I figured this visual diagram could be useful to other new contributors to the project, and am happy to expand on, or correct, any relationship here as needed.

[gemini-code-assist]

Code Review

This is a great initiative to visualize the Ignition boot flow, which will be very helpful for new contributors. The diagram is well-structured. I've left a few comments with suggestions to improve the accuracy of the flow in the 'Network Stack' and 'Ignition Fetch' sections, and a minor styling suggestion for consistency. Overall, this is a valuable addition to the documentation.

[gemini-code-assist]

This part of the flow could be misleading. Requesting cloud-specific configs (D2) and opening a config device like /dev/sr0 (D3) are typically alternative actions that depend on the detected platform, rather than sequential steps. The current diagram with D2 --> D3 suggests one follows the other. It would be more accurate to represent them as alternative paths.

[gemini-code-assist]

The order of operations in the network stack appears to be incorrect. The network.target (N5) is reached only after the network is fully configured, which includes acquiring an IP address via DHCP (N6). Therefore, N6 should come before N5 in the sequence.

Suggested change

	N1 --> N2 --> N3 --> N4 --> N5 --> N6
	N1 --> N2 --> N3 --> N4 --> N6 --> N5

[gemini-code-assist]

The node N1 represents systemd-networkd.service but it's not styled as a service. For consistency, it should be included in the service class definition.

Suggested change

	class A,B,C,D,E,F,H,I,J,K,N4 service
	class A,B,C,D,E,F,H,I,J,K,N1,N4 service

[cjp256]

if ignition-fetch.service is after network.target, how do we know if the DHCP succeeded?

[cadejacobson]

When running through the services and targets (at least on Flatcar), the actual queries to the cloud platforms may be started before the DHCP request has been completed. For example, here are some of the journalctl logs from a recent machine:

We see:

1. The link come up
2. The system reach network.target
3. Ignition-fetch.service begin (which is also corroborated in the systemd service file found below:)

   ignition/dracut/30ignition/ignition-fetch.service

   Line 22 in 66a64cd

   After=network.target

4. Calls to the IMDS user-data begin and fail (presumably because DHCP has not been completed)
5. The DCHPv4 address 10.0.0.4 return
6. IMDS user-data is successfully queried (attempt 7)

To answer your question, ignition-fetch.service does not necessarily know that DHCP has succeeded, but it relies on DHCP to do so before the calls to IMDS exhaust the retries.