QA » openQA Project » openQA Tests

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?

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/

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)

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

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

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.

Any update here?

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.

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

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.

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.

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.

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

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.

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 :).

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

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.

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).

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