Consider matching the best `ResourceClass` for a given abstract resource about crossplane HOT 5 CLOSED

There are two models we could consider here that are not mutually exclusive.

developers uses classes to select known configurations

In this model, a developer selects a class by name to choose among different "configurations". This model is similar to Persistent Volumes in K8S today. It also is similar in how users select virtual machine classes in most cloud providers, i.e. m4.xlarge in AWS to select a well defines configuration of cpu, memory and local storage.

A downside to this approach is that the developer has to discover the class name, likely through documentation. If the classes change the app would need to change too, or the provisioner would need to map between older and newer compatible classes.

developers use granular abstract configuration and requirements

In this model, the developer specifies their requirements in a granular fashion. This is similar to Pods and their resources today in K8S. For example, in a pod spec you can specify:

      resources:
          limits:
            cpu: 100m
            memory: 100Mi
          requests:
            cpu: 99m
            memory: 100Mi

which could get matched to multiple kinds of nodes, or even along partial nodes without having to specify a class or machine type. There’s a mapping between these abstract cpu units 1m to a cloud provider: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/#meaning-of-cpu (edited)
and this abstraction of units enables more portability

In this model there would still be classes that are set by the admin, but they are not used by the developers directly. Instead they are used when creating/provisioning concrete resources. In other words, the admin specifies classes to define how physical resources are created. developers deal with abstract resources, units, configuration.

this model arguable has more portability, but might be more opaque.

from crossplane.

The issue as stated is a little confusing. It appears that the issue is confounded to the Dynamic Provisioning since this is the only time when a user would need to operate on ResourceClass construct. The way I understand the thrust of this issue, it would be great to "omit" the notion of the "ResourceClass" altogether (including the default classes).

While the issue provides "matching" example, the spirit of the example but using "resource" matching is very much in the realm of the Static provisioned resources, i.e. resources already exist and the Abstract resource simply needs to be matched against one or many existing resources. This is the confusing part.

I guess the thrust is, there are many ResourceClasses and "Scheduler" should pick one which matches closely the "AbstractResource" based on the resources defined in the "AbstractResource". If this is correct understanding, I think we can tag this issue as a "Scheduler" topic.

from crossplane.

Relates closely to #870.

from crossplane.

Cross linking relevant discussion from crossplane-contrib/provider-gcp#46 (comment).

from crossplane.

I think this is no longer relevant given that we're deprecating resource classes. I suppose we could do something like this for selecting a composition based on the composite resource's configuration, though I'm not sure whether we still see that as a direction we want to go. I'm going to close this - let me know if you want it to stay open and we can instead reframe it around composition.

from crossplane.