Add the split configuration proposal

[diconico07]

As discussed during the Community Meeting, here is the split configuration proposal on its own.

This proposal aims to split the configuration object in two objects

This change is needed for or can facilitate the implementation of several existing proposals:

• Add Initial version of proposal for DRA mode #88
• proposal: Arbitrary broker resource type #75
• Add proposal for status field in akri resources #77

Moreover, while this proposal tries to be as small as possible and stick as close as possible to the current behavior, several future enhancements or changes can already be envisioned while working on this proposal (these are here as future possibilities, and will be their own proposals if we feel we want to pursue those):

• Allow a WorkloadConfiguration to trigger on Instances properties rather than the DiscoveryConfiguration it is linked to, this could allow workload to be scheduled to only a subset of the discovered devices, or spanning over multiple DiscoveryConfigurations;
• Share Instances between DiscoveryConfigurations, if multiple DiscoveryConfigurations discover the exact same device, we may want to merge those as one Instance owned by several DiscoveryConfigurations;

[bfjelds]

i wonder if capacity isn't a workload property? in my mind, it impacts how many workloads can exist at once more than being a reflection on anything discovered.

[diconico07]

The workloadConfiguration describes the workload akri is creating by itself, the capacity describes how many simultaneous users a given device can handle, be it one akri scheduled or one the user scheduled with some other way.
So I believe the capacity is a property of a device in that way, I even wonder if we shouldn't have the capacity in the Instance somehow.

[diconico07]

This also makes sense for responsibility distribution, as the "agent" is currently responsible for managing the slots and it should be the one to manage the Discovery Configuration.

The "controller" on the other hand will manage the Workload Configuration.

The Instances will get created by the "agent" and read by the "controller".

I'll add a paragraph in the proposal about this.

[bfjelds]

I even wonder if we shouldn't have the capacity in the Instance somehow

historically, the Configuration was the place for a user to configure an Instance. if we are splitting Configuration into Discovery and Workload, i think capacity belongs in Workload. If we are introducing a third split (Discovery, Workload, and Instance), i can see it fitting in either Workload or Instance.

[diconico07]

To me the DiscoveryConfiguration is all about getting Instances created and configured and the WorkloadConfiguration is all about creating the "workload" (or as it is currently known "broker").

This split has multiple ideas behind it:

• you can use akri with "manual" workload scheduling (as per Requesting Resources) without a WorkloadConfiguration.
• we get rid of the namespaces for Instances (as it doesn't make sense since the resource is exposed and usable from any namespace as it is exposed by the node resource)

If we have the capacity in the WorkloadConfiguration, then the agent will need to read a WorkloadConfiguration to be able to create the DevicePlugin, so it means you must have a 1:1 relationship between a WorkloadConfiguration and a DiscoveryConfiguration.

[kate-goldenring]

I am more aligned with adding capacity to the DiscoveryConfiguration. To me, using the WorkloadConfiguration is an add on to akri and not everyone will use it -- they may apply their own deployments. On the other hand, discovering and specifying a capacity for a device is essential to Akri and should belong in discovery. It is also something that is managed through the device plugin so it should fit in the Agent's control loop which is the discovery one.

[kate-goldenring]

This is looking great! I like the idea you give of adding a paragraph on the following in an "implementation" section:

The "controller" on the other hand will manage the Workload Configuration.

The Instances will get created by the "agent" and read by the "controller".

I'll add a paragraph in the proposal about this.

[kate-goldenring]

I wonder if this should exist in the workload configuration, since these are environment variables that are set in every workload that uses the device. For example, setting frame rate for a udev camera here doesn't quite make sense

[diconico07]

These properties are stored at the device plugin level and managed by the agent, I think it can make sense to want to add information about a udev device that is unknown to the discovery handler, but of use to any consumer of the device: e.g. one craft a udev query to select modbus adapters and knows the device behind these uses address 0x42 and this is not discovered by the udev DH, so the DiscoveryConfiguration writer wants this information to be carried to the consumers of the discovered devices.

In the workload configuration, one can just add any additional property through pod/job/whatever env list.

[kate-goldenring]

Are we using the term discovery selector instead of "discovery handler"

[diconico07]

well here we do not point to a discovery handler, but to a discovery configuration, so the full name should be discoveryConfigurationSelector, I shortened it to discoverySelector to make it simpler.