Architecture: add high level view section

[bleader]

• Add very high view
• Add the main building block details and interaction

Before submitting the pull request, you must agree with the following statements by checking both boxes with a 'x'.

• "I accept that my contribution is placed under the CC BY-SA 2.0 license [1]."
• "My contribution complies with the Developer Certificate of Origin [2]."

[1] https://creativecommons.org/licenses/by-sa/2.0/
[2] https://xcp-ng.org/docs/contributing.html#developer-certificate-of-origin-dco

[ydirson]

xl does not talk to XAPI, it would be better described as something like "lower-level Xen tool bypassing XAPI", and xe as "CLI to a subset of the XAPI interface"

xe has a lowercase "c" as language

"storage stack" should likely include python in languages (for SM and the SR drivers)

The VMs would likely be useful to show. This would allow to show how how all interaction with VMs go through Xen.

"guest tools" run inside the guest, and currently get info from the guest only (mostly from the guest OS kernel), not from any other XCP-ng component. Currently written in Go.
It would also be important to show the PV drivers, since there is often a confusion between them and the guest tools, as both are distributed as a single package for Windows guests.

[bleader]

I remade the diagrams that were done in drawio using structurizr lite instead, so the diagrams are sligthly different beyond the changes related to your comments :)

1. I linked xl directly to xen and used your suggested description
2. I used your suggested description for xe, and language should be C everywhere it's needed
3. I added Python in the languages for Storage Stack
4. I added the VMs as a separate and external SoftwareSystem
5. I removed the 'guest tools' from the XCP-ng SoftwareSystem box, added them to the VMs system, and switched language to Go
6. I also added the PV driver

In a separate commit I added a short network section, and added the zoom in the 'Network Stack' section, where I show the 2 parts of the PV drivers, unfortunately I wasn't able to make structurizr show that the 'PV drivers` part is inside the VM, not fully satisfied with that.

I hope it is better this way.

For reference, current .dsl file to generate these is available on c4-draft

[ydirson]

• I think we should also have a "XAPI -configures-> xl" link
• Most PV Drivers configuration comes from XAPI through Xenstore (configuration of frontend devices, memory target for balloon driver, triggering PM events, ...)
• Today Guest Tools control over the Guest OS is very limited: none for the Unix guest tools, and Windows Guest tools only have CopyPaste and (optional) Command Execution, that I'm aware of
• Maybe a "controls" link of some sort from Xen to GuestOS
• Maybe some "provides storage" from Storage Stack to PV Drivers

[bleader]

• I went with "XAPI - configures xen using -> xl" as it is not configuring xl itself, but using it
• I added a link between xapi and pv drivers, ideally, it should be from xenstore at the "component level" but I don't feel like doing the lower level diagram of XAPI yet
• I remove the "Controls" link, not sure if it was what you had in mind? But I'm all for a little less clutter! I had in mind the fact that we can reboot/power off machines with XO when guest tools are installed, that's why I added this.
• You're right, I went with an outside line to avoid crossing, not very readable, but maybe better than crossing lines
• Again, that's a good point, I missed it because I only did the link between "lower" layer of representation in network stack and PV drivers (which automatically creates the links at this level). I added it.

[stormi]

AFAIK XAPI doesn't use xl. It uses xc, through xenopsd-xc.

A general comment : I'm not sure a pull request is the best tool to collaborate on these diagrams. Making a draft (like you did) then trapping a few people in a (virtual) room with the objective of finalizing them would work better in my eyes.

[ydirson]

git grep xl ocaml/xenopsd/xc/ in xen-api does show a couple of matches, even it's not much. Looks like they rather call xl rather than link to libxl, yuck. Comment even says XXX: we don't want to use the 'xl' command here because the "interface" isn't considered as stable as the C API, but still they're doing just that.

[ydirson]

Maybe make "Xen project" and "XAPI project" software components to make it visible XAPI+tools is a layer above Xen+tools? Would make it harder for the Network Stack, since that one would then be spread between those 2 layers... likely more efficient to have a live discussion, yes :)

[gthvn1]

In fact xenopsd has several possible backends. xc is one of them but there is also Xenlight (so libxl). And it has some others. So IIUC it can use both.
But as said "don't use xl but do it quand meme" :-)

[ydirson]

That's what's written in the XAPI arch documentation, but that's outdated. The "xenlight" backend was removed several years ago, but the doc was not updated.
See xapi-project/xen-api#5021