Metal3 future architecture with multi-tenancy

[lentzi90]

I want to take the opportunity to gather three proposals in one discussion since the discussions anyway seem to get tangled.
The proposals are:

• DHCP-less IPAM
• CAPI multi-tenancy for CAPM3
• BareMetalHost API decomposition

In my head they fit together beautifully. There is just one open question about where/how the metaData and networkData should be handled. But I'm probably missing a lot of details.

To get started, I have attempted to draw a simplistic diagram of how things could fit together. I don't know if this is useful/understandable but I hope so.

(I know there are many resources missing in this picture but I didn't want to clutter it more. If I missed something essential please let me know!)

CAPI multi-tenancy is mostly about the vertical dotted line. The point is to strap CAPM3 of its privileges to manage any/all BMHs. Instead the user must explicitly give it credentials to the resources it should use. This is the equivalent of how other CAPI providers accept cloud credentials to get access to a specific tenant in GCP/AWS/OpenStack where they manage the cloud resources.

BMH API decomposition is more about the horizontal dotted line as I see it. Here we want to separate the consumer of a BMH from the admin who makes these baremetal resources available. This is also where the DHCP-less proposal comes in I think, because the admin will need to handle preprovisioning, whereas the consumer may need to have control over the network after provisioning.

That last part is an open question for me, as mentioned. I'm not sure if the consumer should always control the networkData for example. Or perhaps this must be configurable? In some situations it should be the admin and in other the consumer?

I would be very happy to hear opinions on this. Do you agree with what I wrote? Does the diagram make sense? What have I missed? 😄

[Rozzii]

For additional context: https://groups.google.com/g/metal3-dev/c/Wl2DIdr_ZQ0