Generate manifest files for applications #353
Assignees
Labels
Comments
This was referenced Sep 3, 2024
Merged
IfSentient
added a commit
that referenced
this issue
Sep 12, 2024
# What This PR Does / Why We Need It This PR introduces the first step of the **App Manifest**, a concept to help clarify and drive app development. The App Manifest is the listing of the app's managed kinds and capabilities (admission, conversion) for those kinds. This PR introduces admission and conversion capabilities for kinds in the manifest, be leaves schemas unimplemented. Added in this PR is the `app` package, which is where the App Manifest (as `app.Manifest`) lives, and where additional app-centric logic will reside for future features such as #385 `app.Manifest` is decoupled from the actual manifest data by having an `app.ManifestData` type which contains manifest data, and having the `app.Manifest` contain a pointer to said data (which can be nil), and a location for the data. This way, an `app.Manifest` can simply point to a file on-disk, or an API server location, without having to have the data loaded, and the consumer of the `app.Manifest` should understand how to fetch the `app.ManifestData`. This allows an app to not need to know the credentials to fetch the manifest data (such as kube config), but still be able to tell other components which may have such knowledge where to fetch the data (this is important in #385, as the App Provider will need to provide the manifest and a way of creating the App, but will not know how to talk to the API server, as the runner will be able to load those credentials). Included in this PR is the generation of this in-progress initial manifest as both an API server CR, and as in-code `app.ManifestData` to use if and when the manifest type is not available in the API server. An app author can now specify their app's capabilities for admission and conversion for kinds via `admission`, `mutations`, and `conversion` in the `apiResource` field in CUE, and can optionally override those kind-wide defaults on a per-version basis with `admission` and `mutation` fields in the version (`conversion` is always only kind-wide, as all versions must be inter-convertable for `conversion` to be allowed). The test data has been updated with these additional fields for manifest generation testing. Two new files will now be generated on each `grafana-app-sdk generate` call: `definitions/<app-name>-manifest.(json|yaml)`, and `pkg/generated/manifest.go`. Relates to #353, which will be completed once the manifest contains the CRDs (schemas) as well. --------- Co-authored-by: Igor Suleymanov <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What
We should create a new concept of a "manifest file", which would act as a root container for application schemas and contain all necessary application metadata.
Those files would then be processed by the platform for registering and initialising applications correctly, similar to how Grafana plugins are currently handled (see https://grafana.com/developers/plugin-tools/reference/plugin-json for details).
Those files can then be used by the codegen for producing CRDs, webhook configs and so on.
Why
To improve the UX for developers and enable automatic registration of the apps on the backend. Currently this requires a lot of manual steps and the process is overall very brittle.
The text was updated successfully, but these errors were encountered: