Project

General

Profile

Actions

action #34576

open

[sssd][ldap][migration][network] Implement functional testing for network service which would utilize migration scenario

Added by sebchlad over 6 years ago. Updated 8 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
New test
Target version:
-
Start date:
2018-04-09
Due date:
% Done:

0%

Estimated time:
Difficulty:

Description

The basic idea is to test migration more widely by re-using migration openQA modules in different areas so - for instance - some network services could be installed and configured on earlier version of SLES, then migration openQA module could be "called", the migration to a given SLES version could be done, and eventually we could see if pre-configured service is still working.

Suggested by SLE Architect - Thorsten K. - for his preferences.

  • setup openldap server with YaST module
  • setup ldap client (sssd)
  • setup autorization against Windows domain server

The target for this is SLE12 SP4.


Related issues 1 (1 open0 closed)

Related to openQA Tests - action #70168: [SLE][Migration][backlog]: sssd.pm integrate into service checkBlockedcoolgw2020-08-18

Actions
Actions #1

Updated by sebchlad over 6 years ago

Next step: I'll talk to Okurz to get his view and see what qa sle func team is already doing in this regards.

Actions #2

Updated by sebchlad over 6 years ago

  • Target version set to future
Actions #3

Updated by sebchlad over 6 years ago

  • Description updated (diff)
Actions #4

Updated by okurz over 6 years ago

  • Target version changed from future to future
Actions #5

Updated by pcervinka about 4 years ago

  • Tags set to migration, network
  • Project changed from 46 to 178
  • Subject changed from [kernel][networking][migration] Implement functional testing for network service which would utilize migration scenario to Implement functional testing for network service which would utilize migration scenario
  • Target version changed from future to 643
Actions #6

Updated by pcervinka almost 4 years ago

@sebchlad I don't think it is in our scope. What do you think? Reject? There are other teams form migration, also Windows domain server for auth is within other teams.

Actions #7

Updated by sebchlad almost 4 years ago

It seems that there was no project management done over this, in the meantime migration team is doing a bit different things, so I would not bother re-discussing it.
It should be QE technical project mgmt driving it.

I would reject it then.

Actions #8

Updated by okurz almost 4 years ago

As long as it's not done yet, it's not done yet. Why would you reject it? If you think the migration team can help I suggest to clarify with them. Just hoping that they cover it is not good quality assurance, right? ;)

Actions #9

Updated by pcervinka almost 4 years ago

  • Project changed from 178 to openQA Project
  • Subject changed from Implement functional testing for network service which would utilize migration scenario to [sssd][ldap][migration][network] Implement functional testing for network service which would utilize migration scenario
  • Target version deleted (643)

Releasing from kernel qe as the content is out of scope, so any team interested in can pick it up.

Actions #10

Updated by pcervinka almost 4 years ago

  • Target version set to future
Actions #11

Updated by okurz almost 4 years ago

  • Project changed from openQA Project to openQA Tests
  • Category set to New test
  • Target version deleted (future)
Actions #12

Updated by szarate almost 4 years ago

  • Status changed from New to Rejected

with this ping pong, I foresee that this ticket will rot.

Oliver if you still think it's a valid ticket, please assign it to yourself when reopening it.

Actions #13

Updated by okurz almost 4 years ago

  • Status changed from Rejected to New
  • Parent task set to #73417

why should I assign to myself? The ticket has valid team markers, e.g. "[migration]". Can we keep it for the migration team? Especially as the topic of SSSD and LDAP is raised by customers, support, Product Managers, etc. . Added the corresponding ticket as "parent".

Actions #14

Updated by coolgw over 3 years ago

Very old ticket and i have following questions on this ticket. Please see my comments/suggestion:

*setup openldap server with YaST module <==== from 15sp3 the openldap server start obsolete, so from migration view this can be SKIP?
*setup ldap client (sssd) <==== for sssd service check(before / after ) migration we have another ticket https://progress.opensuse.org/issues/70168 tracking within migration group. And this task pending on https://progress.opensuse.org/issues/89479.
*setup autorization against Windows domain server <=====If we need authorization against windows domain server, then we also need consider this kind of scenario within ticket https://progress.opensuse.org/issues/89479. Or we create another ticket for sssd + windows server scenario for QE CORE team. BTW: we have to use multi machine setup for this scenario(one is for sssd client and another is windows domain server)

Actions #15

Updated by szarate over 3 years ago

coolgw wrote:

Very old ticket and i have following questions on this ticket. Please see my comments/suggestion:

*setup openldap server with YaST module <==== from 15sp3 the openldap server start obsolete, so from migration view this can be SKIP?

Yes, I don't think this is needed, if it's already tested somewhere else, after all, once the initial config is done, why would the user come back to yast?.

*setup ldap client (sssd) <==== for sssd service check(before / after ) migration we have another ticket https://progress.opensuse.org/issues/70168 tracking within migration group. And this task pending on https://progress.opensuse.org/issues/89479.

I think that #89479 doesn't block you anymore, so you could proceed with the service check part.

*setup autorization against Windows domain server <=====If we need authorization against windows domain server, then we also need consider this kind of scenario within ticket https://progress.opensuse.org/issues/89479. Or we create another ticket for sssd + windows server scenario for QE CORE team. BTW: we have to use multi machine setup for this scenario(one is for sssd client and another is windows domain server)

This is being worked on: https://progress.opensuse.org/issues/72169#note-55 and https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12517 so at a later point when the test is done and stable we can consider adapting the scenario to adapt it for migration. We don't use Multi Machine for this atm, but rather we're using a separate standalone windows machine.

PS: I would reject this ticket, as the points raised by Wayne are already covered. Wayne what do you think?

Actions #16

Updated by szarate over 3 years ago

Added Wayne (I hope coolgw is Wayne :)) to watchers :), so that he can read the comment above

Actions #17

Updated by coolgw over 3 years ago

szarate wrote:

coolgw wrote:

Very old ticket and i have following questions on this ticket. Please see my comments/suggestion:

*setup openldap server with YaST module <==== from 15sp3 the openldap server start obsolete, so from migration view this can be SKIP?

Yes, I don't think this is needed, if it's already tested somewhere else, after all, once the initial config is done, why would the user come back to yast?.

*setup ldap client (sssd) <==== for sssd service check(before / after ) migration we have another ticket https://progress.opensuse.org/issues/70168 tracking within migration group. And this task pending on https://progress.opensuse.org/issues/89479.

I think that #89479 doesn't block you anymore, so you could proceed with the service check part.

[GW]: we blocked on https://progress.opensuse.org/issues/93210 since #89479 not using service check style. Correct me if any misunderstanding.

*setup autorization against Windows domain server <=====If we need authorization against windows domain server, then we also need consider this kind of scenario within ticket https://progress.opensuse.org/issues/89479. Or we create another ticket for sssd + windows server scenario for QE CORE team. BTW: we have to use multi machine setup for this scenario(one is for sssd client and another is windows domain server)

This is being worked on: https://progress.opensuse.org/issues/72169#note-55 and https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/12517 so at a later point when the test is done and stable we can consider adapting the scenario to adapt it for migration. We don't use Multi Machine for this atm, but rather we're using a separate standalone windows machine.

PS: I would reject this ticket, as the points raised by Wayne are already covered. Wayne what do you think?

Actions #18

Updated by szarate over 3 years ago

coolgw wrote:

[GW]: we blocked on https://progress.opensuse.org/issues/93210 since #89479 not using service check style. Correct me if any misunderstanding.

You can pick that ticket also, so that you don't have to wait for a longer period of time.

Actions #19

Updated by szarate almost 3 years ago

  • Parent task deleted (#73417)
Actions #21

Updated by maritawerner almost 3 years ago

@coolgw could you please close that ticket? I think everything is done?

Actions #22

Updated by coolgw almost 3 years ago

@szarate
setup autorization against Windows domain server
[GW]:Is there any test case already running on ODS for above scenario?

Actions #23

Updated by szarate almost 3 years ago

coolgw wrote:

@szarate
setup autorization against Windows domain server
[GW]:Is there any test case already running on ODS for above scenario?

You can check https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/d8e55380ed7aa90d3d9e3d6284349dd1a961e78e/tests/network/samba/samba_adcli.pm#L74

Actions #24

Updated by coolgw almost 3 years ago

  • Related to action #70168: [SLE][Migration][backlog]: sssd.pm integrate into service check added
Actions #25

Updated by slo-gin almost 2 years ago

This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions #26

Updated by slo-gin 8 months ago

This ticket was set to Normal priority but was not updated within the SLO period. Please consider picking up this ticket or just set the ticket to the next lower priority.

Actions

Also available in: Atom PDF