action #153478
closed
[mtui] Prepare MTUI for ALP
Added by vpelcak 4 months ago.
Updated about 1 month ago.
Description
Motivation¶
With ALP approaching we need to prepare our testing platform for its arrival to be able to continue delivering the updates. Some weeks prior release of new product we start with testing of fixes which came after a deadline and didn't make it into release and we can use that as an opportunity to test the workflow. So the specific goal here is that MTUI is able to handle update testing of ALP.
Acceptance Criteria¶
- AC1: mtui can be called successfully on ALP maintenance requests
Suggestions¶
- Coordinate with the PO of UV (hrommel1) and leading engineers, e.g. mpluskal, to understand and crosscheck the specific requirements
- If possible actually join the UV squad for some time e.g. days/weeks to properly and efficiently accomplish this task
- Find (test) maintenance requests for ALP to be able to test mtui against. If no such test maintenance requests exist yet then request such test maintenance requests
- Ensure you have a proper development environment for https://github.com/openSUSE/mtui/, i.e. at least
make test works
- Add missing support in config, e.g. in mtui/template/products/
- Consider additional adaptions needed to handle any relevant ALP changes
- Description updated (diff)
Could you please provide further details here so we can estimate the task properly? Like when this will be needed, what's required to make this work, relevant links or whom to reach out to for those questions.
I'm guessing templates need to be added at least.
livdywan wrote in #note-2:
Could you please provide further details here so we can estimate the task properly?
To be fair upfront I don't see this request fitting to the tools team at all so Liv speaking for the tools team with "we" shouldn't lead to the impression that providing more details here would mean as consequence that the tools team will work on this.
okurz wrote in #note-3:
To be fair upfront I don't see this request fitting to the tools team at all so Liv speaking for the tools team with "we" shouldn't lead to the impression that providing more details here would mean as consequence that the tools team will work on this.
I fail to understand how tools development doesn't fit into the Tools team responsibility.
vpelcak wrote in #note-4:
I fail to understand how tools development doesn't fit into the Tools team responsibility.
Well, I suggest we don't expect the tools team to be the one-stop software shop for everything but ensure we can focus on key areas to be effective and efficient.
- Description updated (diff)
okurz wrote in #note-5:
vpelcak wrote in #note-4:
I fail to understand how tools development doesn't fit into the Tools team responsibility.
Well, I suggest we don't expect the tools team to be the one-stop software shop for everything but ensure we can focus on key areas to be effective and efficient.
What do you consider to be the key areas?
Do you consider the release of maintenance updates for SLE/ALP to be one?
vpelcak wrote in #note-6:
Well, I suggest we don't expect the tools team to be the one-stop software shop for everything but ensure we can focus on key areas to be effective and efficient.
What do you consider to be the key areas?
What https://progress.opensuse.org/projects/qa/wiki/Tools#Team-responsibilities states. By the way, it mentions MTUI but https://github.com/openSUSE/mtui/commits/main/ should show what tools team members mainly contribute there which is mostly everything for which no specific domain knowledge is needed
Do you consider the release of maintenance updates for SLE/ALP to be one?
While that is one of the most responsibilities of LSG QE that is not a key area for the tools team per se just by the fact that we mostly never are involved with the actual process of releasing maintenance updates. What we do provide is a testing environment that supports triggering, running and evaluating tests for various products – without the tools team knowing actual details about the specific products.
Based on my experience the actual technical implementation of this task might be trivial, the hard part is understanding the requirements. To solve that I see two viable alternatives:
- Detail the ticket description following the templates from https://progress.opensuse.org/projects/openqav3/wiki/#Feature-requests at best filling all sections. Plus describe expectations regarding when this is needed. Plus specify affected user groups and who we can contact to support during development and try out the functionality. Then we strongly urge the tools team to pick this up and we will not ask but effectively force them to do it because you and me understand that the initial request is completely valid and ALP support in MTUI is needed.
- Followup within the UV squad. As necessary lend or rotate people with programming experience into the UV squad.
- Tags set to mtui, uv
- Project changed from 46 to QA
- Description updated (diff)
- Target version set to Tools - Next
So based on the different points we have suggested above vpelcak and me agreed in a call we just had that we will drive the topic within the tools team with the approach of close collaboration with the UV squad, e.g. temporarily joining the UV squad.
- Copied to action #154231: [timeboxed:10h][spike][mtui] Read product definitions from config files added
- Status changed from New to Blocked
- Assignee set to okurz
okurz wrote in #note-7:
vpelcak wrote in #note-6:
Do you consider the release of maintenance updates for SLE/ALP to be one?
While that is one of the most responsibilities of LSG QE that is not a key area for the tools team per se just by the fact that we mostly never are involved with the actual process of releasing maintenance updates. What we do provide is a testing environment that supports triggering, running and evaluating tests for various products – without the tools team knowing actual details about the specific products.
Based on my experience the actual technical implementation of this task might be trivial, the hard part is understanding the requirements. To solve that I see two viable alternatives:
- Detail the ticket description following the templates from https://progress.opensuse.org/projects/openqav3/wiki/#Feature-requests at best filling all sections. Plus describe expectations regarding when this is needed. Plus specify affected user groups and who we can contact to support during development and try out the functionality. Then we strongly urge the tools team to pick this up and we will not ask but effectively force them to do it because you and me understand that the initial request is completely valid and ALP support in MTUI is needed.
- Followup within the UV squad. As necessary lend or rotate people with programming experience into the UV squad.
I am OK with both options under conditions:
- SMs and POs are OK with it
- MTUI or any other tools is not quietly transferred to UV squad as their responsibility.
vpelcak wrote in #note-11:
- MTUI or any other tools is not quietly transferred to UV squad as their responsibility.
No I want to be very explicit in the transfer of responsibility to the UV squad :)
okurz wrote in #note-12:
vpelcak wrote in #note-11:
- MTUI or any other tools is not quietly transferred to UV squad as their responsibility.
No I want to be very explicit in the transfer of responsibility to the UV squad :)
Sorry, I don't see that happening and I am not going to support that.
- Target version changed from Tools - Next to future
With the disappearance of ALP, and the fact that Update Validation doesn't touch SLE Micro (for now I guess), there's no further need for this ticket from my PoV.
Now, we will need to add support for SLE 16 and that should be pretty straightforward from what I can see here https://github.com/openSUSE/mtui/blob/main/mtui/template/products/sle15.py
I suggest repurposing the ticket to reflect that. Remember, as the data in MTUI is in the codebase, we can't add information about SLE 16 until its announcement during SUSECon later this year.
poo #154231 needs to be implemented first.
- Assignee changed from okurz to szarate
One suggestion from Ondrej was:
Second possibility is dictionary ( with all combinations ) which can be stored in yaml :)
But by the looks of it, we don't need to change anything so far. See previous comment
- Status changed from Blocked to Rejected
Also available in: Atom
PDF