You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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.
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.
Uh oh!
There was an error while loading. Please reload this page.
Demo Objective
When creating APIs for service providers, we might want to have a few levels of APIs:
An example would be a compute service provided by provider X:
where
virtualmachiens.machines.svm.io/a1apha1
is user-created and provider-maintained, the user will need to refer to instance typeinstanceTypeRef
, 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:
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.
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
Stories
The text was updated successfully, but these errors were encountered: