coordination #92037
open
coordination #80142: [saga][epic] Scale out: Redundant/load-balancing deployments of openQA, easy containers, containers on kubernetes
[epic] Extensible openQA: Support for external openQA plugins
Added by livdywan about 3 years ago.
Updated almost 3 years ago.
Category:
Feature requests
Estimated time:
(Total: 0.00 h)
Description
Motivation¶
Different users have different workflows and use cases. Supporting all in openQA would make openQA an unmaintainable monolith, so … plugins! :)
openQA can already be extended pretty easily but it's not clear if plugins can be published without contributing them upstream. An example of "probably should be external" could be ObsRsync which is very project-specific.
Acceptance criteria¶
- AC1: Plugins can be installed in the user's home
- AC2: Plugins can be installed system-wide
- AC3: Documentation explains how to install plugins out of tree
User stories¶
- Cary would like to publish a package that adds a new openqa-cli command.
- Lee wants to extend the openQA UI for a project-specific downstream feature.
- Tracker changed from action to coordination
- Subject changed from Support for external openQA plugins to [epic] Extensible openQA: Support for external openQA plugins
- Description updated (diff)
- Status changed from Workable to Blocked
- Assignee set to okurz
- Target version changed from future to Ready
- Parent task set to #80142
Looks nice. I think we can easily split this so turned the ticket into an epic with a subtask. But I think we should find another good example of an actual plugin to be used in the subtask.
okurz wrote:
But I think we should find another good example of an actual plugin to be used in the subtask.
I'm not sure we want to get rid of any CLI plugins. I could see myself offering a prospective plugin... I never published one because of this chicken and egg situation of not knowing quite what to do with it 🤓️ For instance I was testing out a new clone command written from scratch that doesn't directly correspond to something we have. So that's where I sort of appreciate the freedom of not having to come up with a port or going by exact requirements we already have.
- Status changed from Blocked to Workable
- Assignee deleted (
okurz)
- Target version changed from Ready to future
I am sorry, putting that in the backlog was premature, my mistake
Also available in: Atom
PDF