Project

General

Profile

Actions

action #11518

open

openQA Project - action #13868: isotovideo should support test postrun hook

[sle] Mark used SLE SCC Codes

Added by RBrownSUSE almost 8 years ago. Updated over 2 years ago.

Status:
New
Priority:
Low
Assignee:
-
Category:
Enhancement to existing tests
Target version:
Start date:
2016-04-06
Due date:
% Done:

30%

Estimated time:
Difficulty:

Description

From Artem,

Hi, everyone.

May we kindly ask to evaluate the possibility to de-register a system
when the test run on openQA for specific build is done.

That will allow us to keep organization with Alpha keys tidy.


Any ideas on how we can implement this? Having the worker do it seems hard work (it might not know enough about the system to do it) but having the VM do it might not be viable... can we do a post fail hook on all tests?

Actions #1

Updated by okurz almost 8 years ago

  • Project changed from openQA Project to openQA Tests
Actions #2

Updated by mkravec almost 8 years ago

  • Assignee set to mkravec
Actions #3

Updated by mkravec over 7 years ago

We can not:

  • post-fail hook: We unregister only if some test fail (and after every failed test). Non fatal tests would unregister, but job would continue running
  • hook that would unregister after last test finishes (or fatal test fails): this would be ignored when restarting & canceling job from webui (when newer build is scheduled)
  • hook that would trigger when we destroy VM (root console is available anymore)

As suggested, maybe worker can do it (hard work solution):

  • save credentials during registration and unregister from worker when job is finished (calling http 'DELETE /connect/systems ... scc.suse.com')

Better suggestions?

Actions #4

Updated by mkravec over 7 years ago

  • Parent task set to #13868
Actions #5

Updated by mkravec over 7 years ago

System can be deregistered by calling scc url:
https://github.com/SUSE/connect/wiki/SCC-API-(Implemented)#deregister-system

Username & password are generated during registration and stored in:
/etc/zypp/credentials.d/

Actions #6

Updated by RBrownSUSE over 7 years ago

mkravec wrote:

Username & password are generated during registration and stored in:
/etc/zypp/credentials.d/

Deleting that dirs contents is only necessary if we intend to reuse the image (like with upgrades, so we'll need to do it, but maybe not always)

Actions #7

Updated by mkravec over 7 years ago

PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/1923

Deleting dir contents is part of poo#10996 - required when publishing hdd

Actions #8

Updated by dgutu over 7 years ago

mkravec wrote:

PR: https://github.com/os-autoinst/os-autoinst-distri-opensuse/pull/1923

Deleting dir contents is part of poo#10996 - required when publishing hdd

This solution, to delete data should be applied only for sles12sp0 because the version of SUSEConnect is not able to unregister the system. "SUSEConnect -d" works for sles12sp1.

Actions #9

Updated by mkravec over 7 years ago

  • Status changed from New to In Progress
  • % Done changed from 0 to 100
Actions #10

Updated by okurz over 7 years ago

  • Category set to Enhancement to existing tests
Actions #11

Updated by maritawerner over 7 years ago

Any update here?

Actions #12

Updated by mkravec over 7 years ago

First solution was dismissed as we found out that unregistering all tests after execution might break maintenance (where they expect registered image).
I am working on proposed solution where we upload information required for unregistration into assets and unregister from background job after few days.
Current problem is that assets are not uploaded on obsoleted/canceled tests, which requires backend changes.

Issue was on hold for a moment as I was working on other things, I will continue this week.

Actions #13

Updated by mkravec over 7 years ago

  • Assignee deleted (mkravec)
  • % Done changed from 100 to 30

I implemented part that uploads SCC credentials as job asset or variable. What needs to be done is part that uses that information and deregister system when all related jobs are finished.

Proposed solution from backend developers was to implement a openQA plugin for this task.
I have little backend knowledge, so will free this issue for the moment (so anybody interested can look at it).
If nobody takes it I will continue after I finish tasks that I can solve faster.

Actions #14

Updated by RBrownSUSE about 7 years ago

  • Project changed from openQA Tests to openQA Project
  • Subject changed from SLE SCC Deregister on Test End to [tools]SLE SCC Deregister on Test End
  • Category deleted (Enhancement to existing tests)

Now a backend task, tagging appropriately

Actions #15

Updated by okurz@suse.de about 7 years ago

Does not make sense to me. SCC can not be related to Backend. "Everything AdamWill from Fedora can solve should be in openQA project, everything else in tests repo" or suseqa

Actions #16

Updated by RBrownSUSE about 7 years ago

it's going to require modifications to os-autoinst and probably few or not os-autoinst-distri-opensuse

After all, the tests will not know when they're finished with the image, only os-autoinst or openQA can know that.

Therefore, it's a backend task

Sure, it's not a backend task that is relevant to Adam, which is why it has a nice new shiney [tools] tag on it to show that it's relevant to the SLE QA Tools team

But I think it should still be in the appropriate tracker - after all, Red Hat have their own registration system, their openQA might not be plugged into it, but maybe our solution for SCC is useful as a reference for that. Or maybe we need a common 'registration library' to abstract that away in the backend regardless of which registration system is in use.

Still, don't see how it's a openQA test ticket.

Actions #17

Updated by RBrownSUSE about 7 years ago

it's going to require modifications to os-autoinst and probably few or not os-autoinst-distri-opensuse

After all, the tests will not know when they're finished with the image, only os-autoinst or openQA can know that.

Therefore, it's a backend task

Sure, it's not a backend task that is relevant to Adam, which is why it has a nice new shiney [tools] tag on it to show that it's relevant to the SLE QA Tools team

But I think it should still be in the appropriate tracker - after all, Red Hat have their own registration system, their openQA might not be plugged into it, but maybe our solution for SCC is useful as a reference for that. Or maybe we need a common 'registration library' to abstract that away in the backend regardless of which registration system is in use.

Still, don't see how it's a openQA test ticket.

Actions #18

Updated by okurz about 7 years ago

  • Category set to Feature requests
Actions #19

Updated by coolo almost 7 years ago

Assets just don't cut it - as mkravec found out.

And I don't think we should extend the backend for this - it's just a too special problem IMO.

How about a minimal web app our tests post the used codes to - implementing this app is a finger exercise for a trainee/intern. And doing a POST to a given URL from the test is easy to add too (in dubio use curl within the SUT, but we already use LWP::Simple in lib/x11regressiontest.pm

That app then stores the keys and will periodically talk to SCC to deregister.

Actions #20

Updated by coolo over 6 years ago

  • Project changed from openQA Project to openQA Tests
  • Subject changed from [tools]SLE SCC Deregister on Test End to Mark used SLE SCC Codes
  • Category deleted (Feature requests)
  • Status changed from In Progress to New

As stated before, I disagree with Richard and this should be handled outside of openQA from within the tests.

Actions #21

Updated by okurz over 6 years ago

  • Category set to Enhancement to existing tests
  • Priority changed from High to Normal
  • Target version set to future
Actions #22

Updated by okurz almost 6 years ago

  • Subject changed from Mark used SLE SCC Codes to [sle] Mark used SLE SCC Codes

Well, I would regard it as a task for [tools] as it is not really tailored for any of the other groups but coolo just removed the tag so …

Actions #23

Updated by okurz almost 6 years ago

Is this request still useful when it only concerns openQA tests? For example I do not care to deregister my system in manual tests.

Actions #24

Updated by okurz almost 6 years ago

  • Target version changed from future to future
Actions #25

Updated by skotov almost 6 years ago

In the SCC Alpha organization we currently see a huge amount of
registered systems:
https://scc.suse.com/subscriptions?current_organization=309910

This makes one of our API endpoints very slow.

To resolve the current situation soonish we plan to deregister systems which has no activity since 2 weeks (timeframe not yet agreed / negotiable) from time to time.

However it would be really nice if openQA tests would deregister systems after (at least) successful tests. Other things (systems that left after unsuccessful tests) could be cleaned up on our side.

In general the database records like system registrations done by openQA or manual QA sessions should be cleaned up right after the test.

Actions #26

Updated by szarate almost 6 years ago

I think we don't rely too much on having systems already registered in SCC, @okurz if you don't have any arguments I would agree for SCC to delete keys with no activity in the timeframe that he's proposing, while the idea proposed by coolo about a small web app could also be a potential gain but would need other efforts to be taken :).

Actions #27

Updated by okurz almost 6 years ago

I had discussed this with @skotov already over chat:

In general, I guess with low risk we can try as long as we inform all reviewers of openQA test reviewers, e.g. with a message to openqa@suse.de and probably maintenance@suse.de . If there are any problems we will see in tests and handle this accordingly. Right now I can't think of any like qcow images from virtual machines that are registered and we rely on the registration for longer than one test run which is less than a day in each case I guess. However, in case of manual tests I can think of we register a system and leave it around for e.g. 2 months and then it would be a minor annoyance if the registration is lost again. Can we apply the deletion to special codes for openQA only and not all codes from the alpha org? I suggest the following: Cleanup existing alpha organisations, create new codes which are easy to remember like the existing ones in the openQA orga for manual testing which are valid way longer, e.g. 1 year, and cleanup the ones in openQA orga after two weeks because they should be only used for automated tests. If anyone uses these openQA codes for manual tests then it's their own fault if it's invalidated after two weeks :) I would solve it by convention, not by an additional feature in SCC

Actions #28

Updated by digitaltomm over 5 years ago

okurz wrote:

I had discussed this with @skotov already over chat:

In general, I guess with low risk we can try as long as we inform all reviewers of openQA test reviewers, e.g. with a message to openqa@suse.de and probably maintenance@suse.de .

@okurz: could you switch the openqa tests to the openqa organization that I created for you? (SCC_ORG_ECABHE)
Then it would be clearly seperated which subscriptions are used for openqa automated tests, and the cleanup can run just there not to kill systems that might still be used manually.

Actions #29

Updated by okurz over 5 years ago

digitaltomm wrote:

@okurz: could you switch the openqa tests to the openqa organization that I created for you? (SCC_ORG_ECABHE)

Yes, I would like us to do that but currently the organisation is quite limited in its applicability as we only cover a small subset of products in this orga. Could you add subscriptions for all relevant products as provided already in SCC_ORG_DAJJBA. And for the sake of consistency it would be great to have pronouncable regcodes for all products (but not a necessity).

Actions #30

Updated by skotov over 5 years ago

@okurz: please see the example cleanup script here
https://github.com/SUSE/connect/pull/380/files

Actions #31

Updated by okurz over 2 years ago

  • Priority changed from Normal to Low

This ticket was set to "Normal" priority but was not updated within 730 days which is 2 times the period of the SLO for "Normal" tickets (365 days) as described on https://progress.opensuse.org/projects/openqatests/wiki/Wiki#SLOs-service-level-objectives . The ticket will be set to the next lower priority of "Low".

Actions

Also available in: Atom PDF