Skip to content

epic: Introduce virtual resources #3292

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
3 of 6 tasks
mjudeikis opened this issue Feb 11, 2025 · 0 comments
Open
3 of 6 tasks

epic: Introduce virtual resources #3292

mjudeikis opened this issue Feb 11, 2025 · 0 comments
Assignees
Labels
epic Represents a larger feature with multiple stories

Comments

@mjudeikis
Copy link
Contributor

mjudeikis commented Feb 11, 2025

Demo Objective

When creating APIs for service providers, we might want to have a few levels of APIs:

  1. Provider produced and consumer instantiated/created. This is covered by current APIExport behaviour.,
  2. Provider produced and consumer read. This is not covered now by anything.

An example would be a compute service provided by provider X:

apiVersion: machines.svm.io/v1alpha1
kind: VirtualMachine
metadata:
  name: bobs-dev-machine
  namespace: dev
spec:
  instanceTypeRef:
    resource: InstanceTypes
    group: machines.svm.io
    name: simpleVmTypeSmall
    type: corev1.ObjectReference
  secret: # corev1.LocalObjectReference type
    name: vm-ssh-key

where virtualmachiens.machines.svm.io/a1apha1 is user-created and provider-maintained, the user will need to refer to instance type instanceTypeRef, which is something the provider should deliver to every consumer of this API to be able to read and use.

This is what we call a VirtualResource. The resource can be "projected" into the user workspace/cluster but not acted on, modified, or deleted. It is just there to be read and referred to.

One of the goals to achieve this is an easy-to-understand API and as small a mental overhead for users as possible.
APIExport/APIbinding are already hard concepts for a newcomer to understand, so we should try to keep it simple.

Mini write-up is here: https://docs.google.com/document/d/18Xh2-VFnH23bDiAHPP_JXm4qAG4QK6GjTKcpszPGApQ/edit?tab=t.0

The initial proposed implementation is this:

  1. Change APIExport schemas API:
  latestResourceSchemas:
    - today.cowboys.wildwest.dev
  resourcesSchemas:
  - schema:  today.cowboys.wildwest.dev
    storage: crd
 - schema: instances.compute.corp.io
   storage: virtual
  permissionClaims:

to introduce a new field (deprecate old). Where we have typed schema types in the APIExports, this allows more flexible management of the schemas and schema types, storage ways, etc. It opens doors to reuse the same API for more, as shown in the example.

  1. Once we do this, we can start working on secondary virtual resource schemas by creating a new storage layer and working on an aggregated APIServer pattern for resource representation in the workspace.

There is still an open question of how we get data from these virtual resources as the schema is just spec, not data.

Demo Steps

No response

Action Items

  • Agree on implementation details
  • Implement

Stories

@mjudeikis mjudeikis added the epic Represents a larger feature with multiple stories label Feb 11, 2025
@kcp-ci-bot kcp-ci-bot added this to kcp Feb 11, 2025
@github-project-automation github-project-automation bot moved this to New in kcp Feb 11, 2025
@mjudeikis mjudeikis self-assigned this Mar 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic Represents a larger feature with multiple stories
Projects
Status: New
Development

No branches or pull requests

1 participant