openSUSE Project Management Tool: Issueshttps://progress.opensuse.org/https://progress.opensuse.org/themes/openSUSE/favicon/favicon.ico?15829177842023-02-17T11:44:22ZopenSUSE Project Management Tool
Redmine openSUSE admin - tickets #124727 (Closed): Progress APIhttps://progress.opensuse.org/issues/1247272023-02-17T11:44:22Zilausuchilausuch@suse.com
<p>Hi,</p>
<p>I am engineer at SUSE at the department of QE. I am working in a project that extracts information from the progress using the API to generate metrics. It usually do several requests (for the project I am testing >400) in a sort period of time.</p>
<p>I think my IP was blocked because using different VPNs IPs I can continue calling to the API and continue my work. I checked that should be some sort of limitation of number of queries I could perform or request to the machine. I hope that in the future this project will be working in a production environment with different projects.</p>
<p>Is there anyway to solve this situation? And prevent that when we have the system in production will be blocked?</p>
<p>The project is this one:<br>
<a href="https://github.com/ilausuch/project_management_statistics" class="external">https://github.com/ilausuch/project_management_statistics</a><br>
This is also a Hackweek project.</p>
<p>I put in copy to my manager in case you need to ask him about some authorisation. He knows what is objective of this project</p>
<p>Thank you<br>
Best regards,</p>
openSUSE admin - tickets #124559 (Closed): Banned ip for progress?https://progress.opensuse.org/issues/1245592023-02-15T10:01:47Zilausuchilausuch@suse.com
<p>Hi,</p>
<p>I have problems to connect to progress if I use the IP that my ISP give to me (185.234.246.104 ). I have timeouts. The ISP doesn’t change the IP neither if I restart the router, but I can use progress with a public VPN. But it will be better to have access to progress with my IP.</p>
<p>I having using the progress API a lot because I am doing a project that requires querying. Maybe I raised some kind of limit.</p>
<p>Thank you<br>
Best regards</p>
openQA Tests - action #120924 (New): test fails in check_registercloudguest - repository list emptyhttps://progress.opensuse.org/issues/1209242022-11-24T13:05:42Zilausuchilausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-12-SP5-AZURE-Basic-Updates-x86_64-publiccloud_consoletests@64bit fails in<br>
<a href="https://openqa.suse.de/tests/10031130/modules/check_registercloudguest/steps/17" class="external">check_registercloudguest</a></p>
<p>This should be esporadic, but we have a check that fails on <a href="https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/50513d2aeb2a693e8c2742d6d7902da3dc8a539e/tests/publiccloud/check_registercloudguest.pm#L50" class="external">https://github.com/os-autoinst/os-autoinst-distri-opensuse/blob/50513d2aeb2a693e8c2742d6d7902da3dc8a539e/tests/publiccloud/check_registercloudguest.pm#L50</a></p>
<pre><code class="text syntaxhl" data-language="text">timeout 360 ssh -i '/root/.ssh/id_rsa' "azureuser@xxxx" -- 'sudo zypper lr | wc -l'
</code></pre>
<p>The problem is that there is an output, so all this line works fine</p>
<p>An other case: <a href="https://openqa.suse.de/tests/10033543/logfile?filename=serial_terminal.txt" class="external">https://openqa.suse.de/tests/10033543/logfile?filename=serial_terminal.txt</a></p>
<pre><code class="text syntaxhl" data-language="text">Warning: No repositories defined.
</code></pre>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>The base test suite is used for job templates defined in YAML documents. It has no settings of its own.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/10024236" class="external">20221123-1</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/10016909" class="external">20221122-1</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=AZURE-Basic-Updates&machine=64bit&test=publiccloud_consoletests&version=12-SP5" class="external">latest</a></p>
openQA Tests - action #102948 (New): test fails in podman_3rd_party_images - Waiting for Godot: p...https://progress.opensuse.org/issues/1029482021-11-24T10:57:46Zilausuchilausuch@suse.com
<a name="Observation"></a>
<h2 >Observation<a href="#Observation" class="wiki-anchor">¶</a></h2>
<p>openQA test in scenario sle-15-SP3-EC2-BYOS-Updates-x86_64-publiccloud_containers@64bit fails in<br>
<a href="https://openqa.suse.de/tests/7731431/modules/podman_3rd_party_images/steps/716" class="external">podman_3rd_party_images</a></p>
<a name="Test-suite-description"></a>
<h2 >Test suite description<a href="#Test-suite-description" class="wiki-anchor">¶</a></h2>
<p>The base test suite is used for job templates defined in YAML documents. It has no settings of its own.</p>
<a name="Reproducible"></a>
<h2 >Reproducible<a href="#Reproducible" class="wiki-anchor">¶</a></h2>
<p>Fails since (at least) Build <a href="https://openqa.suse.de/tests/7710839" class="external">20211121-1</a></p>
<a name="Expected-result"></a>
<h2 >Expected result<a href="#Expected-result" class="wiki-anchor">¶</a></h2>
<p>Last good: <a href="https://openqa.suse.de/tests/7707128" class="external">20211120-1</a> (or more recent)</p>
<a name="Further-details"></a>
<h2 >Further details<a href="#Further-details" class="wiki-anchor">¶</a></h2>
<p>Always latest result in this scenario: <a href="https://openqa.suse.de/tests/latest?arch=x86_64&distri=sle&flavor=EC2-BYOS-Updates&machine=64bit&test=publiccloud_containers&version=15-SP3" class="external">latest</a></p>
QA - action #95854 (Rejected): Grafana doesn't show information during some minutes, but also we ...https://progress.opensuse.org/issues/958542021-07-22T10:17:59Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>On 2021-07-22 10:14 we can grafana is not showing getting any results of the Webui summary ping<br>
<a href="https://stats.openqa-monitor.qa.suse.de/d/WebuiDb/webui-summary?tab=alert&viewPanel=76&orgId=1&from=1626941518339&to=1626942588243" class="external">https://stats.openqa-monitor.qa.suse.de/d/WebuiDb/webui-summary?tab=alert&viewPanel=76&orgId=1&from=1626941518339&to=1626942588243</a><br>
And we can check that we have increase of CPU after the recovery<br>
<a href="https://stats.openqa-monitor.qa.suse.de/d/WebuiDb/webui-summary?tab=alert&viewPanel=25&orgId=1" class="external">https://stats.openqa-monitor.qa.suse.de/d/WebuiDb/webui-summary?tab=alert&viewPanel=25&orgId=1</a><br>
<a href="https://stats.openqa-monitor.qa.suse.de/d/WebuiDb/webui-summary?tab=alert&viewPanel=25&orgId=1&from=1628060971570&to=1628663436435" class="external">https://stats.openqa-monitor.qa.suse.de/d/WebuiDb/webui-summary?tab=alert&viewPanel=25&orgId=1&from=1628060971570&to=1628663436435</a></p>
<p>During the daily we checked that there weren't a huge quantity of pending jobs to explain the amount of CPU on the recovery.</p>
openQA Project - action #95768 (New): containers: the single_container_test shows this error "Per...https://progress.opensuse.org/issues/957682021-07-21T09:02:09Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Thanks to a previous issue <a class="issue tracker-4 status-3 priority-4 priority-default closed behind-schedule" title="action: [sporadic] containers: eventually the tests fails on single_container_webui step with the error "... (Resolved)" href="https://progress.opensuse.org/issues/95179">#95179</a> we could see in the logs that the webui has permissions problems on the "factory" directory<br>
e.g. <a href="https://openqa.opensuse.org/tests/1830297#step/single_container_webui/107" class="external">https://openqa.opensuse.org/tests/1830297#step/single_container_webui/107</a></p>
<p>The reason is because the directory has the root user (in the container) but the webui is executed with the geekotest user. </p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: webui can create the needed directories in /var/lib/openqa/share/factory</li>
</ul>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<ul>
<li>Currently if the container doesn't fail the logs are not be printed, so print "docker logs openqa_webui" the logs before destroy the container</li>
<li>Check if there are other directories that require to be created from the webui and can be created</li>
</ul>
openQA Project - action #94255 (New): containers: Improve the speed of the container test in CIhttps://progress.opensuse.org/issues/942552021-06-18T10:48:35Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>The container testing has two main parts: build + run containers. <br>
The building process consume a lot of time and we saw recently several failures because of timeouts <a class="issue tracker-4 status-3 priority-5 priority-high3 closed behind-schedule" title="action: openqa-in-OpenQA fails in openqa-from-containers (Resolved)" href="https://progress.opensuse.org/issues/93713">#93713</a><br>
The building process takes a lot of time installing packages with zypper (we don't have metrics yet, but is human observation).</p>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Decrease the time to run the container tests</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<p>Because we want to focus on test openQA itself and not the packages we install in our system, I suggest to focus only on open QA testing, and don't care too much about the required packages.<br>
For that, I suggest split each container images in two parts (two different Dockerfiles). One Dockerfile will prepare the base system with the installation of all the packages. The other Docker file will run the openQA code for testing. <br>
The base image could be created during the test, but most interesting, I think is that, we can use a pre build image created by OBS (or other service) every day (or with the frequency we decided) and uploaded tom some registry</p>
openQA Project - action #94030 (Resolved): Cleanup logging in autoinst-log.txt for download assetshttps://progress.opensuse.org/issues/940302021-06-15T12:51:18Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>In the ticket <a class="issue tracker-4 status-3 priority-4 priority-default closed child" title="action: Cleanup logging in autoinst-log.txt (Resolved)" href="https://progress.opensuse.org/issues/91527">#91527</a> we listed other cases to cleanup. One of these is the information of the assets download, e.g.</p>
<pre><code>[2021-05-17T13:49:33.0579 CEST] [info] Download of Tumbleweed.x86_64-1.0-virtualbox-Snapshot20210516.vagrant.virtualbox.box processed:
[info] [#358]
Cache size of "/var/lib/openqa/cache" is 57GiB, with limit 180GiB
[info] [#358]
Downloading "Tumbleweed.x86_64-1.0-virtualbox-Snapshot20210516.vagrant.virtualbox.box" from "http://openqa1-opensuse/tests/1745884/asset/other/Tumbleweed.x86_64-1.0-virtualbox-Snapshot20210516.vagrant.virtualbox.box"
[info] [#358]
Content of "/var/lib/openqa/cache/openqa1-opensuse/Tumbleweed.x86_64-1.0-virtualbox-Snapshot20210516.vagrant.virtualbox.box" has not changed, updating last use
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong> : indent with the same indentation criteria than in <a class="issue tracker-4 status-3 priority-4 priority-default closed child" title="action: Cleanup logging in autoinst-log.txt (Resolved)" href="https://progress.opensuse.org/issues/91527">#91527</a></li>
</ul>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<ul>
<li><a href="https://github.com/os-autoinst/os-autoinst/pull/1670" class="external">https://github.com/os-autoinst/os-autoinst/pull/1670</a></li>
<li>See: <a href="https://github.com/os-autoinst/os-autoinst/blob/09824a01348c41641d5cff8cd6d4192ad5ebd7a6/bmwqemu.pm#L199" class="external">https://github.com/os-autoinst/os-autoinst/blob/09824a01348c41641d5cff8cd6d4192ad5ebd7a6/bmwqemu.pm#L199</a></li>
</ul>
openQA Project - action #93177 (New): containers: webui doesn't has the credentials to connect to...https://progress.opensuse.org/issues/931772021-05-27T11:42:47Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>The PR <a href="https://github.com/os-autoinst/openQA/pull/3915" class="external">https://github.com/os-autoinst/openQA/pull/3915</a> introduces a test of launching a job, but in the webui logs we can appreciate this error<br>
I separated this ticket from <a class="issue tracker-4 status-3 priority-4 priority-default closed behind-schedule" title="action: containers: Web UI cannot connect to scheduler (Resolved)" href="https://progress.opensuse.org/issues/92833">#92833</a> because It requires go deeper in testing and also see if there are other alternatives to the provided solution (below)</p>
<pre><code class="text syntaxhl" data-language="text">webui_2 | {"error":"Not authorized"}
</code></pre>
<a name="Acceptance-criteria"></a>
<h2 >Acceptance criteria<a href="#Acceptance-criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong> The communication from the webui with the scheduler is authorized</li>
</ul>
<a name="Ideas-and-previous-tests"></a>
<h2 >Ideas and previous tests<a href="#Ideas-and-previous-tests" class="wiki-anchor">¶</a></h2>
<p>Adding this to client.conf works.</p>
<pre><code class="text syntaxhl" data-language="text">[scheduler]\nkey = 1234567890ABCDEF\nsecret = 1234567890ABCDEF\n
</code></pre> openQA Project - action #92893 (Resolved): containers, docker-compose: Ensure that the scheduler ...https://progress.opensuse.org/issues/928932021-05-20T10:34:39Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Trying to complete the task <a class="issue tracker-4 status-12 priority-4 priority-default child" title="action: How to run an openQA test in 5 minutes size:M (Workable)" href="https://progress.opensuse.org/issues/76978">#76978</a> I found a problem in the webui container. It cannot connect to the scheduler and the jobs still unscheduled</p>
<pre><code class="text syntaxhl" data-language="text">scheduler_1 | -- Blocking request (http://127.0.0.1:9527/api/send_job)
scheduler_1 | -- Connect 41d600104970be636ece6296a21d1bdc (http://127.0.0.1:9527)
</code></pre>
<p>It could be easily fixed adding OPENQA_WEB_SOCKETS_HOST: "websockets" to the scheduler declaration</p>
<p>But then an other problems happens:</p>
<pre><code class="text syntaxhl" data-language="text">scheduler_1 | -- Client <<< Server (http://websockets:9527/api/send_job)
scheduler_1 | HTTP/1.1 403 Forbidden\x0d
scheduler_1 | Content-Length: 26\x0d
scheduler_1 | Server: Mojolicious (Perl)\x0d
scheduler_1 | Date: Thu, 20 May 2021 10:24:45 GMT\x0d
scheduler_1 | Content-Type: application/json;charset=UTF-8\x0d
scheduler_1 | \x0d
scheduler_1 | {"error":"Not authorized"}
</code></pre>
<p>This happens when we launch a web UI openQA using the docker-compose, and try to run a job (using clone_job)</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: scheduler can connect to websockets without problems</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Investigate the auth method to these services. Maybe the auth method is only localhost</li>
<li>Check that the client.ini has the correct credentials</li>
</ul>
<a name="References"></a>
<h2 >References<a href="#References" class="wiki-anchor">¶</a></h2>
<p>See the comments at <a class="issue tracker-4 status-3 priority-4 priority-default closed behind-schedule" title="action: containers: Web UI cannot connect to scheduler (Resolved)" href="https://progress.opensuse.org/issues/92833#note-6">#92833#note-6</a></p>
openQA Project - action #92092 (New): containers: openQA test eventually fails because of timeoutshttps://progress.opensuse.org/issues/920922021-05-03T15:15:00Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>This test shows that the containers test in openQA eventually fails because of timeouts<br>
<a href="https://openqa.opensuse.org/tests/1724212#step/build/5" class="external">https://openqa.opensuse.org/tests/1724212#step/build/5</a></p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: container tests doesn't fails because of timeouts at least for 10 rounds</li>
</ul>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>Seems the worker was overload, a suggestion solution is to increase the timeouts in <a href="https://github.com/os-autoinst/os-autoinst-distri-openQA/blob/master/tests/containers/build.pm" class="external">https://github.com/os-autoinst/os-autoinst-distri-openQA/blob/master/tests/containers/build.pm</a></p>
openQA Project - action #91818 (New): containers: Add logs when docker-compose up fails in the CIhttps://progress.opensuse.org/issues/918182021-04-27T09:40:06Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>We don't have information when docker-compose up -d fails in the CI test for containers.</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: CI shows logs when docker-compose up fails</li>
</ul>
openQA Project - action #91815 (New): containers: Expand the docker-compose CI test to check heal...https://progress.opensuse.org/issues/918152021-04-27T09:35:26Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>PO suggested to split <a class="issue tracker-4 status-3 priority-4 priority-default closed child" title="action: containers: The deploy using docker-compose is not stable and eventually fails (Resolved)" href="https://progress.opensuse.org/issues/89731">#89731</a> and move the AC2 to a new ticket. Currently CI is not checking that all the containers are healthy</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Expand the docker-compose CI test to include this case</li>
</ul>
<a name="Suggestion"></a>
<h2 >Suggestion<a href="#Suggestion" class="wiki-anchor">¶</a></h2>
<p>A PR is started as a proposal for <a href="https://progress.opensuse.org/issues/89731#note-28" class="external">https://progress.opensuse.org/issues/89731#note-28</a><br>
<a href="https://github.com/os-autoinst/openQA/pull/3864" class="external">https://github.com/os-autoinst/openQA/pull/3864</a></p>
openQA Project - action #91752 (Resolved): jenkins: Multiple missing fields and errors in configu...https://progress.opensuse.org/issues/917522021-04-26T11:10:31Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>Saving a new configuration is necessary to accomplish <a class="issue tracker-4 status-3 priority-5 priority-high3 closed behind-schedule" title="action: openQA-in-openQA tests always fail and results do not impact submission pipeline (Resolved)" href="https://progress.opensuse.org/issues/88754">#88754</a>. But it's impossible because multiple missing fields and errors in the UI configuration.<br>
It is not possible to save new changes.</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: The configuration can be changed and saved</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<ul>
<li>Configuration url: <a href="http://jenkins.qa.suse.de/view/openQA-in-openQA/job/monitor-openQA_in_openQA-TW/configure" class="external">http://jenkins.qa.suse.de/view/openQA-in-openQA/job/monitor-openQA_in_openQA-TW/configure</a></li>
</ul>
openQA Project - action #91584 (New): containers: ensure the failure of the web UI container when...https://progress.opensuse.org/issues/915842021-04-22T10:36:05Zilausuchilausuch@suse.com
<a name="Motivation"></a>
<h2 >Motivation<a href="#Motivation" class="wiki-anchor">¶</a></h2>
<p>We can see in this log <a href="https://openqa.opensuse.org/tests/1708952#step/single_container_webui/107" class="external">https://openqa.opensuse.org/tests/1708952#step/single_container_webui/107</a> how in spite Apache fails the container continues working.<br>
In this test the certificates were removed, and the error was expected running the single container web UI (non docker-compose)</p>
<pre><code>validate_script_output got:
AH00526: Syntax error on line 18 of /etc/apache2/vhosts.d/openqa-ssl.conf:
SSLCertificateFile: file '/etc/apache2/ssl.crt/server.crt' does not exist or is empty
</code></pre>
<p>This could be a problem in a production environment because without Apache the API doesn't work.</p>
<a name="Acceptance-Criteria"></a>
<h2 >Acceptance Criteria<a href="#Acceptance-Criteria" class="wiki-anchor">¶</a></h2>
<ul>
<li><strong>AC 1</strong>: Container exits when Apache fails</li>
<li><strong>AC 2</strong>: Container exits when any of the critical processes fails.</li>
</ul>
<a name="Suggestions"></a>
<h2 >Suggestions<a href="#Suggestions" class="wiki-anchor">¶</a></h2>
<p>In the daily meeting when this was exposed we suggested to create a simple health-check using pgrep to check that Apache is working all the time. This health-check will be included in the container and will be a complement to external health-checks.</p>