action #44393
open[sle][desktop][sles4sap][hpc] staging project for a second SLE product besides SLES, e.g. SLE RT in SLE15
Added by okurz almost 6 years ago. Updated over 4 years ago.
0%
Description
Motivation¶
See #43580. Having at least a second SLE product besides SLES testing in staging projects would show flaws in the unified installer.
Acceptance criteria¶
- AC1: The value of having RT in staging projects is evaluated and confirmed with stakeholders
- AC2: At least one product is tested in SLE15 staging tests besides SLES
Updated by okurz almost 6 years ago
- Copied from action #43580: The RT product can be tested by release managers or developers before full SLE validation added
Updated by okurz almost 6 years ago
https://bugzilla.suse.com/show_bug.cgi?id=1117535 is a bug I found in the RT staging test example so I guess it does make sense to have that in staging
Updated by okurz almost 6 years ago
- Due date set to 2019-02-12
- Status changed from New to Workable
Updated by riafarov almost 6 years ago
- Due date deleted (
2019-02-12)
Is it confirmed with Jeffrey? I disagree to extend some staging for the RT, only RT specific one. Removing from the sprint for now.
Updated by okurz almost 6 years ago
- Due date set to 2019-02-26
- Target version changed from Milestone 22 to Milestone 23
riafarov wrote:
Is it confirmed with Jeffrey?
It is. We mentioned it as an idea in one of the calls with him, he took the idea and in the end the task bounced back to us over multiple hops of management.
I disagree to extend some staging for the RT, only RT specific one.
Sorry, I don't understand. Can you elaborate?
Removing from the sprint for now.
ok, fine. Let's try later then :)
Updated by riafarov almost 6 years ago
- Description updated (diff)
- Estimated time set to 5.00 h
Updated by mloviska almost 6 years ago
- Status changed from Workable to Feedback
mail sent to Coolo and Jeffrey
Updated by mloviska almost 6 years ago
In which staging project to schedule (or in all), is something to be discussed with sle-release-coord@suse.de
So let's wait for Jeffrey's thoughts
Updated by riafarov over 5 years ago
- Due date changed from 2019-02-26 to 2019-03-26
Got reply from Jeffrey, but not getting answer to our question. If not RT, we can consider any other project e.g. SLED.
Updated by mloviska over 5 years ago
Updated by okurz over 5 years ago
I suggest to just add SLE RT as the "second SLE product" in staging.
Updated by mloviska over 5 years ago
Jeffrey decided to leave staging as it is for now and enable RT in staging when sle15sp2 comes.
Updated by okurz over 5 years ago
That's ok however we should add the test scenario nevertheless as decided. The main purpose is to cover "any second SLE product besides SLES", we just picked "SLE RT" as the example.
Updated by mloviska over 5 years ago
okurz wrote:
That's ok however we should add the test scenario nevertheless as decided. The main purpose is to cover "any second SLE product besides SLES", we just picked "SLE RT" as the example.
That is against AC1
Updated by okurz over 5 years ago
I think you have covered AC1 pretty well. So we understood that the RT RM does not care :) Which means we could simply pick "any product". We could select "sles4sap" just as well.
Updated by riafarov over 5 years ago
As per our discussion, as we have risk of RT not being available in SLE 15 SP2, we agreed that we should better aim other product which will remain, e.g. HPC, SAP or SLED. I've checked, both are available on staging. Will clarify with Frederic if he is fine with extending staging with such scenario.
Updated by riafarov over 5 years ago
- Due date deleted (
2019-03-26) - Status changed from Feedback to Workable
- Assignee deleted (
mloviska) - Target version changed from Milestone 23 to Milestone 26
As per discussion with Frederic, SAP would be better candidate in his opinion and we also agreed that we should perform that change for SP2 and in case of SAP being chosen one as second product, we need to confirm it with Stefan Weiberg as he is accountable for providing fixes for it.
So, I move it to the product backlog so we can work on it after SP1 is released. We also will have information if RT will be available.
Updated by riafarov over 5 years ago
- Target version changed from Milestone 26 to Milestone 27
Updated by mgriessmeier about 5 years ago
- Target version changed from Milestone 27 to Milestone 28
Updated by riafarov about 5 years ago
- Target version changed from Milestone 28 to Milestone 29
Updated by riafarov about 5 years ago
- Due date set to 2019-12-03
- Target version changed from Milestone 29 to Milestone 30+
SLE 15 SP2 online installer doesn't support installation of other products yet.
Updated by riafarov about 5 years ago
- Due date changed from 2019-12-03 to 2019-12-17
Updated by riafarov almost 5 years ago
- Due date changed from 2019-12-17 to 2020-01-28
Updated by mgriessmeier almost 5 years ago
- Target version changed from Milestone 30+ to Milestone 30
bulk moved to M30 for revisiting
Updated by riafarov almost 5 years ago
- Due date changed from 2020-01-28 to 2020-02-11
Updated by riafarov almost 5 years ago
- Due date changed from 2020-02-11 to 2020-02-25
Updated by oorlov almost 5 years ago
- Status changed from Workable to Rejected
Already implemented in Staging:S: (e.g. sles4sap_default_install@64bit).
It is enough to catch issues on early stage.
Updated by okurz almost 5 years ago
- Status changed from Rejected to Workable
But I don't think that counts because :S is only used to stage SLES4SAP changes. One goal for this story to was to test e.g. if the SLES4SAP installer breaks on SLES changes. I guess when we have the sles4sap scenario triggered in all other staging projects we could count this as done.
Updated by riafarov almost 5 years ago
- Subject changed from [sle][functional][y] staging project for a second SLE product besides SLES, e.g. SLE RT in SLE15 to [sle][functional] staging project for a second SLE product besides SLES, e.g. SLE RT in SLE15
- Due date deleted (
2020-02-25) - Assignee set to okurz
okurz wrote:
But I don't think that counts because :S is only used to stage SLES4SAP changes. One goal for this story to was to test e.g. if the SLES4SAP installer breaks on SLES changes. I guess when we have the sles4sap scenario triggered in all other staging projects we could count this as done.
For staging projects we always have argument of having more tests vs execution time. Enabling this scenario for all staging will significantly increase load on the workers causing delays in the results. As we didn't see this functionality breaking often to run it for each staging, we also can see that in the installer part we don't miss severe regressions which do not allow testing.
In case we really want to have it covered, we should rather enable separate checks for the limited scope instead of choosing second popular product and enabling it just because we can.
So for qsf-y, we don't see action items remaining here for us and other stakeholders (this was our initiative originally and didn't get much support from other stakeholders).
Assigning it to you, in case you want to act on it.
Updated by okurz over 4 years ago
- Subject changed from [sle][functional] staging project for a second SLE product besides SLES, e.g. SLE RT in SLE15 to [sle][desktop][sles4sap][hpc] staging project for a second SLE product besides SLES, e.g. SLE RT in SLE15
- Assignee deleted (
okurz) - Priority changed from Normal to Low
- Target version changed from Milestone 30 to future
Yes, sounds reasonable. So this could be interesting e.g. for [desktop] or [sles4sap] or [hpc]