Project

General

Profile

action #34576

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

Added by sebchlad over 3 years ago. Updated 6 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.

History

#1 Updated by sebchlad over 3 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.

#2 Updated by sebchlad over 3 years ago

  • Target version set to future

#3 Updated by sebchlad over 3 years ago

  • Description updated (diff)

#4 Updated by okurz over 3 years ago

  • Target version changed from future to future

#5 Updated by pcervinka about 1 year ago

  • Tags set to migration, network
  • Project changed from SUSE QA to QE Kernel
  • 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 QE Kernel Todo

#6 Updated by pcervinka about 1 year 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.

#7 Updated by sebchlad about 1 year 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.

#8 Updated by okurz 12 months 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? ;)

#9 Updated by pcervinka 12 months ago

  • Project changed from QE Kernel 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 (QE Kernel Todo)

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

#10 Updated by pcervinka 12 months ago

  • Target version set to future

#11 Updated by okurz 12 months ago

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

#12 Updated by szarate 12 months 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.

#13 Updated by okurz 12 months 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".

#14 Updated by coolgw 6 months 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)

#15 Updated by szarate 6 months 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?

#16 Updated by szarate 6 months ago

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

#17 Updated by coolgw 6 months 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?

#18 Updated by szarate 6 months 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.

Also available in: Atom PDF