[receiver/hostmetrics] Add available memory state (optionally) #19149

lootek · 2023-03-01T07:02:22Z

Description:

Add available memory state to hostmetricsreceiver.
Add enable_additional_memory_states configuration option to memoryscraper that controls reporting of memory state metrics: slab_reclaimable, slab_unreclaimable and available. This is because when those are enabled, all the memory states don't sum up well (the result exceeds total memory).

Link to tracking Issue:
#7417

Testing:
Updated the relevant memoryscraper unit tests.

Documentation:
The hostmetricsreceiver/memoryscraper docs were updated accordingly.

…utes thatt do not sum up well by default

linux-foundation-easycla · 2023-03-01T07:02:36Z

The committers listed above are authorized under a signed CLA.

✅ login: lootek / name: Piotr Lucinski (0d4fc66, c28fb17, 83c7902, 1357d66, 3b7842f, 4409f3e)

runforesight · 2023-03-12T08:41:22Z

Foresight Summary

Major Impacts

build-and-test duration(36 minutes 41 seconds) has decreased 27 minutes 47 seconds compared to main branch avg(1 hour 4 minutes 28 seconds).

View More Details

⭕ build-and-test-windows workflow has finished in 5 seconds (41 minutes 41 seconds less than `main` branch avg.) and finished at 14th Mar, 2023.

Job	Failed Steps	Tests
windows-unittest-matrix	- 🔗	N/A	See Details
windows-unittest	- 🔗	N/A	See Details

✅ telemetrygen workflow has finished in 1 minute 16 seconds (51 seconds less than `main` branch avg.) and finished at 14th Mar, 2023.

Job	Failed Steps	Tests
build-dev	- 🔗	N/A	See Details
publish-latest	- 🔗	N/A	See Details
publish-stable	- 🔗	N/A	See Details

✅ check-links workflow has finished in 1 minute 27 seconds and finished at 14th Mar, 2023.

Job	Failed Steps	Tests
changed files	- 🔗	N/A	See Details
check-links	- 🔗	N/A	See Details

❌ build-and-test workflow has finished in 36 minutes 41 seconds (27 minutes 47 seconds less than `main` branch avg.) and finished at 14th Mar, 2023. 1 job failed.

Job	Failed Steps	Tests
unittest-matrix (1.19, connector)	- 🔗	✅ 113 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.20, connector)	- 🔗	✅ 113 ❌ 0 ⏭ 0 🔗	See Details
correctness-metrics	- 🔗	✅ 2 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.20, internal)	- 🔗	✅ 583 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.19, internal)	- 🔗	✅ 583 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.20, extension)	- 🔗	✅ 538 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.20, processor)	- 🔗	✅ 1545 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.19, extension)	- 🔗	✅ 538 ❌ 0 ⏭ 0 🔗	See Details
correctness-traces	- 🔗	✅ 17 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.19, processor)	- 🔗	✅ 1545 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.20, receiver-0)	- 🔗	✅ 2609 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.19, receiver-0)	- 🔗	✅ 2609 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.19, exporter)	- 🔗	✅ 2488 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.20, exporter)	- 🔗	✅ 2488 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.19, receiver-1)	- 🔗	✅ 1940 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.20, receiver-1)	- 🔗	✅ 1940 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.20, other)	- 🔗	✅ 4728 ❌ 0 ⏭ 0 🔗	See Details
unittest-matrix (1.19, other)	- 🔗	✅ 4728 ❌ 0 ⏭ 0 🔗	See Details
integration-tests	- 🔗	✅ 55 ❌ 0 ⏭ 0 🔗	See Details
setup-environment	- 🔗	N/A	See Details
check-codeowners	- 🔗	N/A	See Details
check-collector-module-version	- 🔗	N/A	See Details
checks	CodeGen 🔗	N/A	See Details
lint-matrix (receiver-0)	- 🔗	N/A	See Details
lint-matrix (receiver-1)	- 🔗	N/A	See Details
lint-matrix (processor)	- 🔗	N/A	See Details
lint-matrix (exporter)	- 🔗	N/A	See Details
lint-matrix (extension)	- 🔗	N/A	See Details
lint-matrix (connector)	- 🔗	N/A	See Details
lint-matrix (internal)	- 🔗	N/A	See Details
lint-matrix (other)	- 🔗	N/A	See Details
build-examples	- 🔗	N/A	See Details
lint	- 🔗	N/A	See Details
unittest (1.20)	- 🔗	N/A	See Details
unittest (1.19)	- 🔗	N/A	See Details
cross-compile (darwin, amd64)	- 🔗	N/A	See Details
cross-compile (darwin, arm64)	- 🔗	N/A	See Details
cross-compile (linux, 386)	- 🔗	N/A	See Details
cross-compile (linux, amd64)	- 🔗	N/A	See Details
cross-compile (linux, arm)	- 🔗	N/A	See Details
cross-compile (linux, arm64)	- 🔗	N/A	See Details
cross-compile (linux, ppc64le)	- 🔗	N/A	See Details
cross-compile (windows, amd64)	- 🔗	N/A	See Details
cross-compile (windows, 386)	- 🔗	N/A	See Details
build-package (rpm)	- 🔗	N/A	See Details
windows-msi	- 🔗	N/A	See Details
build-package (deb)	- 🔗	N/A	See Details
publish-check	- 🔗	N/A	See Details
publish-dev	- 🔗	N/A	See Details
publish-stable	- 🔗	N/A	See Details

✅ changelog workflow has finished in 2 minutes 39 seconds and finished at 14th Mar, 2023.

Job	Failed Steps	Tests
changelog	- 🔗	N/A	See Details

✅ load-tests workflow has finished in 6 minutes 49 seconds (6 minutes 27 seconds less than `main` branch avg.) and finished at 14th Mar, 2023.

Job	Failed Steps	Tests
loadtest (TestTraceAttributesProcessor)	- 🔗	✅ 3 ❌ 0 ⏭ 0 🔗	See Details
loadtest (TestIdleMode)	- 🔗	✅ 1 ❌ 0 ⏭ 0 🔗	See Details
loadtest (TestMetric10kDPS\|TestMetricsFromFile)	- 🔗	✅ 6 ❌ 0 ⏭ 0 🔗	See Details
loadtest (TestTraceNoBackend10kSPS\|TestTrace1kSPSWithAttrs)	- 🔗	✅ 8 ❌ 0 ⏭ 0 🔗	See Details
loadtest (TestMetricResourceProcessor\|TestTrace10kSPS)	- 🔗	✅ 12 ❌ 0 ⏭ 0 🔗	See Details
loadtest (TestBallastMemory\|TestLog10kDPS)	- 🔗	✅ 18 ❌ 0 ⏭ 0 🔗	See Details
setup-environment	- 🔗	N/A	See Details
loadtest (TestTraceBallast1kSPSWithAttrs\|TestTraceBallast1kSPSAddAttrs)	- 🔗	✅ 10 ❌ 0 ⏭ 0 🔗	See Details

✅ prometheus-compliance-tests workflow has finished in 3 minutes 31 seconds (4 minutes less than `main` branch avg.) and finished at 14th Mar, 2023.

Job	Failed Steps	Tests
prometheus-compliance-tests	- 🔗	✅ 21 ❌ 0 ⏭ 0 🔗	See Details

✅ e2e-tests workflow has finished in 13 minutes 28 seconds and finished at 14th Mar, 2023.

Job	Failed Steps	Tests
kubernetes-test (v1.26.0)	- 🔗	N/A	See Details
kubernetes-test (v1.25.3)	- 🔗	N/A	See Details
kubernetes-test (v1.24.7)	- 🔗	N/A	See Details
kubernetes-test (v1.23.13)	- 🔗	N/A	See Details

🔎 See details on Foresight

^{*You can configure Foresight comments in your organization settings page.}

dmitryax

I think it's a safe solution, but not 100% sure it's sustainable in the long run.

@rogercoll @djaglowski WDYT?

Another option would be to introduce additional optional metrics like system.linux.memory.slab and system.memory.available. BTW is the available state value useful on other platforms? If not, it can be system.linux.memory.available

receiver/hostmetricsreceiver/internal/scraper/memoryscraper/metadata.yaml

receiver/hostmetricsreceiver/internal/scraper/memoryscraper/config.go

.chloggen/hostmetrics-add-mem-available.yaml

receiver/hostmetricsreceiver/internal/scraper/memoryscraper/memory_scraper_linux.go

…nfig.go Co-authored-by: Dmitrii Anoshin <[email protected]>

…mory_scraper_linux.go Co-authored-by: Dmitrii Anoshin <[email protected]>

lootek · 2023-03-13T11:10:35Z

BTW is the available state value useful on other platforms?

Looks like it is: https://github.com/shirou/gopsutil/blob/c7c548d6bdb46b39cd36ae0815926de70ab1b8ca/mem/mem.go#L22

djaglowski · 2023-03-13T14:18:50Z

receiver/hostmetricsreceiver/README.md

@@ -88,6 +88,15 @@ load:
  cpu_average: <false|true>
 ```

+### Memory
+
+`enable_additional_memory_states` specifies whether to enable reporting of a couple of additional memory state metrics: `slab_reclaimable`, `slab_unreclaimable` and `available`. When those are enabled, all the memory states don't sum up well (the result exceeds `total` memory) (default: `false`).


This isn't a hill I'm going to die on, but in my opinion we should be looking to replace this metric with one or more metrics that use attributes appropriately to differentiate portions of a meaningful total.

I'm not an expert at memory management but it seems someone should be able to clearly state the relationships between these values. As a (probably wrong) starting point:

total = buffered + cached + inactive + free + used

slab = slab_reclaimable + slab_unreclaimable

available = free + slab_reclaimable?

If we had a list of these relationships, it should be fairly easy to identify a correct data model. Without it, I don't know how to evaluate such a solution except to say that overloading a metric has never been necessary elsewhere, as far as I am aware. Again, this isn't intended to be blocking - just trying to articulate why in my opinion we are having to invent novel ways to tweak a metric.

Yeah, you're right, we're dealing with a complex issue that doesn't have a simple and universal solution. However, I believe that including the ability to report available memory is a valuable feature for users, despite its potential drawbacks.

rogercoll · 2023-03-14T08:31:57Z

Another option would be to introduce additional optional metrics like system.linux.memory.slab and system.memory.available. BTW is the available state value useful on other platforms? If not, it can be system.linux.memory.available

Memory available only has a unique value for Linux systems, as it was introduced by the kernel in version 3.16. For other platforms, it seems that Gopsutils is computing the value from others:

Windows: Same as Free -> https://github.com/shirou/gopsutil/blob/master/mem/mem_windows.go#L49 (Duplicated metric)
BSD: Inactive +Cached + Free (we currently provide all the values) -> https://github.com/shirou/gopsutil/blob/master/mem/mem_openbsd.go#L49
Darwin: Inactive + Free (already provided) -> https://github.com/shirou/gopsutil/blob/master/mem/mem_darwin_cgo.go#L43

I would consider introducing system.linux or only provide the metric for Linux systems to prevent duplications. For other platforms, we could add some documentation on how to extract the equivalent value.

lootek · 2023-03-14T09:34:05Z

@rogercoll thank you for sharing your thoughts on this topic! I do agree with some of what you've said, but there's another issue that I think we should consider as well. While it's true that the Linux kernel provides the available memory state exclusively, there are also memory states that are specific to other OSes. To me, unifying our approach would require some significant changes to the current memory scraper metrics/codebase. What do you think? Do you agree it'd be better to address this as a separate issue or pull request?

lootek · 2023-03-21T11:49:05Z

@dmitryax @djaglowski what do you think?

dmitryax · 2023-03-22T20:50:53Z

I'd lean toward introducing new optional metrics system.memory.slab and system.linux.memory.available instead of having optional attributes violating the "aggregation meaningfulness" requirement.

It should provide users with a better source in case they want to utilize both available and total linux memory metrics.

lootek · 2023-03-23T08:24:23Z

I'd lean toward introducing new optional metrics system.memory.slab and system.linux.memory.available instead of having optional attributes violating the "aggregation meaningfulness" requirement.

It should provide users with a better source in case they want to utilize both available and total linux memory metrics.

Fine, I can rewrite my PR according to this then. Just to be sure:

system.memory.slab is going to be a new metric with no differentiation between reclaimable and unreclaimable (having those available from the previous place). Also, to my understanding slab refers to the memory used by kernel specifically so it should be probably also available for linux (or unix-based) OSes only?
system.linux.memory.available is gonna be reported for linux only? What about the other unix-based OSes that have memory available supported by gopsutil?

dmitryax · 2023-03-23T18:09:39Z

system.memory.slab is going to be a new metric with no differentiation between reclaimable and unreclaimable (having those available from the previous place). Also, to my understanding slab refers to the memory used by kernel specifically so it should be probably also available for linux (or unix-based) OSes only?

Right, this should be available on Linux only, but I don't think we need to have linux prefix in the name because we don't have a conflicting meaning of slab as per the spec. The metric should have the same state attribute with reclaimable and unreclaimable values.

system.linux.memory.available is gonna be reported for linux only? What about the other unix-based OSes that have memory available supported by gopsutil?

As pointed out by @rogercoll, it looks like the metric value is unique for Linux only, and other Unix-based OSes like FreeBSD can get that value deferred from other states.

I'd like to get an agreement on this from @rogercoll and @djaglowski before starting implementation. We should also start by adding system.memory.slab to the spec to get more people involved.

Also, these issues should be handled as separate follow-up PRs. Let's keep this one for the discussion.

And thank you, @lootek, for helping with that! I think we are getting closer to finally resolving #7417

lootek · 2023-03-24T08:54:13Z

system.memory.slab is going to be a new metric with no differentiation between reclaimable and unreclaimable (having those available from the previous place). Also, to my understanding slab refers to the memory used by kernel specifically so it should be probably also available for linux (or unix-based) OSes only?

Right, this should be available on Linux only, but I don't think we need to have linux prefix in the name because we don't have a conflicting meaning of slab as per the spec. The metric should have the same state attribute with reclaimable and unreclaimable values.

So is this gonna duplicate what we currently have? Or replace the existing memory states at some point?

system.linux.memory.available is gonna be reported for linux only? What about the other unix-based OSes that have memory available supported by gopsutil?

As pointed out by @rogercoll, it looks like the metric value is unique for Linux only, and other Unix-based OSes like FreeBSD can get that value deferred from other states.

ok, this makes sense. Unless we want to provide memory available for those as a kind of "handy shortcut".

I'd like to get an agreement on this from @rogercoll and @djaglowski before starting implementation. We should also start by adding system.memory.slab to the spec to get more people involved.

Good point, for sure we should!

Also, these issues should be handled as separate follow-up PRs. Let's keep this one for the discussion.

ok 👍

And thank you, @lootek, for helping with that! I think we are getting closer to finally resolving #7417

My pleasure :) And if possible I'd like to take part in having this finally resolved.

dmitryax · 2023-03-25T06:43:27Z

So is this gonna duplicate what we currently have? Or replace the existing memory states at some point?

We will need to remove slab_reclaimable and slab_unreclaimable states from system.memory.usage metric and move them to system.memory.slab.

lootek · 2023-03-27T07:19:46Z

So is this gonna duplicate what we currently have? Or replace the existing memory states at some point?

We will need to remove slab_reclaimable and slab_unreclaimable states from system.memory.usage metric and move them to system.memory.slab.

Since such removal would be a breaking change I guess it'll be a typical 2-stage process (first the deprecation, then actiual removal)? Or are we gonna add a config setting like I did here in this PR?

rogercoll · 2023-03-27T07:29:31Z

I would not tie the metrics with the values provided by Gopsutils (the underlying library could be changed), instead, to the ones provided by each kernel. If a user requires those metrics to be provided for all the systems by the collector, the user could use the metrics generation processor to generate the new ones (at the moment does not support metric attributes, I can open an issue/pr for that) as they are currently being provided.

Specs issue to add the new system.memory.slab metric into the specification, which will solve the first issue of system.memory states not summing up to the total value. Please feel free to add extra information or change the proposal.

dmitryax · 2023-03-29T01:09:36Z

Since such removal would be a breaking change I guess it'll be a typical 2-stage process (first the deprecation, then actiual removal)? Or are we gonna add a config setting like I did here in this PR?

Right, it should be 2-step approach

Add system.memory.slab (optional) + add a warning for system.memory.usage saying that slab attributes are deprecated and will be removed, use system.memory.slab instead.
Remove slab attributes from system.memory.usage

github-actions · 2023-05-26T22:03:07Z

This PR was marked stale due to lack of activity. It will be closed in 14 days.

github-actions · 2023-06-10T05:20:03Z

This PR was marked stale due to lack of activity. It will be closed in 14 days.

github-actions · 2023-06-25T05:20:25Z

Closed as inactive. Feel free to reopen if this PR is still being worked on.

lootek added 5 commits February 21, 2023 13:12

hostmetricsreceiver/memoryscraper: Add available memory metric

0d4fc66

Add chlog

c28fb17

Merge branch 'main' into hostmetrics-add-mem-available

83c7902

Merge branch 'main' into hostmetrics-add-mem-available

1357d66

Add a configuration option to disable some of the memory state attrib…

3b7842f

…utes thatt do not sum up well by default

lootek requested a review from a team March 1, 2023 07:02

lootek requested a review from dmitryax as a code owner March 1, 2023 07:02

github-actions bot assigned dmitryax Mar 1, 2023

github-actions bot added the receiver/hostmetrics label Mar 1, 2023

lootek mentioned this pull request Mar 1, 2023

Add available memory state for hostmetrics receiver #7417

Open

lootek changed the title ~~[receiver/hostmetrics] Add available memory state~~ [receiver/hostmetrics] Add available memory state (optionally) Mar 1, 2023

update docs

4409f3e

dmitryax reviewed Mar 12, 2023

View reviewed changes

receiver/hostmetricsreceiver/internal/scraper/memoryscraper/metadata.yaml Outdated Show resolved Hide resolved

receiver/hostmetricsreceiver/internal/scraper/memoryscraper/config.go Outdated Show resolved Hide resolved

.chloggen/hostmetrics-add-mem-available.yaml Show resolved Hide resolved

dmitryax reviewed Mar 12, 2023

View reviewed changes

receiver/hostmetricsreceiver/internal/scraper/memoryscraper/memory_scraper_linux.go Outdated Show resolved Hide resolved

lootek mentioned this pull request Mar 13, 2023

[receiver/hostmetrics] Add available memory state #19150

Closed

lootek and others added 2 commits March 13, 2023 03:56

Update receiver/hostmetricsreceiver/internal/scraper/memoryscraper/co…

7709a20

…nfig.go Co-authored-by: Dmitrii Anoshin <[email protected]>

Update receiver/hostmetricsreceiver/internal/scraper/memoryscraper/me…

bea4f9f

…mory_scraper_linux.go Co-authored-by: Dmitrii Anoshin <[email protected]>

lootek added 2 commits March 13, 2023 12:25

Merge branch 'main' into hostmetrics-add-mem-available-optionally

5f98074

[CR] changelog updates

8e2bfa4

djaglowski reviewed Mar 13, 2023

View reviewed changes

lootek requested a review from dmitryax March 13, 2023 16:11

dmitryax mentioned this pull request Mar 23, 2023

hostmetrics: Remove slab reclaimable from cache #14909

Closed

rogercoll mentioned this pull request Mar 27, 2023

Proposal to add system.memory.slab open-telemetry/semantic-conventions#531

Closed

github-actions bot added the Stale label May 26, 2023

dmitryax removed the Stale label May 26, 2023

github-actions bot added the Stale label Jun 10, 2023

github-actions bot closed this Jun 25, 2023

This was referenced Aug 15, 2023

Proposal to add system.linux.memory.available open-telemetry/opentelemetry-specification#3659

Closed

Add system.linux.memory.available metric open-telemetry/semantic-conventions#257

Closed

ItsLastDay mentioned this pull request Sep 13, 2023

Add system.linux.memory.available metric open-telemetry/semantic-conventions#323

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[receiver/hostmetrics] Add available memory state (optionally) #19149

[receiver/hostmetrics] Add available memory state (optionally) #19149

lootek commented Mar 1, 2023

linux-foundation-easycla bot commented Mar 1, 2023 •

edited

Loading

runforesight bot commented Mar 12, 2023 •

edited

Loading

`build-and-test` duration(36 minutes 41 seconds) has decreased 27 minutes 47 seconds compared to main branch avg(1 hour 4 minutes 28 seconds).

⭕ build-and-test-windows workflow has finished in 5 seconds (41 minutes 41 seconds less than `main` branch avg.) and finished at 14th Mar, 2023.

✅ telemetrygen workflow has finished in 1 minute 16 seconds (51 seconds less than `main` branch avg.) and finished at 14th Mar, 2023.

✅ check-links workflow has finished in 1 minute 27 seconds and finished at 14th Mar, 2023.

❌ build-and-test workflow has finished in 36 minutes 41 seconds (27 minutes 47 seconds less than `main` branch avg.) and finished at 14th Mar, 2023. 1 job failed.

✅ changelog workflow has finished in 2 minutes 39 seconds and finished at 14th Mar, 2023.

✅ load-tests workflow has finished in 6 minutes 49 seconds (6 minutes 27 seconds less than `main` branch avg.) and finished at 14th Mar, 2023.

✅ prometheus-compliance-tests workflow has finished in 3 minutes 31 seconds (4 minutes less than `main` branch avg.) and finished at 14th Mar, 2023.

✅ e2e-tests workflow has finished in 13 minutes 28 seconds and finished at 14th Mar, 2023.

dmitryax left a comment •

edited

Loading

lootek commented Mar 13, 2023

djaglowski Mar 13, 2023

lootek Mar 13, 2023

rogercoll commented Mar 14, 2023

lootek commented Mar 14, 2023

lootek commented Mar 21, 2023

dmitryax commented Mar 22, 2023

lootek commented Mar 23, 2023 •

edited

Loading

dmitryax commented Mar 23, 2023

lootek commented Mar 24, 2023

dmitryax commented Mar 25, 2023

lootek commented Mar 27, 2023

rogercoll commented Mar 27, 2023 •

edited

Loading

dmitryax commented Mar 29, 2023

github-actions bot commented May 26, 2023

github-actions bot commented Jun 10, 2023

github-actions bot commented Jun 25, 2023

[receiver/hostmetrics] Add available memory state (optionally) #19149

[receiver/hostmetrics] Add available memory state (optionally) #19149

Conversation

lootek commented Mar 1, 2023

linux-foundation-easycla bot commented Mar 1, 2023 • edited Loading

runforesight bot commented Mar 12, 2023 • edited Loading

Foresight Summary

build-and-test duration(36 minutes 41 seconds) has decreased 27 minutes 47 seconds compared to main branch avg(1 hour 4 minutes 28 seconds).

⭕ build-and-test-windows workflow has finished in 5 seconds (41 minutes 41 seconds less than main branch avg.) and finished at 14th Mar, 2023.

✅ telemetrygen workflow has finished in 1 minute 16 seconds (51 seconds less than main branch avg.) and finished at 14th Mar, 2023.

✅ check-links workflow has finished in 1 minute 27 seconds and finished at 14th Mar, 2023.

❌ build-and-test workflow has finished in 36 minutes 41 seconds (27 minutes 47 seconds less than main branch avg.) and finished at 14th Mar, 2023. 1 job failed.

✅ changelog workflow has finished in 2 minutes 39 seconds and finished at 14th Mar, 2023.

✅ load-tests workflow has finished in 6 minutes 49 seconds (6 minutes 27 seconds less than main branch avg.) and finished at 14th Mar, 2023.

✅ prometheus-compliance-tests workflow has finished in 3 minutes 31 seconds (4 minutes less than main branch avg.) and finished at 14th Mar, 2023.

✅ e2e-tests workflow has finished in 13 minutes 28 seconds and finished at 14th Mar, 2023.

dmitryax left a comment • edited Loading

Choose a reason for hiding this comment

lootek commented Mar 13, 2023

djaglowski Mar 13, 2023

Choose a reason for hiding this comment

lootek Mar 13, 2023

Choose a reason for hiding this comment

rogercoll commented Mar 14, 2023

lootek commented Mar 14, 2023

lootek commented Mar 21, 2023

dmitryax commented Mar 22, 2023

lootek commented Mar 23, 2023 • edited Loading

dmitryax commented Mar 23, 2023

lootek commented Mar 24, 2023

dmitryax commented Mar 25, 2023

lootek commented Mar 27, 2023

rogercoll commented Mar 27, 2023 • edited Loading

dmitryax commented Mar 29, 2023

github-actions bot commented May 26, 2023

github-actions bot commented Jun 10, 2023

github-actions bot commented Jun 25, 2023

linux-foundation-easycla bot commented Mar 1, 2023 •

edited

Loading

runforesight bot commented Mar 12, 2023 •

edited

Loading

`build-and-test` duration(36 minutes 41 seconds) has decreased 27 minutes 47 seconds compared to main branch avg(1 hour 4 minutes 28 seconds).

⭕ build-and-test-windows workflow has finished in 5 seconds (41 minutes 41 seconds less than `main` branch avg.) and finished at 14th Mar, 2023.

✅ telemetrygen workflow has finished in 1 minute 16 seconds (51 seconds less than `main` branch avg.) and finished at 14th Mar, 2023.

❌ build-and-test workflow has finished in 36 minutes 41 seconds (27 minutes 47 seconds less than `main` branch avg.) and finished at 14th Mar, 2023. 1 job failed.

✅ load-tests workflow has finished in 6 minutes 49 seconds (6 minutes 27 seconds less than `main` branch avg.) and finished at 14th Mar, 2023.

✅ prometheus-compliance-tests workflow has finished in 3 minutes 31 seconds (4 minutes less than `main` branch avg.) and finished at 14th Mar, 2023.

dmitryax left a comment •

edited

Loading

lootek commented Mar 23, 2023 •

edited

Loading

rogercoll commented Mar 27, 2023 •

edited

Loading