Add Initial version of proposal for DRA mode #88
Conversation
This PR adds a proposal to implement a Dynamic Resource Allocation mode for Akri, it details why we would like to switch to a DRA mode, and what changes are needed as well as a proposed timeline. Signed-off-by: Nicolas Belouin <nicolas.belouin@suse.com>
diconico07
requested review from
kate-goldenring,
bfjelds,
romoh,
jiria,
edrickwong and
johnsonshih
as code owners
| You can note that we do **not** include the name of the discovery handler as it would be in the driver name in ResourceClass | ||
| as a subdomain of `driver.akri.sh` like e.g. `udev.driver.akri.sh` |
There was a problem hiding this comment.
I wonder if that's the best idea to have a driver name per DH, maybe having a single driver.akri.sh DRA driver name is better and thus re-introduce discovery handler name in the DiscoveryConfiguration, as it would remove any ambiguity about what DH the configuration is for.
Another idea here was to have a dedicated CRD per DH so that way there is no ambiguity on what DH a configuration is for, but it would make creating a DH more cumbersome as one would also need to create a CRD. It would also make it harder for the agent as it would need to extract information from a possibly non akri CRD, hence I did not pursued on this idea.
There was a problem hiding this comment.
Another argument against different CRDs is that the ability to tie things together with downwards api seems useful here and an increase in resource types could make building higher level tooling harder (UI for instance)
|
|
||
| ```yaml | ||
| # apiVersion got ommited on purpose | ||
| kind: BrokerTemplate |
There was a problem hiding this comment.
I wonder if ResourceTemplate might be more obvious to users? Broker can be a bit confusing IMO
There was a problem hiding this comment.
That said, the change in language might be it's own proposal...
| The DRA is not yet in beta phase, we should provide this new behavior along with the "old" one as long as all our supported kubernetes | ||
| versions don't have the needed features, however some parts of the new behavior can be implemented without waiting for DRA to be broadly available. | ||
|
|
||
| Here is a proposed timeline: |
| globalBrokerResources: ... # this field is named configurationBrokerResources in other proposal | ||
| ``` | ||
|
|
||
| ### Create a `DiscoveryConfiguration` resource kind |
There was a problem hiding this comment.
This is a cluster-scoped resource kind, as ResourceClasses are cluster-scoped. In fact while we currently have namespaces for our Configurations the DevicePlugin resource is expose outside this namespace, so it would makes more sense to have it cluster scoped anyway.
This PR adds a proposal to implement a Dynamic Resource Allocation mode for Akri, it details why we would like to switch to a DRA mode, and what changes are needed as well as a proposed timeline.
This is a first version, while I tried to specify everything that would be needed to understand in the proposal, don't hesitate to ask for more details.