Project

General

Profile

coordination #92037

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 cdywan 3 months ago. Updated 3 months ago.

Status:
Workable
Priority:
Low
Assignee:
-
Category:
Feature requests
Target version:
Start date:
2021-04-30
Due date:
% Done:

0%

Estimated time:
(Total: 0.00 h)
Difficulty:

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.

Subtasks

action #92040: Support for external openQA plugins in home directoryNew

History

#1 Updated by okurz 3 months ago

  • 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.

#2 Updated by cdywan 3 months ago

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.

#3 Updated by okurz 3 months ago

  • 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