QA (public) » openQA Project (public)

note: we can discuss this ticket in grooming session.

BTW recommendation from mnowak for testing vmware and hyper-v after touching svirt (specially for rewrite) rewrite:
textmode for vmware and hyper-v from Virtualization-Acceptance (https://openqa.suse.de/group_overview/263)
he also recommended to run media_upgrade_sles15_allpatterns_hyperv and proxyscc_upgrade_sles12sp4_hyperv for hyper-v and some for vmware from
Virtualization-Milestone (https://openqa.suse.de/group_overview/264), but they aren't there for 15SP2.

If this is implemented, it might be worth also add svirt serial support for vmware and hyper-v
(similar to #55985).

I want to make one thing clear. Although svirt backend is mainly used by virtualization testing,and michal nowak, as a QA engineer, contributed a lot to this svirt backend to facilitate VT testing. But, this svirt backend maintenance resonsibility, IMHO, should officially belongs to tools group. However, if the tickets(related to svirt backend) are quite relevant to virtualization testing, especially those leading to VT test failures, the new FTE replacing michal, will own the task. But for other general svirt tickets, I have to say that the new FTE focus is vmware&hyperv testing and has a lot to do on test side, and may not have enough effort to handle them. Sorry about it. @okurz FYI.

Thanks for the clarification. I think it is important that we make it explicit what can be expected from individual teams and you did make it explicit. This is good. Please be aware of the responsibility scope as we have it stated for SUSE QE Tools on https://progress.opensuse.org/projects/qa/wiki/Wiki#Team-responsibilities and also the section https://progress.opensuse.org/projects/qa/wiki/Wiki#Out-of-scope . As mentioned there no one should expect the related work to be done by SUSE QE Tools either. This is based on our expertise and focus. It might still be that we will help to improve it but don't hold your breath :)

okurz wrote:

Thanks for the clarification. I think it is important that we make it explicit what can be expected from individual teams and you did make it explicit. This is good. Please be aware of the responsibility scope as we have it stated for SUSE QE Tools on https://progress.opensuse.org/projects/qa/wiki/Wiki#Team-responsibilities and also the section https://progress.opensuse.org/projects/qa/wiki/Wiki#Out-of-scope . As mentioned there no one should expect the related work to be done by SUSE QE Tools either. This is based on our expertise and focus. It might still be that we will help to improve it but don't hold your breath :)

@okurz, Thanks for the links. To be honest, I am a little surprised about some "Out-of-scope" items. I am curious about who defines it, who(which teams) tools team agrees it with and how it is agreed.

Besides, I am not sure whether I understand it correct, please help check.

• In team responsibilities, there is an item about "Develop and maintain upstream openQA". In my interpretion, this includes all upstream openqa related code(os-autoinst, openqa webui, etc). And it means that tools team will DEVELOP and maintain os-autoinst code, including all backend code, qemu/ipmi/svirt/etc.
• However in "Out-of-scope", it states that "Feature development within the backend for single teams (commonly provided by teams themselves)". My interpretion of the statement is that for those backend that are not widely used, tools team will not develop features on them any more. Is this the intended meaning of it? Would you please help clarify, from your POV as tools team PO, whether ipmi and svirt backends belong to this classification? I need to build correct expectations.

Please let me honestly share my opinion on it. I understand that for backends with less users, it is common that they are treated with lower priority, however it is totally different from "out of scope". For low priority case, there is chance to be delivered some highly required new features someday on those backends, while in out of scope case, those new features can not be expected from tools at all. As you said, expertise is important. It is reasonable that some easy features can be done by backend users(we are doing so to some extent), but for those complex/difficult features, it is not realistic to let users implement them. And with them out of scope of tools team, then the users on those backends can never get the new features, although the features may be very important to their work.

@maritawerner, @cachen FYI.

xlai wrote:

@okurz, Thanks for the links. To be honest, I am a little surprised about some "Out-of-scope" items. I am curious about who defines it

the team defined that based on their understanding at that time of what their responsibilities and capabilities are. This was roughly 1-2 years ago, before I was product owner (I did not define it myself for sure).

who(which teams) tools team agrees it with and how it is agreed.

AFAIK PrjMgr, former directors of QA SLE and QAM as well as director of the SLE development group as we also had team members from outside QA SLE and QAM. Speaking for myself I know that this was clarified with me as PO of the former QA SLE Functional team(s) and I expected that this was also clarified with all other teams but I think this was even before you took over PO for the QA SLE virtualization team.

Besides, I am not sure whether I understand it correct, please help check.

• In team responsibilities, there is an item about "Develop and maintain upstream openQA". In my interpretion, this includes all upstream openqa related code(os-autoinst, openqa webui, etc). And it means that tools team will DEVELOP and maintain os-autoinst code, including all backend code, qemu/ipmi/svirt/etc.

Well, I think the original meaning was really about openQA only. I think formerly the tools team (as a reminder, I only joined 2019-05) was only changing os-autoinst where it was needed for communication with openQA. This excludes the specific test API functions as well as all backends. By now we have extended the scope to take responsibility for os-autoinst in general with the exception stated below

• However in "Out-of-scope", it states that "Feature development within the backend for single teams (commonly provided by teams themselves)". My interpretion of the statement is that for those backend that are not widely used, tools team will not develop features on them any more. Is this the intended meaning of it? Would you please help clarify, from your POV as tools team PO, whether ipmi and svirt backends belong to this classification? I need to build correct expectations.

There is no change. Multiple members of former SUSE QA Tools have never touched os-autoinst at all before 2019-05. Commonly the backends, including ipmi and svirt, have been maintained, updated and changed by other teams, e.g. QA SLE Functional, when for example mgriessmeier and me improved and extended the s390x backends (svirt and s390x), or QA Kernel when rpalethorpe worked on the qemu backend or QA Kernel and Network when cfconrad was working on the ssh based serial terminal. The statement "Feature development within the backend for single teams (commonly provided by teams themselves)" merely describes what was and is reality. And the current team in general would not have the capacity nor the experience nor the assignment from stakeholders nor the motivation to work on specific features within specific backends with exception of the most used, generic qemu backend. Of course we are happy to help and try to apply our expertise where we can, e.g. if regressions happen or unexpected behaviour is causing confusion. But what should not be expected is that a sudden feature request for a new feature within a specific backend will be greeted with enthusiasm :)

Please let me honestly share my opinion on it. I understand that for backends with less users, it is common that they are treated with lower priority, however it is totally different from "out of scope". For low priority case, there is chance to be delivered some highly required new features someday on those backends, while in out of scope case, those new features can not be expected from tools at all. As you said, expertise is important. It is reasonable that some easy features can be done by backend users(we are doing so to some extent), but for those complex/difficult features, it is not realistic to let users implement them. And with them out of scope of tools team, then the users on those backends can never get the new features, although the features may be very important to their work.

We can always discuss about the individual requests and we can be flexible on what we see "out of scope". Don't see it too strict. The invitation is always open to talk to us :) But to better understand why we make certain decisions and how we plan and why might see priorities for certain requests in certain ways I have added a new section https://progress.opensuse.org/projects/qa/wiki/Wiki#Our-common-userbase which I recommend to read as this should explain what our user base. It might be bigger than one might expect :) Also there is https://progress.opensuse.org/projects/qa/wiki/Wiki#How-we-work-on-our-backlog explaining our priorization. The team roster can also be considered https://progress.opensuse.org/projects/qa/wiki/Wiki#Team to understand the capacity.

@okurz, Thanks for the long explanation. I understand much better what tools team defines your responsibility now. I will adapt my expectations accordingly. However, I am glad that there is still chance to discuss about the individual requests and the team can be flexible somehow on what you see "out of scope". So the important requests on ipmi/svirt backends are possible to be helped, of course after case by case evaluation by your team. Thanks!