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
{{ message }}
This repository has been archived by the owner on Nov 8, 2022. It is now read-only.
This proposition builds up on top what was proposed, discussed and suggested in #1201 by all participants.
My use case is like this: Let's say that I have a cluster which I would like to monitor (HW metrics, VM/docker metrics, app metrics, etc.). To simplify metrics collection process I would like to just define task manifest and let registry provide me plugins that are needed to run the workflow. Then for example in Kuberenetes I could:
Embed snap task manifest as part of pod manifest.
When new pod is started I would retrieve snap task manifest (via Kuberentes API)
When I have a task, all I need to start metrics collection process are plugins. Global registry could help getting plugins without manual action and that in turn would help in automating metrics collection process.
We already have a storage for released plugins and it could be used as a backed in global registry solution. This public registry should support following queries:
get list of metrics in registry
user provides list of metrics (from task manifest) and gets plugin binaries or links to plugins binaries or just plugins names
user provides plugin name (possibly version too) and gets a plugin binary or a link to plugin binary
Usage models:
It seems that task manifest contains currently all the data to uniquely identify plugins needed for metrics collection. To leverage that two models could be supported:
Invoking snapd like this: snapd --registy default
and then you could just load tasks and snapd in the back should get the plugins from the registry and start tasks.
Invoke snapd as today and then using Registry API to get plugin names or binaries
Combined with with possibility of loading plugin by supplying URL to plugin ( #1201 ) this solution may further increase automation possibility.
For now I would be most interested in the second model. Of course in the next steps user could create private registries if needed - reusing API from global registry.
Any other ideas on how to simplify and automate metrics collection process are welcome.
The text was updated successfully, but these errors were encountered:
It would really simplify user experience if we can go to the point where creating a task from a task manifest automate plugin downloads, a la "docker hub"/"vagrant up"/"kubectl".
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
This proposition builds up on top what was proposed, discussed and suggested in #1201 by all participants.
My use case is like this: Let's say that I have a cluster which I would like to monitor (HW metrics, VM/docker metrics, app metrics, etc.). To simplify metrics collection process I would like to just define task manifest and let registry provide me plugins that are needed to run the workflow. Then for example in Kuberenetes I could:
We already have a storage for released plugins and it could be used as a backed in global registry solution. This public registry should support following queries:
Usage models:
It seems that task manifest contains currently all the data to uniquely identify plugins needed for metrics collection. To leverage that two models could be supported:
snapd --registy default
and then you could just load tasks and snapd in the back should get the plugins from the registry and start tasks.
Combined with with possibility of loading plugin by supplying URL to plugin ( #1201 ) this solution may further increase automation possibility.
For now I would be most interested in the second model. Of course in the next steps user could create private registries if needed - reusing API from global registry.
Any other ideas on how to simplify and automate metrics collection process are welcome.
The text was updated successfully, but these errors were encountered: