Hi all, I met with the openSUSE Board this morning and we had a discussion about https://metrics.opensuse.org/ As one of the openSUSE-release-tools, it tracks the releases, but currently is not tracking Leap 15.2. The tool was written by a member of the release team, but it appears that there is no documentation on how to change or update it for the releases. It appears that one person tryed to fix this in the following PR: https://github.com/openSUSE/openSUSE-release-tools/pull/2464 <https://github.com/openSUSE/openSUSE-release-tools/pull/2464> I merged it a while back after it passed the checks, but was informed that it was Work in Progress, but was not listed at WIP. The committer asked me to revert it, which I did. Unfortunately, there has not been any movement on this since. I wrote on the PR last month on github to see if there was an update, but there has been no response. It looks like the script would need to parse certain info for Grafana. If someone does fix it, it would be great to have it documented, so it can be updated easily for each release cycle. Is there anyway to turn off metrics.o.o while it is being fixed. v/r Doug
On 11/10/20 8:57 AM, ddemaio wrote:
Hi all, I met with the openSUSE Board this morning and we had a discussion about https://metrics.opensuse.org/
As one of the openSUSE-release-tools, it tracks the releases, but currently is not tracking Leap 15.2.
Hi there, updating the tool to track Leap 15.2 is simple. It's just updating the regex for product pattern to match. I can take care of it. It's actually one of few documented items [1]. [1] https://github.com/openSUSE/openSUSE-release-tools/tree/master/metrics/acces...
The tool was written by a member of the release team, but it appears that there is no documentation on how to change or update it for the releases. It appears that one person tryed to fix this in the following PR: https://github.com/openSUSE/openSUSE-release-tools/pull/2464 <https://github.com/openSUSE/openSUSE-release-tools/pull/2464>
My work was focused on extending the collected information and storing statistics about package downloads. Meaning, how often a given package gets downloaded on a day, week, month. The problem is that the script in current shape caches a lot of data on the disk which fills up already. I've written a short summary of that here [2]. I've done some work already to redesign the script and move the aggregation part from cache files into InfluxDB. [2] https://progress.opensuse.org/issues/69535#note-1 Cheers Witek
On Tue 2020-11-10, Witek Bedyk wrote:
updating the tool to track Leap 15.2 is simple. It's just updating the regex for product pattern to match. I can take care of it. It's actually one of few documented items [1].
Cool, thank you!
My work was focused on extending the collected information and storing statistics about package downloads. Meaning, how often a given package gets downloaded on a day, week, month. The problem is that the script in current shape caches a lot of data on the disk which fills up already. I've written a short summary of that here [2]. I've done some work already to redesign the script and move the aggregation part from cache files into InfluxDB.
How much effort do you think this will be (roughly), and do you have a (again rough) ETA? If it takes longer, and some investment (like a disk or two) does make a difference, can you please advise and I hope we can get that quickly (either via eng-infra/management, or if I have to chat with Thomas DiG I'll do that, too). Thank you, Gerald
On Tue, 2020-11-10 at 10:57 +0100, Gerald Pfeifer wrote:
On Tue 2020-11-10, Witek Bedyk wrote:
updating the tool to track Leap 15.2 is simple. It's just updating the regex for product pattern to match. I can take care of it. It's actually one of few documented items [1].
Cool, thank you!
My work was focused on extending the collected information and storing statistics about package downloads. Meaning, how often a given package gets downloaded on a day, week, month. The problem is that the script in current shape caches a lot of data on the disk which fills up already. I've written a short summary of that here [2]. I've done some work already to redesign the script and move the aggregation part from cache files into InfluxDB.
How much effort do you think this will be (roughly), and do you have a (again rough) ETA?
If it takes longer, and some investment (like a disk or two) does make a difference, can you please advise and I hope we can get that quickly (either via eng-infra/management, or if I have to chat with Thomas DiG I'll do that, too).
Please do we've raised this once to Mili, but there was no outcome.
Thank you, Gerald
-- Lubos Kocman, Release Manager openSUSE Leap SUSE Software Solutions Germany GmbH Maxfeldstr. 5, 90409 Nürnberg - Germany (HRB 36809, AG Nürnberg) Geschäftsführer: Felix Imendörffer
On Tue 2020-11-10, Lubos Kocman wrote:
How much effort do you think this will be (roughly), and do you have a (again rough) ETA?
Witold, I'm responding to Lubos, but am still interested in this. :)
If it takes longer, and some investment (like a disk or two) does make a difference, can you please advise and I hope we can get that quickly (either via eng-infra/management, or if I have to chat with Thomas DiG I'll do that, too). Please do we've raised this once to Mili, but there was no outcome.
Could you and Witold share a brief summary of what is necessary, why, and what we are asking for? (That could well be two paragraphs of text only, no overkill, please.) Thank you, Gerald
On 11/10/20 12:59 PM, Gerald Pfeifer wrote:
On Tue 2020-11-10, Lubos Kocman wrote:
How much effort do you think this will be (roughly), and do you have a (again rough) ETA?
Witold, I'm responding to Lubos, but am still interested in this. :)
I think updating the workflow to aggregate the data in InfluxDB and extend statistics to information about downloaded packages is one week of work. Depending on other assignments I should be able to finish it in 2 weeks.
If it takes longer, and some investment (like a disk or two) does make a difference, can you please advise and I hope we can get that quickly (either via eng-infra/management, or if I have to chat with Thomas DiG I'll do that, too). Please do we've raised this once to Mili, but there was no outcome.
Could you and Witold share a brief summary of what is necessary, why, and what we are asking for?
Let me first execute some experiments to evaluate the disk space requirements. Extending the partition wouldn't hurt anyway as the current one is really small. # df -h /dev/vdb1 Filesystem Size Used Avail Use% Mounted on /dev/vdb1 30G 21G 7.5G 74% /home Greetings Witek
participants (4)
-
ddemaio -
Gerald Pfeifer -
Lubos Kocman -
Witek Bedyk