text:
Sanity Check for reports in Smaug cluster

DoD:

Successful deployment of the curator v1.0 in Smaug.

Generate a daily report for the Smaug cluster with the Koku-metrics operator for a day (12 AM - 11:59 PM)

Get the Daily report through Curator API and check for sanity.

Daily report from Smaug cluster for -
November month reports
October month reports

The curator team got access to the Grafana dashboard from a Smaug cluster - https://grafana.operate-first.cloud/

Sanity result for [1d] report ending GMT 2021-12-08 23:59:59:
All namespaces matches within a relative difference of 5%
PromQL for memory (ranged query of the day)
sum(sum(container_memory_usage_bytes{container!='POD', container!='', pod!='', namespace='<namespace>'} / 1024 / 1024) by (node, namespace, pod)) by (namespace)

PromQL for CPU (offset time to start of the day)
sum(sum(rate(container_cpu_usage_seconds_total{container!='POD',container!='',pod!='', namespace='<namespace>'}[1d] offset <offset_to_start_of_the_day>)) BY (pod, namespace, node)) BY (namespace) * 1000

Namespace
Prometheus CPU Report
Curator CPU Report
Prometheus Memory Report
Curator Memory Report

koku-metrics-operator
1.2452417691906863
1.24
59.795084635416664
60.0

openshift-kni-infra
2204.8068931320004
2204.22
3173.7083333333335
3171.0

openshift-cluster-version
8.159180687634601
8.21
197.97900390625
198.0

openshift-ingress
13.275289601887248
13.28
184.77115885416666
185.0

openshift-service-ca
6.050435558828306
6.1
170.61100260416666
172.0

openshift-controller-manager-operator
5.977869589521837
5.98
99.982421875
100.0

openshift-cnv
31.139697923225658
31.15
9416.5185546875
9422.0

openshift-authentication
17.259739599478998
17.23
351.8474934895833
352.0

openshift-insights
3.3244862567210793
3.33
70.77376302083333
71.0

openshift-dns
13.028978573347226
13.03
291.4617513020833
291.0

grafana
1.0780919655204353
1.08
53.3603515625
53.0

openshift-controller-manager
5.14893354993632
5.23
305.01123046875
307.0

openshift-network-operator
7.741012296283447
7.73
228.7900390625
230.0

openshift-kube-scheduler-operator
8.92552609610979
8.87
94.22770182291667
94.0

openshift-service-ca-operator
4.206667435753157
4.19
80.19156901041667
80.0

openshift-kube-scheduler
16.129154392508983
16.1
553.04296875
553.0

openshift-network-diagnostics
4.461727327034858
4.38
166.08870442708334
166.0

openshift-ingress-canary
0.4813564310177135
0.48
92.41731770833333
92.0

openshift-cluster-machine-approver
3.161065721396322
3.16
164.43619791666666
166.0

openshift-cloud-credential-operator
4.9374971767048725
4.94
272.1134440104167
277.0

curator
4.233180716163012
4.24
42.959798177083336
43.0

openshift-kube-apiserver
1024.4072666354987
1021.77
12021.214518229166
12047.0

openshift-etcd-operator
16.34094875733475
16.14
117.34749348958333
117.0

openshift-machine-api
33.10723670791948
33.06
2380.2804361979165
2380.0

openshift-dns-operator
1.4881897182470767
1.48
75.798828125
76.0

openshift-etcd
629.9556851269879
629.32
8272.9248046875
8325.0

openshift-kube-apiserver-operator
20.29147718328129
20.33
172.55208333333334
172.0

openshift-kube-storage-version-migrator-operator
15.443361705777495
15.45
56.948567708333336
57.0

openshift-cluster-node-tuning-operator
1.2906727394349893
1.29
274.8644205729167
275.0

open-cluster-management-agent
31.471834960957143
31.5
454.46240234375
455.0

openshift-cluster-storage-operator
9.375254839284457
9.31
363.5299479166667
364.0

openshift-kube-controller-manager-operator
13.879395164131022
13.79
101.93603515625
102.0

openshift-sdn
17.536890467743437
17.56
488.0950520833333
489.0

costmanagement-metrics-operator
1.1747297288410325
1.18
66.87890625
67.0

openshift-authentication-operator
49.21985606012508
49.4
190.37353515625
191.0

open-cluster-management-agent-addon
198.96478748048833
198.16
716.8125
725.0

openshift-machine-config-operator
9.906586149010064
9.84
739.8509114583334
743.0

helloworld
0.21448143040407544
0.22
74.82731119791667
75.0

openshift-apiserver
175.13604609439653
175.28
4328.124837239583
4330.0

openshift-operator-lifecycle-manager
45.304638923850824
46.11
745.5099283854166
748.0

openshift-multus
44.27719448062992
44.26
691.3935546875
692.0

openshift-kube-controller-manager
67.1326318461503
67.14
1314.68994140625
1319.0

openshift-metering
90.77864781442963
90.73
4075.7013346354165
4046.0

openshift-kube-storage-version-migrator
0.2184317279610976
0.22
34.491048177083336
35.0

openshift-apiserver-operator
9.519354135915227
9.54
150.14697265625
150.0

openshift-cloud-controller-manager-operator
1.1238056030681933
1.12
90.740234375
91.0

openshift-cluster-samples-operator
2.086621596897065
2.17
125.67936197916667
124.0

report-system
32.68947296595917
32.72
347.4484049479167
347.0

openshift-image-registry
4.967626726259106
4.96
98.47672526041667
98.0

openshift-console
5.821032593249986
5.83
2901.9602864583335
2901.0

test-project
0.6178108491837454
0.63
365.671875
366.0

openshift-marketplace
130.21534943266172
129.52
1477.1920572916667
1495.0

openshift-console-operator
6.524121928169492
6.47
91.32340494791667
91.0

openshift-config-operator
7.758494158689362
7.76
78.78076171875
79.0

openshift-ingress-operator
5.114753308614088
5.18
223.61360677083334
225.0

openshift-monitoring
2829.381448794863
2826.92
29587.448079427082
29368.0

openshift-oauth-apiserver
76.34589400695842
76.44
1075.7220052083333
1076.0

Sanity result for Curator Cluster ending GMT 2021-12-12 23:59:59:
All namespaces matches within a relative difference of 5%

Namespace
Prometheus CPU Report
Curator CPU Report
Prometheus Memory Report
Curator Memory Report

costmanagement-metrics-operator
1.202696713293966
1.2
30.440266927083332
30.0

curator
4.375653097973846
4.38
42.997233072916664
43.0

grafana
1.0686150502836629
1.07
53.609375
54.0

helloworld
0.21895274442514803
0.22
72.64111328125
73.0

koku-metrics-operator
2.121783889035545
2.12
47.250813802083336
48.0

open-cluster-management-agent
30.74008879818604
30.58
335.9532877604167
338.0

open-cluster-management-agent-addon
141.33298197523814
141.52
519.61767578125
519.0

openshift-apiserver
175.21555624387435
175.33
4406.432291666667
4409.0

openshift-apiserver-operator
8.897806743316796
8.91
157.65771484375
159.0

openshift-authentication
15.00834924066997
15.01
348.17431640625
349.0

openshift-authentication-operator
28.06258707539262
28.41
192.443359375
192.0

openshift-cloud-controller-manager-operator
1.0484185358761926
1.05
90.55387369791667
91.0

openshift-cloud-credential-operator
4.68476663542897
4.69
308.2804361979167
314.0

openshift-cluster-machine-approver
2.9742525046312336
2.95
163.93961588541666
166.0

openshift-cluster-node-tuning-operator
1.239028049866852
1.24
275.2117513020833
275.0

openshift-cluster-samples-operator
2.0819473224151883
2.15
125.50048828125
124.0

openshift-cluster-storage-operator
9.136917172803056
9.16
390.0968424479167
389.0

openshift-cluster-version
11.88273168713674
11.9
200.74739583333334
201.0

openshift-cnv
28.106232018146784
28.1
6581.07861328125
6583.0

openshift-config-operator
7.645086752587686
7.64
78.91389973958333
79.0

openshift-console
3.950521863702687
3.93
2793.4803059895835
2793.0

openshift-console-operator
6.505601155702183
6.49
92.09065755208333
92.0

openshift-controller-manager
5.284088967245571
5.42
328.4444986979167
332.0

openshift-controller-manager-operator
6.095736017876608
6.12
100.32356770833333
100.0

openshift-dns
13.05549264279264
13.07
294.3846028645833
294.0

openshift-dns-operator
1.4328866632163977
1.43
76.0830078125
76.0

openshift-etcd
620.237735886778
619.74
8367.901529947916
8639.0

openshift-etcd-operator
15.994217772698844
15.85
116.04166666666667
116.0

openshift-image-registry
4.430281839689709
4.44
99.34440104166667
99.0

openshift-ingress
12.51573057722589
12.52
153.52669270833334
153.0

openshift-ingress-canary
0.46798589343522007
0.47
94.7783203125
95.0

openshift-ingress-operator
4.852071808834082
4.89
223.36604817708334
225.0

openshift-insights
3.337855729489404
3.34
70.79361979166667
71.0

openshift-kni-infra
2357.9402547351156
2356.85
3373.7822265625
3374.0

openshift-kube-apiserver
995.8682345568134
994.7
12317.284016927084
12328.0

openshift-kube-apiserver-operator
20.634168945143042
20.78
173.80387369791666
173.0

openshift-kube-controller-manager
84.97830215907145
85.29
1237.7058919270833
1245.0

openshift-kube-controller-manager-operator
13.60448815895566
13.56
101.38362630208333
102.0

openshift-kube-scheduler
16.342656812898017
16.38
558.1461588541666
559.0

openshift-kube-scheduler-operator
9.12157189212686
9.11
96.28466796875
96.0

openshift-kube-storage-version-migrator
0.22297851165914087
0.22
34.540690104166664
35.0

openshift-kube-storage-version-migrator-operator
14.967981620435342
14.97
57.077799479166664
57.0

openshift-machine-api
33.069501467928674
32.88
2482.1375325520835
2483.0

openshift-machine-config-operator
9.66429890866043
9.68
739.2042643229166
743.0

openshift-marketplace
121.6216049168547
120.32
1728.8819986979167
1737.0

openshift-metering
90.48092780653187
90.36
4021.16455078125
4044.0

openshift-monitoring
3175.1447086683484
3172.2
30234.2158203125
30038.0

openshift-multus
45.05903950759516
45.06
698.9259440104166
698.0

openshift-network-diagnostics
4.403023327717948
4.4
183.82503255208334
184.0

openshift-network-operator
7.728370030508277
7.74
239.8203125
242.0

openshift-oauth-apiserver
76.28036750620574
76.36
1130.2783203125
1130.0

openshift-operator-lifecycle-manager
47.665252870591615
48.38
780.2410481770834
782.0

openshift-sdn
17.56883330114629
17.59
490.5528971354167
490.0

openshift-service-ca
5.884397046428144
5.88
188.80875651041666
190.0

openshift-service-ca-operator
4.117320187565142
4.12
80.25634765625
80.0

report-system
33.12570366523693
33.12
346.92236328125
347.0

test-project
0.28983316692138505
0.29
371.80078125
372.0

Sanity result for Curator Cluster ending GMT 2021-12-13 23:59:59:
All namespaces matches within a relative difference of 5%

Namespace
Prometheus CPU Report
Curator CPU Report
Prometheus Memory Report
Curator Memory Report

open-cluster-management-agent
31.130186236119368
31.14
342.9309895833333
340.0

open-cluster-management-agent-addon
140.35143351792064
140.45
521.9742838541666
517.0

costmanagement-metrics-operator
1.2072045369999835
1.21
33.079915364583336
33.0

curator
4.2118075054804605
4.21
42.985026041666664
43.0

grafana
1.0708031887460918
1.07
54.624837239583336
55.0

helloworld
0.21971919939754087
0.22
71.98828125
72.0

koku-metrics-operator
2.094683551126296
2.09
46.5146484375
47.0

report-system
33.54311564003928
33.57
347.3570963541667
347.0

test-project
1.2018603287944616
1.23
374.7517903645833
375.0

openshift-cluster-storage-operator
9.151186285214763
9.14
390.0553385416667
389.0

openshift-cluster-version
8.409083788526088
8.45
198.57584635416666
198.0

openshift-cnv
28.74561541589742
28.8
6733.1865234375
6733.0

openshift-config-operator
7.661233351499365
7.66
79.2431640625
79.0

openshift-console
4.112790174053504
4.1
2767.4607747395835
2766.0

openshift-console-operator
6.512129806147988
6.5
93.07112630208333
92.0

openshift-controller-manager
5.271289629710237
5.42
329.6552734375
332.0

openshift-controller-manager-operator
6.097249509204587
6.11
100.28922526041667
100.0

openshift-dns
13.137778505587894
13.14
295.93310546875
296.0

openshift-dns-operator
1.4227721029871472
1.42
75.69905598958333
75.0

openshift-etcd
618.5300220905062
618.64
8790.050455729166
8610.0

openshift-etcd-operator
16.00012103585732
15.85
116.89534505208333
116.0

openshift-image-registry
4.221288907964361
4.21
99.59391276041667
100.0

openshift-ingress
12.531195497209696
12.56
153.88199869791666
154.0

openshift-ingress-canary
0.4790062853552756
0.48
96.40559895833333
96.0

openshift-ingress-operator
4.8997049660530285
4.87
223.56640625
226.0

openshift-insights
3.333847859326142
3.33
70.58707682291667
71.0

openshift-kni-infra
2396.8302673936146
2396.23
3419.947265625
3424.0

openshift-kube-apiserver
994.2064360383005
992.94
12381.280598958334
12418.0

openshift-kube-apiserver-operator
20.537711595415228
20.62
174.92578125
175.0

openshift-kube-controller-manager
83.85710249387857
83.94
1242.4763997395833
1251.0

openshift-kube-controller-manager-operator
13.428410190529153
13.37
101.73128255208333
102.0

openshift-kube-scheduler
16.328205338102197
16.34
559.9044596354166
560.0

openshift-kube-scheduler-operator
9.084197080351993
9.08
96.44856770833333
96.0

openshift-kube-storage-version-migrator
0.2278226785573704
0.23
34.521809895833336
35.0

openshift-kube-storage-version-migrator-operator
15.058835427011697
15.06
57.163736979166664
57.0

openshift-machine-api
33.00400221589403
32.93
2493.4866536458335
2494.0

openshift-machine-config-operator
9.624314984563563
9.64
737.1940104166666
743.0

openshift-marketplace
124.1291976843935
123.04
1635.7275390625
1625.0

openshift-metering
90.71113986528901
90.77
4009.1280924479165
4036.0

openshift-monitoring
3275.664561338513
3274.4
30321.955891927082
30125.0

openshift-multus
44.66300670960811
44.66
698.06884765625
699.0

openshift-network-diagnostics
4.397455607424007
4.34
183.93310546875
184.0

openshift-oauth-apiserver
76.45553404524142
76.44
1144.2913411458333
1145.0

openshift-operator-lifecycle-manager
47.93123833287023
48.58
775.9827473958334
784.0

openshift-sdn
18.71703173108739
18.73
490.1170247395833
491.0

openshift-service-ca
5.899601060090292
5.84
189.03580729166666
190.0

openshift-service-ca-operator
4.118929176971164
4.12
81.20947265625
80.0

openshift-network-operator
7.881217425112877
7.9
239.2001953125
243.0

openshift-apiserver
174.33066513282225
174.54
4433.496256510417
4433.0

openshift-apiserver-operator
8.96668130721317
8.99
157.5341796875
158.0

openshift-authentication
15.043258625856787
15.04
348.7490234375
349.0

openshift-authentication-operator
28.1721595570221
28.53
191.7294921875
192.0

openshift-cloud-controller-manager-operator
1.0504135014588392
1.05
90.55891927083333
91.0

openshift-cloud-credential-operator
4.658590736644671
4.67
305.40380859375
311.0

openshift-cluster-machine-approver
2.985182267187684
3.01
164.04541015625
166.0

openshift-cluster-node-tuning-operator
1.234374524493906
1.23
275.0450846354167
275.0

openshift-cluster-samples-operator
2.1107846474586127
2.18
125.90576171875
124.0

Sanity result for Curator Cluster ending GMT 2022-01-05 23:59:59:

Namespace
isAccurate
Prometheus CPU Report
Curator CPU Report
Prometheus Memory Report
Curator Memory Report

prometheus-anomaly-detector
❌
41.86365088181088
41.79
1459.9412434895833
1337.0

opf-ci-pipelines
❌
111.86124937636943
109.08
620.3006184895834
474.0

thoth-middletier-prod
❌
8.93362297659591
8.73
105.27294921875
114.0

open-cluster-management-agent-addon
❌
622.6121021898807
622.67
1300.3404947916667
1205.0

neu-cs6620
❌
181.99232061534093
182.16
422.3831380208333
661.0

opf-trino-stage
❌
38.15037790241982
37.65
5149.11962890625
4844.0

openshift-controller-manager
❌
7.167120324672918
6.94
534.2639973958334
464.0

koku-metrics-operator
✅
6.5401569123769905
6.53
552.55810546875
554.0

reloader
✅
11.67180788291073
11.67
278.79345703125
278.0

ushift-dev
✅
27.1287931293852
27.18
2473.83154296875
2476.0

thoth-amun-inspection-prod
✅
2.465007449971053
2.47
130.86328125
131.0

opf-slack-first
✅
0.27136871454208633
0.27
73.81477864583333
74.0

opf-jupyterhub-stage
✅
217.98709981453047
217.93
706.0680338541666
705.0

tremor-demo
✅
0.07870691495889788
0.08
19.59375
20.0

opf-alertreceiver
✅
0.07310146814866281
0.07
25.473470052083332
25.0

opf-observatorium
✅
7619.156913461469
7621.06
125185.40999348958
123536.0

opf-argo
✅
0.3280614894755122
0.33
34.352701822916664
34.0

tekton-pipelines
✅
5.824862039770757
5.81
260.3819986979167
260.0

opf-seldon
✅
2.7694017931341905
2.77
242.97835286458334
243.0

aicoe-meteor
✅
25.92126027629352
25.94
556.3444010416666
555.0

thoth-bots-prod
✅
9.752256535463703
9.76
817.3658854166666
820.0

fybrik-blueprints
✅
0.06170766524256104
0.06
76.37890625
76.0

b4mad-racing
✅
94.26295861967112
94.34
3751.15087890625
3751.0

seraph-platform-mq
✅
35.83861647365985
35.83
1340.64013671875
1341.0

opf-jupyterhub
✅
221.763612904719
221.67
2400.6048177083335
2392.0

open-cluster-management-agent
✅
45.08620887114739
45.19
634.3567708333334
635.0

opf-pulp
✅
27.24917037867314
27.25
1070.4410807291667
1071.0

opf-dashboard
✅
0.0481200894870905
0.05
86.70068359375
87.0

ds-github-labeler
✅
0.44980970966770834
0.45
302.9521484375
303.0

acme-operator
✅
12.898338427034862
12.91
402.0335286458333
402.0

thoth-infra-prod
✅
262.7527250102631
262.8
687.3338216145834
687.0

opf-ci-prow
✅
345.96646997349285
339.74
2324.9005533854165
2258.0

fybrik-system
✅
22.223639928088488
22.25
333.9539388020833
334.0

democratic-csi
✅
291.62613347610784
301.4
2715.8670247395835
2718.0

opf-kafka
✅
1489.5482628572884
1490.84
64258.306966145836
64574.0

apicurio-apicurio-registry
✅
20.734103209517187
20.73
905.8009440104166
906.0

thoth-backend-prod
✅
2.887848184809544
2.89
92.20361328125
92.0

opf-google-spark-operator
✅
3.116419875720744
3.12
210.55419921875
211.0

node-labeler
✅
73.25224957207324
73.2
2090.4347330729165
2062.0

dex
✅
0.21830053732777602
0.22
18.317545572916668
18.0

opf-monitoring
✅
214.74455054080082
214.89
233.1572265625
233.0

thoth-graph-prod
✅
164.65034500716698
165.37
12233.098795572916
12240.0

report-system
✅
58.15416931981021
58.16
331.8068033854167
332.0

opf-trino
✅
36.502440247991196
35.96
25457.670247395832
25202.0

opf-triage-party
✅
17.36185114437886
17.32
561.4646809895834
569.0

ds-ml-workflows-ws
✅
168.18998352323476
168.21
3005.7569986979165
2999.0

thoth-frontend-prod
✅
46.72397150913512
46.76
803.9695638020834
804.0

opendatahub-operator
✅
80.62838267730692
80.51
1658.1834309895833
1658.0

opf-superset
✅
6.791451844332519
6.79
1595.6495768229167
1596.0

openshift-cluster-node-tuning-operator
✅
15.580894675569239
15.58
3054.1974283854165
3055.0

openshift-kube-controller-manager
✅
161.83571135644377
162.18
2453.4129231770835
2452.0

openshift-kube-storage-version-migrator
✅
0.1981572695959241
0.2
31.445149739583332
31.0

openshift-oauth-apiserver
✅
45.54505047259467
45.6
1335.2249348958333
1336.0

openshift-kni-infra
✅
4139.457175550145
4139.64
23589.642578125
23610.0

openshift-cluster-version
✅
10.121064105673268
10.2
146.96907552083334
148.0

openshift-ingress
✅
268.94316972706906
269.08
296.4140625
300.0

openshift-cluster-storage-operator
✅
17.67247424362625
17.67
458.6095377604167
458.0

openshift-service-ca
✅
7.296456141287497
7.2
239.48030598958334
239.0

openshift-pipelines
✅
994.0281056354364
993.39
896.2919921875
898.0

openshift-controller-manager-operator
✅
8.695751547169127
8.72
113.20817057291667
113.0

openshift-cnv
✅
822.8110514368415
823.1
22275.491536458332
22273.0

openshift-kube-controller-manager-operator
✅
19.708249173995615
19.73
135.26171875
135.0

openshift-authentication
✅
10.129286243846236
10.12
355.3072916666667
356.0

openshift-insights
✅
2.979282029894638
2.97
181.22281901041666
179.0

openshift-dns
✅
197.8330180949789
197.86
3222.37890625
3224.0

openshift-image-registry
✅
28.610081231225696
28.75
11781.26513671875
11782.0

openshift-user-workload-monitoring
✅
278.02634863951585
277.92
6708.183430989583
6655.0

openshift-sdn
✅
442.0438388737597
443.99
9995.03271484375
9958.0

openshift-network-operator
✅
9.43333054099804
9.41
399.0989583333333
398.0

openshift-nfd
✅
92.73777501781773
92.77
1262.19189453125
1257.0

openshift-storage
✅
663.4408653525645
663.67
11372.281575520834
11404.0

openshift-kube-scheduler-operator
✅
18.79594809599404
18.8
118.1572265625
118.0

openshift-apiserver-operator
✅
15.609031633425964
15.58
199.92708333333334
200.0

openshift-service-ca-operator
✅
4.996854123816146
5.0
148.91080729166666
149.0

openshift-vertical-pod-autoscaler
✅
8.130932750395123
8.23
779.3138020833334
776.0

openshift-authentication-operator
✅
25.649388925934975
25.36
189.48600260416666
188.0

openshift-ingress-operator
✅
2.770047161792292
2.79
208.90559895833334
209.0

openshift-kube-scheduler
✅
21.240872684242213
21.18
1129.7747395833333
1129.0

openshift-console
✅
7.722822835683688
7.74
3946.341796875
3946.0

openshift-network-diagnostics
✅
12.726470487816117
12.83
1023.89404296875
1024.0

openshift-ingress-canary
✅
4.426753109817501
4.43
1890.6295572916667
1891.0

openshift-monitoring
✅
7026.0878836703805
7032.63
113370.74235026042
112170.0

openshift-cluster-machine-approver
✅
3.7051317468796956
3.74
154.42138671875
154.0

openshift-cloud-credential-operator
✅
6.7674266548222635
6.83
305.6422526041667
306.0

openshift-logging
✅
2868.542733449139
2872.57
32410.177571614582
32452.0

openshift-marketplace
✅
1410.0854364023958
1444.79
5565.704915364583
5544.0

openshift-machine-config-operator
✅
81.17563742245947
81.19
8970.6650390625
8967.0

openshift-kube-apiserver
✅
1312.929111365833
1314.94
17530.19287109375
17508.0

openshift-console-operator
✅
6.43133269613291
6.49
110.1865234375
110.0

openshift-cluster-samples-operator
✅
1.8703344362741678
1.9
165.17252604166666
164.0

openshift-etcd-operator
✅
41.43013733672574
41.22
143.7236328125
144.0

openshift-apiserver
✅
318.3096009404083
318.69
5178.677408854167
5175.0

openshift-machine-api
✅
22.60984164018756
22.78
2039.88525390625
2043.0

openshift-operator-lifecycle-manager
✅
212.45408177635747
213.66
3047.3170572916665
3053.0

openshift-dns-operator
✅
1.305505411358109
1.31
87.9091796875
88.0

openshift-etcd
✅
763.1290883475517
763.1
9224.961100260416
9220.0

openshift-kube-apiserver-operator
✅
25.80217270369345
25.69
235.70686848958334
236.0

openshift-config-operator
✅
7.452922063181649
7.45
132.45296223958334
133.0

openshift-kube-storage-version-migrator-operator
✅
13.451581597973847
13.45
123.23486328125
123.0

openshift-operators
✅
61.08127433926075
60.7
2459.1357421875
2459.0

openshift-multus
✅
517.7218203737942
518.0
7088.138997395833
7085.0

Sanity result for Curator Cluster ending GMT 2022-01-06 23:59:59:

Namespace
isAccurate
Prometheus CPU Report
Curator CPU Report
Prometheus Memory Report
Curator Memory Report

prometheus-anomaly-detector
❌
41.87590883363851
41.78
1460.107421875
1338.0

opf-ci-pipelines
❌
47.78704790631032
46.84
181.38688151041666
264.0

open-cluster-management-agent-addon
❌
622.5410366259051
622.51
1292.23828125
1202.0

neu-cs6620
❌
182.00807013576141
181.99
422.3829752604167
661.0

opf-trino-stage
❌
37.96221270135706
37.52
5180.97509765625
4903.0

training-model
❌
24.90703374898153
24.8
5796.869977678572
1852.0

openshift-controller-manager
❌
7.109225576681718
6.9
531.7237955729166
462.0

thoth-backend-prod
✅
2.940338757913626
2.93
92.212890625
92.0

reloader
✅
11.609811148998501
11.62
278.9607747395833
279.0

ushift-dev
✅
10.154919367616053
10.18
2700.53857421875
2701.0

thoth-amun-inspection-prod
✅
2.4687863211068657
2.47
130.91569010416666
131.0

opf-slack-first
✅
0.30421217379877297
0.3
74.08024088541667
74.0

opf-jupyterhub-stage
✅
218.1879333634712
218.21
707.6277669270834
708.0

tremor-demo
✅
0.07904549459302994
0.08
19.59375
20.0

opf-alertreceiver
✅
0.07620671117286097
0.08
25.474283854166668
25.0

opf-observatorium
✅
8017.400957567167
8027.89
126936.56608072917
125137.0

opf-argo
✅
0.3273478341438
0.33
34.35205078125
34.0

tekton-pipelines
✅
5.319368326328596
5.19
260.3898111979167
260.0

opf-seldon
✅
2.7760165156863357
2.78
244.18717447916666
244.0

aicoe-meteor
✅
25.79735080839411
25.79
546.4783528645834
547.0

thoth-bots-prod
✅
9.776898378026987
9.83
818.5836588541666
818.0

fybrik-blueprints
✅
0.09565318611786491
0.1
78.75716145833333
79.0

b4mad-racing
✅
94.54696226451318
94.57
3747.66064453125
3746.0

seraph-platform-mq
✅
36.443788297614894
36.42
1348.8896484375
1349.0

opf-jupyterhub
✅
232.15460186367258
231.41
2280.9215494791665
2241.0

open-cluster-management-agent
✅
45.05058262731272
45.24
635.162109375
635.0

opf-pulp
✅
27.138079527993185
27.13
1070.8933919270833
1071.0

opf-dashboard
✅
0.05821533013013518
0.06
96.81087239583333
98.0

ds-github-labeler
✅
0.45043186388792356
0.45
302.95361328125
303.0

thoth-middletier-prod
✅
4.125009277940826
4.13
105.32275390625
106.0

acme-operator
✅
15.45646276631933
15.44
402.0538736979167
402.0

thoth-infra-prod
✅
262.88584832219425
262.72
687.9000651041666
688.0

opf-ci-prow
✅
462.8224728873482
453.39
2352.4220377604165
2337.0

fybrik-system
✅
22.350912125367593
22.35
334.0236002604167
334.0

democratic-csi
✅
287.8404505681811
297.37
2726.0436197916665
2726.0

opf-kafka
✅
1490.8756342278311
1491.53
67220.11507161458
67236.0

apicurio-apicurio-registry
✅
20.60420704051175
20.61
906.5421549479166
907.0

koku-metrics-operator
✅
6.479253989927062
6.48
568.89013671875
570.0

opf-google-spark-operator
✅
3.00183702943151
3.0
210.56510416666666
211.0

node-labeler
✅
73.2532351919601
73.26
2064.1962890625
2066.0

dex
✅
0.2521973660182936
0.26
18.326822916666668
18.0

opf-monitoring
✅
215.28661198762336
215.3
235.58951822916666
235.0

thoth-graph-prod
✅
165.56805184131682
165.89
12237.96240234375
12242.0

report-system
✅
56.1527204802015
56.22
331.76171875
332.0

opf-trino
✅
41.12249377951615
40.68
25587.751790364582
25367.0

opf-triage-party
✅
17.341868166110913
17.38
578.2574869791666
571.0

ds-ml-workflows-ws
✅
181.4811674039284
181.35
2602.9091796875
2591.0

thoth-frontend-prod
✅
47.2207594764849
47.2
792.2667643229166
792.0

opendatahub-operator
✅
226.74651940559048
223.47
1614.4944661458333
1560.0

opf-superset
✅
6.864244673573267
6.83
1520.38232421875
1533.0

openshift-kube-controller-manager
✅
169.10271336954958
169.57
2439.8489583333335
2447.0

openshift-kube-storage-version-migrator
✅
0.20196589971054726
0.2
31.453287760416668
31.0

openshift-kni-infra
✅
4112.925247530491
4113.17
24310.12646484375
24325.0

openshift-cluster-version
✅
10.000429790239664
10.09
148.5478515625
149.0

openshift-ingress
✅
272.5429056267336
272.83
315.8177083333333
315.0

openshift-monitoring
✅
6906.128286783338
6910.18
120809.78352864583
119718.0

openshift-service-ca
✅
7.32641421145072
7.27
239.48323567708334
239.0

openshift-pipelines
✅
1077.803082056012
1078.33
913.2430013020834
917.0

openshift-controller-manager-operator
✅
8.902103483929592
8.89
113.18522135416667
113.0

openshift-cnv
✅
816.3533875677209
816.39
22344.549153645832
22389.0

openshift-cluster-storage-operator
✅
17.303448055667474
17.42
458.1175130208333
458.0

openshift-authentication
✅
10.415803302269314
10.41
354.64892578125
355.0

openshift-insights
✅
2.9597653689822905
2.99
180.52880859375
181.0

openshift-dns
✅
198.0779272407639
197.96
3224.1456705729165
3226.0

openshift-kube-controller-manager-operator
✅
18.721910234132224
18.74
135.78645833333334
136.0

openshift-user-workload-monitoring
✅
268.1449259704761
268.07
6693.5693359375
6635.0

openshift-image-registry
✅
28.524004573997352
28.32
11781.886555989584
11782.0

openshift-network-operator
✅
9.373654168113939
9.41
395.48876953125
396.0

openshift-sdn
✅
438.46175483112074
438.25
9909.474283854166
9908.0

openshift-storage
✅
695.807958928447
695.78
13105.846028645834
13114.0

openshift-kube-scheduler-operator
✅
18.50408569316892
18.5
118.14485677083333
118.0

openshift-nfd
✅
88.30307952018025
88.27
963.1092122395834
964.0

openshift-service-ca-operator
✅
4.819109638149807
4.81
148.41959635416666
149.0

openshift-apiserver-operator
✅
15.42786348967233
15.41
199.99625651041666
200.0

openshift-vertical-pod-autoscaler
✅
7.516673881706611
7.3
552.4938151041666
554.0

openshift-authentication-operator
✅
25.372850238392974
25.12
187.40364583333334
189.0

openshift-kube-scheduler
✅
21.243036812180144
21.33
1132.4358723958333
1131.0

openshift-oauth-apiserver
✅
45.62274380157459
45.63
1389.9274088541667
1391.0

openshift-network-diagnostics
✅
12.70632681200988
12.93
1025.17822265625
1026.0

openshift-ingress-canary
✅
4.429405140187621
4.43
1892.6476236979167
1893.0

openshift-console
✅
6.011608933970135
6.03
3951.12353515625
3950.0

openshift-cluster-machine-approver
✅
3.6675512236887844
3.67
154.77262369791666
155.0

openshift-ingress-operator
✅
2.7385487372467274
2.74
208.80989583333334
209.0

openshift-cloud-credential-operator
✅
6.746055302107225
6.83
305.9462890625
306.0

openshift-logging
✅
2951.5522078916865
2947.58
33011.55908203125
32905.0

openshift-marketplace
✅
1433.7203931044382
1438.72
5771.600260416667
5707.0

openshift-machine-config-operator
✅
81.69163096456528
81.75
8892.203287760416
8892.0

openshift-kube-apiserver
✅
1334.2707678794604
1336.13
18080.756998697918
18076.0

openshift-console-operator
✅
6.239846937362526
6.28
109.92496744791667
110.0

openshift-cluster-samples-operator
✅
1.8805050596966555
1.91
165.68619791666666
164.0

openshift-etcd-operator
✅
40.918086158214656
40.74
144.62955729166666
144.0

openshift-apiserver
✅
356.3373205051986
356.18
5166.9951171875
5166.0

openshift-machine-api
✅
22.432508411323376
22.6
2052.0940755208335
2053.0

openshift-operator-lifecycle-manager
✅
188.07959755254717
189.56
3019.2535807291665
3026.0

openshift-dns-operator
✅
1.3222302188028268
1.32
87.92496744791667
88.0

openshift-etcd
✅
776.7785226770177
777.28
9192.309733072916
9264.0

openshift-kube-apiserver-operator
✅
26.73319834918378
26.69
236.08203125
236.0

openshift-config-operator
✅
7.230876634213266
7.23
133.4775390625
133.0

openshift-kube-storage-version-migrator-operator
✅
13.150364926085471
13.16
123.35514322916667
123.0

openshift-operators
✅
60.886768107731164
60.38
2470.8463541666665
2471.0

openshift-multus
✅
517.1174218122612
517.23
7074.725911458333
7077.0

openshift-cluster-node-tuning-operator
✅
15.446848327331242
15.44
3056.8859049479165
3057.0

Sanity result for Curator Cluster ending GMT 2022-01-16 23:59:59:

Namespace
isAccurate
Prometheus CPU Report
Curator CPU Report
Prometheus Memory Report
Curator Memory Report

opf-alertreceiver
❌
0.07436398289915473
0.07
25.475130208333333
25.0

opf-trino-stage
❌
38.818941554868594
37.99
5280.482240125868
4780.0

acme-operator
✅
22.781293281289788
22.78
402.5072455512153
403.0

aicoe-meteor
✅
32.396911439087674
32.4
734.839794921875
735.0

apicurio-apicurio-registry
✅
21.129580325182392
21.12
926.8973090277777
927.0

b4mad-racing
✅
94.03461736777825
94.05
3725.3329616970486
3725.0

democratic-csi
✅
280.41779441926593
289.59
2748.546177842882
2749.0

dex
✅
0.2444819833854344
0.25
21.68251410590278
22.0

ds-github-labeler
✅
0.488387617343985
0.49
302.9549072265625
303.0

ds-ml-workflows-ws
✅
10.131767746555516
10.13
2704.6553819444443
2705.0

fybrik-blueprints
✅
0.19545388806298472
0.2
91.90234375
92.0

fybrik-system
✅
22.36851112116478
22.36
334.62088487413195
335.0

koku-metrics-operator
✅
6.390908846034507
6.4
771.9135687934028
772.0

neu-cs6620
✅
181.97487285307415
182.09
659.8983506944444
660.0

node-labeler
✅
72.72496259248582
72.75
2065.7547715928818
2066.0

open-cluster-management-agent
✅
54.49410959726757
54.46
638.7215793185763
639.0

open-cluster-management-agent-addon
✅
631.446277397869
632.32
1143.8338433159722
1159.0

opendatahub-operator
✅
1114.0111660373273
1113.33
1946.5084201388888
1947.0

opf-argo
✅
0.3152187226351749
0.31
36.400018988715274
36.0

opf-ci-pipelines
✅
2.097898313430588
2.1
521.4718668619792
521.0

opf-ci-prow
✅
299.7078741901885
299.71
1823.1966281467014
1823.0

opf-dashboard
✅
0.08304169533402797
0.08
132.60049913194445
133.0

opf-google-spark-operator
✅
2.434345161039707
2.44
212.859521484375
213.0

opf-jupyterhub
✅
222.54691952031078
222.66
1898.2111735026042
1899.0

opf-jupyterhub-stage
✅
216.71228510526785
216.77
733.4868706597222
734.0

opf-kafka
✅
1476.8925494357284
1477.12
65997.36060384115
66037.0

opf-monitoring
✅
211.15519258551612
211.32
265.05113932291664
265.0

opf-observatorium
✅
9312.954474129312
9318.56
149880.6513970269
149883.0

opf-pulp
✅
27.260005835811008
27.25
1069.7884087456598
1070.0

opf-seldon
✅
2.8519118443325175
2.86
244.24293891059028
244.0

opf-slack-first
✅
0.2766868885492648
0.28
74.52288140190973
75.0

opf-superset
✅
5.712318260842888
5.72
2132.2424696180556
2132.0

opf-triage-party
✅
16.21817418770404
16.18
586.6231743706597
587.0

opf-trino
✅
38.11740256157228
37.91
34267.330555555556
34150.0

prometheus-anomaly-detector
✅
41.93520098298013
41.98
1340.9910129123264
1342.0

reloader
✅
11.914492097070712
11.92
280.53723958333336
281.0

report-system
✅
56.82416049620239
56.88
331.7018229166667
332.0

seraph-ingress
✅
8.724131372953574
8.72
91.27271592881945
91.0

seraph-platform-mq
✅
39.623960369526436
39.62
1367.71572265625
1368.0

tekton-chains
✅
2.0911500438115076
2.09
79.87526312934028
80.0

tekton-pipelines
✅
6.123542141646402
6.15
260.7139377170139
261.0

thoth-amun-api-prod
✅
1.5329444446219755
1.54
310.9459499782986
311.0

thoth-amun-inspection-prod
✅
2.5946069570915817
2.6
139.15438096788193
139.0

thoth-backend-prod
✅
4.030868474963888
3.95
182.21358506944443
183.0

thoth-bots-prod
✅
9.527941190019687
9.53
826.4009684244792
826.0

thoth-frontend-prod
✅
47.29140831450733
47.31
811.9041286892361
812.0

thoth-graph-prod
✅
21.853063022831815
22.42
12257.69251030816
12258.0

thoth-infra-prod
✅
262.7314937739958
262.74
639.9149712456597
640.0

thoth-middletier-prod
✅
4.048939002315997
4.1
108.06679144965278
108.0

training-model
✅
3997.828790978161
3998.03
4117.663465711806
4118.0

tremor-demo
✅
0.07782227889313419
0.08
19.59375
20.0

ushift-dev
✅
8.668148207097406
8.65
2706.3087266710068
2706.0

openshift-marketplace
✅
1185.802928446263
1228.85
6001.710101996528
6012.0

openshift-monitoring
✅
7725.339054227884
7727.64
134657.67474500867
134640.0

openshift-multus
✅
510.7964510763996
510.83
7085.400138346354
7085.0

openshift-network-diagnostics
✅
12.041095188550749
12.15
1032.3635579427084
1032.0

openshift-network-operator
✅
9.555761602454568
9.52
395.70872395833334
396.0

openshift-nfd
✅
90.90493057978554
90.82
1058.9000759548612
1059.0

openshift-oauth-apiserver
✅
45.467551261676576
45.5
1881.1312310112846
1881.0

openshift-operator-lifecycle-manager
✅
307.85036508263215
308.33
2541.487220594618
2541.0

openshift-operators
✅
61.04831490536933
60.62
2688.14892578125
2688.0

openshift-pipelines
✅
1808.096550924464
1809.15
1310.5322645399306
1311.0

openshift-sdn
✅
417.93705717736253
418.44
9824.446332465277
9824.0

openshift-service-ca
✅
7.377939809065658
7.37
241.52085774739584
242.0

openshift-service-ca-operator
✅
6.158089634004853
6.16
147.90108235677084
148.0

openshift-storage
✅
715.5309992716899
715.53
14394.515502929688
14395.0

openshift-user-workload-monitoring
✅
289.1932707595988
289.18
6794.642108832465
6795.0

openshift-vertical-pod-autoscaler
✅
7.7111839809656155
7.57
695.0443440755208
695.0

openshift-apiserver
✅
1057.4765620788019
1057.32
5151.068248155382
5151.0

openshift-apiserver-operator
✅
16.773508798517994
16.73
199.99109157986112
200.0

openshift-authentication
✅
10.005522760669207
10.0
357.2313937717014
357.0

openshift-authentication-operator
✅
27.871415232453316
27.96
192.17860243055554
190.0

openshift-cloud-credential-operator
✅
7.595247187889287
7.68
312.4281711154514
312.0

openshift-cluster-machine-approver
✅
3.5490938408011954
3.54
155.7814697265625
156.0

openshift-cluster-node-tuning-operator
✅
16.210078337236705
16.2
3078.49638671875
3078.0

openshift-cluster-samples-operator
✅
1.807407960414499
1.81
168.23591851128472
168.0

openshift-cluster-storage-operator
✅
19.72248191505153
19.69
464.6740614149306
465.0

openshift-cluster-version
✅
10.940895991411935
10.91
133.81771918402777
134.0

openshift-cnv
✅
860.304221754872
860.08
24978.95259331597
24979.0

openshift-config-operator
✅
8.738486637825632
8.74
131.7299099392361
132.0

openshift-console
✅
3.1930173033808136
3.19
3943.8153510199654
3944.0

openshift-console-operator
✅
7.612239569943248
7.59
109.08939887152778
109.0

openshift-controller-manager
✅
6.622825940052273
6.74
465.488037109375
465.0

openshift-controller-manager-operator
✅
17.201892387356793
17.21
108.92327202690973
109.0

openshift-dns
✅
195.24043737153085
195.03
3241.5395128038194
3242.0

openshift-dns-operator
✅
1.3444946965728832
1.36
87.80097113715277
88.0

openshift-etcd
✅
802.3260292754654
802.11
9132.021516927083
9126.0

openshift-etcd-operator
✅
42.588785901528354
42.52
146.45030924479167
147.0

openshift-image-registry
✅
32.509883536250776
32.49
20164.705598958335
20165.0

openshift-ingress
✅
282.5410559500989
282.61
302.47782931857637
302.0

openshift-ingress-canary
✅
4.417772375814346
4.42
1894.5708062065971
1895.0

openshift-ingress-operator
✅
2.8048707809308735
2.81
211.9302924262153
212.0

openshift-insights
✅
2.9760380883177047
2.97
180.92482367621528
181.0

openshift-kni-infra
✅
4109.3218200550255
4109.24
31459.777851019964
31461.0

openshift-kube-apiserver
✅
1369.789854309913
1370.87
15153.512103949653
15149.0

openshift-kube-apiserver-operator
✅
34.641951258342125
34.57
236.02284342447916
236.0

openshift-kube-controller-manager
✅
269.86483102129506
269.26
2453.3149169921876
2453.0

openshift-kube-controller-manager-operator
✅
22.070751963679534
22.08
135.31446397569445
135.0

openshift-kube-scheduler
✅
20.78007413369082
20.87
1129.6659478081597
1130.0

openshift-kube-scheduler-operator
✅
19.915073088317776
19.92
117.99206000434027
118.0

openshift-kube-storage-version-migrator
✅
0.20278029915479828
0.2
31.60263943142361
32.0

openshift-kube-storage-version-migrator-operator
✅
14.612668985747423
14.61
123.82447374131945
124.0

openshift-logging
✅
2107.7090670103125
2106.39
23644.944949001736
23647.0

openshift-machine-api
✅
23.18442865955768
23.05
2152.729109700521
2153.0

openshift-machine-config-operator
✅
86.506143526038
86.53
8354.238053385418
8354.0

Sanity result for Curator Cluster ending GMT 2022-01-17 23:59:59:

Namespace
isAccurate
Prometheus CPU Report
Curator CPU Report
Prometheus Memory Report
Curator Memory Report

opf-dashboard
❌
0.08469664615028362
0.08
132.86466471354166
133.0

opf-trino-stage
❌
38.882272418443875
38.32
5301.666897243924
4968.0

acme-operator
✅
22.91701639649184
22.91
402.5265299479167
403.0

aicoe-meteor
✅
69.57344919854619
69.71
878.4314181857638
878.0

apicurio-apicurio-registry
✅
21.27589283997913
21.27
927.8792561848958
928.0

b4mad-racing
✅
94.3262869636795
94.4
3751.4331217447916
3751.0

democratic-csi
✅
284.8391204175869
294.13
2760.769626193576
2760.0

dex
✅
0.2354274340395971
0.23
21.691842990451388
22.0

ds-github-labeler
✅
0.4946536222994097
0.5
302.95780978732637
303.0

ds-ml-workflows-ws
✅
10.143248506286906
10.15
2704.7091606987847
2705.0

fybrik-blueprints
✅
0.19759738567789714
0.2
91.90234375
92.0

fybrik-system
✅
22.434410387912536
22.45
334.65238986545137
335.0

koku-metrics-operator
✅
6.689501490471238
6.71
792.6952338324653
793.0

neu-cs6620
✅
181.96811761914324
182.11
660.8780110677084
661.0

node-labeler
✅
72.52972249474776
72.54
2067.25999077691
2067.0

open-cluster-management-agent
✅
54.573116282652855
54.49
641.5774224175348
642.0

open-cluster-management-agent-addon
✅
638.2941431226941
634.55
1126.3543782552083
1126.0

opendatahub-operator
✅
1105.405885325437
1106.32
2022.544105360243
2023.0

opf-alertreceiver
✅
0.09545183997915928
0.1
25.492182074652778
25.0

opf-argo
✅
0.32647843845085134
0.33
36.3996826171875
36.0

opf-ci-pipelines
✅
195.6656627923809
193.91
1225.525697157118
1227.0

opf-ci-prow
✅
610.4327259000938
606.3
2917.9580674913195
2921.0

opf-google-spark-operator
✅
3.798418665323601
3.79
212.86383192274306
213.0

opf-jupyterhub
✅
255.2636974847628
255.09
3340.5393798828127
3339.0

opf-jupyterhub-stage
✅
216.28990033179423
216.26
736.3733127170138
736.0

opf-kafka
✅
1460.099510839249
1460.11
66305.45804036458
66305.0

opf-monitoring
✅
211.24160947990057
211.14
263.5434054904514
264.0

opf-observatorium
✅
9418.78834892681
9427.06
148163.73819715713
148173.0

opf-pulp
✅
27.55128677789743
27.55
1069.8102837456597
1070.0

opf-seldon
✅
2.836039772907264
2.84
244.2360324435764
244.0

opf-slack-first
✅
0.31413943475743816
0.31
74.37918836805555
74.0

opf-superset
✅
6.6595246009494
6.68
2137.054866536458
2137.0

opf-triage-party
✅
16.151026882447564
16.25
585.8576985677083
585.0

opf-trino
✅
42.24862801624412
41.87
34302.660096571184
34068.0

prometheus-anomaly-detector
✅
42.05641052606238
42.14
1340.177956814236
1340.0

reloader
✅
12.082323264304746
12.08
279.6764105902778
280.0

report-system
✅
58.61419875959241
58.68
331.75376790364584
332.0

seraph-ingress
✅
8.769886061259697
8.78
92.64886067708333
93.0

seraph-platform-mq
✅
39.673818105059624
39.7
1378.8748725043404
1379.0

tekton-chains
✅
12.387492485234537
12.14
90.64122450086805
91.0

tekton-pipelines
✅
7.986794305418557
7.94
260.73101942274303
261.0

thoth-amun-api-prod
✅
1.508731467618321
1.52
314.2984320746528
314.0

thoth-amun-inspection-prod
✅
2.603871449403727
2.6
139.15419108072916
139.0

thoth-backend-prod
✅
193.3349759748706
193.1
333.4666639539931
334.0

thoth-bots-prod
✅
11.836578040860696
11.83
826.8655381944444
827.0

thoth-frontend-prod
✅
45.92147072904942
45.95
785.2469455295139
785.0

thoth-graph-prod
✅
21.894312148477415
22.32
12275.482351345487
12276.0

thoth-infra-prod
✅
263.07563185044637
263.17
646.9095323350695
647.0

thoth-middletier-prod
✅
3.959697347509328
3.96
109.0847195095486
109.0

training-model
✅
3998.017903006308
3995.88
4117.760427517361
4118.0

tremor-demo
✅
0.0777075738219288
0.08
19.59375
20.0

ushift-dev
✅
8.702759800752586
8.68
2706.3660183376737
2706.0

openshift-marketplace
✅
1252.3113938911958
1318.21
5830.776174587673
5818.0

openshift-monitoring
✅
7725.462118366565
7724.83
137230.2059624566
137230.0

openshift-multus
✅
514.5795185826147
514.57
7137.85202094184
7138.0

openshift-network-diagnostics
✅
11.952054153162043
12.11
1033.1386474609376
1033.0

openshift-network-operator
✅
10.048075688329277
10.07
404.32860785590276
404.0

openshift-nfd
✅
91.34736829996012
91.36
1061.9626708984374
1062.0

openshift-oauth-apiserver
✅
45.49507425041108
45.5
1924.7991726345485
1925.0

openshift-operator-lifecycle-manager
✅
306.2813472867676
308.85
2520.0576226128474
2520.0

openshift-operators
✅
63.22249961849585
63.0
2715.494775390625
2715.0

openshift-pipelines
✅
1851.639849725338
1852.41
1330.1334988064236
1330.0

openshift-sdn
✅
472.8974660753478
473.09
10098.125298394098
10098.0

openshift-service-ca
✅
7.442110756014815
7.34
243.11446397569443
243.0

openshift-service-ca-operator
✅
6.267039632441834
6.27
147.80608452690973
148.0

openshift-storage
✅
764.3883902033713
760.35
11636.657446289062
11546.0

openshift-user-workload-monitoring
✅
291.509215546595
291.57
6771.31754828559
6769.0

openshift-vertical-pod-autoscaler
✅
8.820678266886647
8.63
729.1418185763889
729.0

openshift-apiserver
✅
1051.648737324475
1051.61
5179.067051866319
5179.0

openshift-apiserver-operator
✅
17.051410809609816
17.06
201.97851833767362
202.0

openshift-authentication
✅
9.939303290864888
9.93
357.0944932725694
357.0

openshift-authentication-operator
✅
28.67609439678128
28.77
190.88013509114583
191.0

openshift-cloud-credential-operator
✅
7.984811084659003
7.99
314.3693142361111
314.0

openshift-cluster-machine-approver
✅
3.8174729378487915
3.79
155.8273871527778
156.0

openshift-cluster-node-tuning-operator
✅
16.360280997222297
16.36
3080.655859375
3080.0

openshift-cluster-samples-operator
✅
1.8459704856431634
1.85
167.55162217881946
168.0

openshift-cluster-storage-operator
✅
20.211207375118654
20.19
468.79849717881945
469.0

openshift-cluster-version
✅
10.998845461039714
11.0
141.06694878472223
141.0

openshift-cnv
✅
895.4064878311445
895.18
24982.2162109375
24982.0

openshift-config-operator
✅
8.992592789695491
9.0
131.6718288845486
132.0

openshift-console
✅
4.657369920979513
4.65
3950.625661892361
3951.0

openshift-console-operator
✅
7.8021091220447
7.78
108.92066514756945
109.0

openshift-controller-manager
✅
7.270376644216741
7.4
478.50781792534724
479.0

openshift-controller-manager-operator
✅
17.386279130276705
17.38
108.93779296875
109.0

openshift-dns
✅
197.04713655639654
197.21
3240.9193196614583
3241.0

openshift-dns-operator
✅
1.3385612026398073
1.35
87.78226996527778
88.0

openshift-etcd
✅
825.6166789053373
825.72
9263.925206163194
9258.0

openshift-etcd-operator
✅
43.51731549450036
43.62
146.69085286458332
147.0

openshift-image-registry
✅
34.87151839803018
35.01
19136.57043185764
19137.0

openshift-ingress
✅
287.2204730309018
287.67
310.01738009982637
310.0

openshift-ingress-canary
✅
4.394737466925595
4.39
1894.7515245225695
1895.0

openshift-ingress-operator
✅
2.819552175523912
2.88
212.22764214409722
212.0

openshift-insights
✅
2.9627647357994604
2.98
180.93309190538196
181.0

openshift-kni-infra
✅
4116.168708519407
4116.71
32173.048385959202
32173.0

openshift-kube-apiserver
✅
1412.1435009644897
1412.13
16435.815972222223
16435.0

openshift-kube-apiserver-operator
✅
35.615388210732974
35.58
237.37294379340278
237.0

openshift-kube-controller-manager
✅
273.9569850235846
273.69
2509.9514458550348
2510.0

openshift-kube-controller-manager-operator
✅
22.133173556142175
22.14
135.25163031684028
136.0

openshift-kube-scheduler
✅
21.45109696747715
21.42
1143.5091525607638
1143.0

openshift-kube-scheduler-operator
✅
20.10271830487437
20.11
118.45880262586806
118.0

openshift-kube-storage-version-migrator
✅
0.2051465171587351
0.21
31.627183702256943
32.0

openshift-kube-storage-version-migrator-operator
✅
14.796586423735123
14.79
125.20697699652777
125.0

openshift-logging
✅
2316.6596439060754
2316.44
24726.361984592015
24734.0

openshift-machine-api
✅
23.1185081632743
23.01
2159.6494927300346
2160.0

openshift-machine-config-operator
✅
86.56165593036941
86.68
8317.48770345052
8318.0

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close

@sesheta: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
/close

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

authors: leihchen sesheta skanthed

repo: operate-first/curator


text:
:bug: bump the catalogserver write timeout to 1 minute

to allow for fully writing large catalogs contents in the response

Removed from merge queue as there is some discussion around whether or not 1 minute is enough

source: gharchive/pull-request

repo: operator-framework/catalogd

license_type: permissive

license_source: github-api


text:
Make the ControllerConfiguration annotation optional

With workflows being moved to their own annotation, it might often happen that the ControllerConfiguration ends up being empty. It would be nice if it could be made optional.
Originally posted by @csviri in https://github.com/operator-framework/java-operator-sdk/issues/2274#issuecomment-1989056835

Note that, if I recall properly, we already looked at making it optional at some point but ran into some issues (though I don't remember which ones).
Note also that the annotation is already optional when you use the Quarkus extension because the processing is based on whether or not a class implements the Reconciler interface there.

source: gharchive/issue

repo: operator-framework/java-operator-sdk


text:
Bug 1855088: generate unique (Cluster)RoleBinding names

Description of the change:
Make ServiceAccount name part of the input for (Cluster)RoleBinding name generation.
This is done by passing permission object, of StrategyDeploymentPermissions type,
which contains ServiceAccountName and Rules fields.
Motivation for the change:
When same permission rules were defined for different ServiceAccounts,
OLM would generate same name for (Cluster)RoleBinding related to this rules.
BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1855088
Closes #1625
Reviewer Checklist

[ ] Implementation matches the proposed design, or proposal is updated to match implementation
[ ] Sufficient unit test coverage
[ ] Sufficient end-to-end test coverage
[ ] Docs updated or added to /docs
[ ] Commit messages sensible and descriptive

Note: this PR only addresses (Cluster)RoleBinding that are created when there are identical permissions rules.
OLM will still create just one (Cluster)Role, which will then be bound to multiple ServiceAccounts.
I would call this accidental optimization :)
Not sure if this needs to be addressed or not.

/ok-to-test

/retest

/lgtm

/retest

/retest

The last commit:

should address @njhale concern about collision on ClusterBinding, as well as some other possible collisions/edge cases.
fully addresses #1625 - it will create distinct roles for each ServiceAccount, even if the rules are the same.
brings back ServiceAccount name into (Cluster)Role name, as that was fairly convenient when troubleshooting

Looking forward to feedback. Cheers.

/lgtm

Looks like ci/prow/e2e-aws-olm tests are failing for different reasons between the runs:
 [Fail] Install Plan with deprecated version CRD Test [It] upgrade CRD with deprecated version
FAIL! -- 117 Passed | 1 Failed | 1 Pending | 3 Skipped

[Fail] CSV [It] API service resource not migrated if not adoptable
FAIL! -- 117 Passed | 1 Failed | 1 Pending | 3 Skipped

 [Fail] Catalog [It] delete gRPC registry pod triggers recreation
FAIL! -- 117 Passed | 1 Failed | 1 Pending | 3 Skipped

/cherry-pick release-4.5

/retest

authors: dinhxuanvu ecordell kevinrizza matskiv

license_source: bigquery


text:
fix(packagemanifest): Add InstallModes info from CSV to PackageManifest

PackageManifest is missing InstallModes information from CSV.
Each CSVDescription should have the spec.installModes from the
ClusterServiceVersion copied as well. This allows us to compare
PackageManifests to potential OperatorGroups that they would be
installed into and prevent errors.
Signed-off-by: Vu Dinh vdinh@redhat.com

@dinhxuanvu You probably have to run make vendor.

/retest

/test e2e-aws
/test e2e-aws-olm

/lgtm

/retest

/retest

/hold

/hold cancel

/retest

/lgtm
(lost previous lgtm from clean rebase)

time="2019-02-08T13:39:46Z" level=fatal msg="unable to setup API &{[packages.apps.redhat.com/v1alpha1] map[v1alpha1:map[packagemanifests:0xc420705bc0]] v1  0xc4204de000 {0xc4204de000 [{[application/json] application/json [json] true 0xc4204cc100 0xc4204cc240 []  {} 0xc4204cc100} {[application/yaml] application/yaml [yaml] true 0xc4204cd040  []   } {[application/vnd.kubernetes.protobuf] application/vnd.kubernetes.protobuf [pb] false 0xc4200fce10  []  {} 0xc4201d2ea0}] 0xc420352600 [{application/json true 0xc4204cc100 0xc4204cc240 0xc4201d2f00} {application/yaml true 0xc4204cd040  } {application/vnd.kubernetes.protobuf false 0xc4200fce10  0xc4201d2f30}] 0xc4204cc100} 0xc4200d2740}: error in registering resource: packagemanifests, unable to build openapi definitions for packages.apps.redhat.com/v1alpha1, Kind=PackageManifest: cannot find model definition for github.com/operator-framework/operator-lifecycle-manager/pkg/api/apis/operators/v1alpha1.InstallMode. If you added a new type, you may need to add +k8s:openapi-gen=true to the package or type and run code-gen again"
I don't understand what's missing since the codegen was done.

time="2019-02-08T13:39:46Z" level=fatal msg="unable to setup API &{[packages.apps.redhat.com/v1alpha1] map[v1alpha1:map[packagemanifests:0xc420705bc0]] v1 0xc4204de000 {0xc4204de000 [{[application/json] application/json [json] true 0xc4204cc100 0xc4204cc240 [] {} 0xc4204cc100} {[application/yaml] application/yaml [yaml] true 0xc4204cd040 [] } {[application/vnd.kubernetes.protobuf] application/vnd.kubernetes.protobuf [pb] false 0xc4200fce10 [] {} 0xc4201d2ea0}] 0xc420352600 [{application/json true 0xc4204cc100 0xc4204cc240 0xc4201d2f00} {application/yaml true 0xc4204cd040 } {application/vnd.kubernetes.protobuf false 0xc4200fce10 0xc4201d2f30}] 0xc4204cc100} 0xc4200d2740}: error in registering resource: packagemanifests, unable to build openapi definitions for packages.apps.redhat.com/v1alpha1, Kind=PackageManifest: cannot find model definition for github.com/operator-framework/operator-lifecycle-manager/pkg/api/apis/operators/v1alpha1.InstallMode. If you added a new type, you may need to add +k8s:openapi-gen=true to the package or type and run code-gen again"
I don't understand what's missing since the codegen was done.

Where did you find this - running the branch locally? in the pod logs for ci-operator?

I ran it locally, specifically make e2e-local TEST=TestCreateInstallPlanWithPreExistingCRDOwners (don't know if that test is specifically necessary or not) and saw the package server pod was crashing.

/retest
VPC errors...

/retest

/retest

/retest

authors: alecmerdler dinhxuanvu jpeeler njhale


text:
fix: printout errors even if we have a timeout

Signed-off-by: jesus m. rodriguez jesusr@redhat.com
Description of the change:
Handle DeadlineExceeded errors by allowing test output to be printed even during context timeouts
Motivation for the change:
context timeouts hide all test results
Fixes: #5415
Checklist
If the pull request includes user-facing changes, extra documentation is required:

[x] Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
[ ] Add or update relevant sections of the docs website in website/content/en/docs

before this change, timeout would simply result in the context error showing:
$ operator-sdk scorecard ./bundle --wait-time 5s
Error: error running tests context deadline exceeded
Usage:
  operator-sdk scorecard [flags]

Flags:
  -c, --config string            path to scorecard config file
  -h, --help                     help for scorecard
      --kubeconfig string        kubeconfig path
  -L, --list                     Option to enable listing which tests are run
  -n, --namespace string         namespace to run the test images in
  -o, --output string            Output format for results. Valid values: text, json, xunit (default "text")
  -l, --selector string          label selector to determine which tests are run
  -s, --service-account string   Service account to use for tests (default "default")
  -x, --skip-cleanup             Disable resource cleanup after tests are run
  -b, --storage-image string     Storage image to be used by the Scorecard pod (default "docker.io/library/busybox@sha256:c71cb4f7e8ececaffb34037c2637dc86820e4185100e18b4d02d613a9bd772af")
  -t, --test-output string       Test output directory. (default "test-output")
  -u, --untar-image string       Untar image to be used by the Scorecard pod (default "registry.access.redhat.com/ubi8@sha256:910f6bc0b5ae9b555eb91b88d28d568099b060088616eba2867b07ab6ea457c7")
  -w, --wait-time duration       seconds to wait for tests to complete. Example: 35s (default 30s)

Global Flags:
      --plugins strings   plugin keys to be used for this subcommand execution
      --verbose           Enable verbose logging

FATA[0005] error running tests context deadline exceeded

after this change, the test results will printout
$ operator-sdk scorecard ./bundle --wait-time 5s
--------------------------------------------------------------------------------
Image:      quay.io/operator-framework/scorecard-test:v1.18.0
Entrypoint: [scorecard-test olm-spec-descriptors]
Labels:
        "suite":"olm"
        "test":"olm-spec-descriptors-test"
Results:
        State: fail

        Errors:
                timed out waiting for the condition

--------------------------------------------------------------------------------
Image:      quay.io/operator-framework/scorecard-test:v1.18.0
Entrypoint: [scorecard-test olm-crds-have-resources]
Labels:
        "suite":"olm"
        "test":"olm-crds-have-resources-test"
Results:
        State: fail

        Errors:
                timed out waiting for the condition

--------------------------------------------------------------------------------
Image:      quay.io/operator-framework/scorecard-test:v1.18.0
Entrypoint: [scorecard-test basic-check-spec]
Labels:
        "suite":"basic"
        "test":"basic-check-spec-test"
Results:
        State: fail

        Errors:
                timed out waiting for the condition

--------------------------------------------------------------------------------
Image:      quay.io/operator-framework/scorecard-test:v1.18.0
Entrypoint: [scorecard-test olm-status-descriptors]
Labels:
        "suite":"olm"
        "test":"olm-status-descriptors-test"
Results:
        State: fail

        Errors:
                timed out waiting for the condition

--------------------------------------------------------------------------------
Image:      quay.io/operator-framework/scorecard-test:v1.18.0
Entrypoint: [scorecard-test olm-bundle-validation]
Labels:
        "suite":"olm"
        "test":"olm-bundle-validation-test"
Results:
        State: fail

        Errors:
                timed out waiting for the condition

--------------------------------------------------------------------------------
Image:      quay.io/operator-framework/scorecard-test:v1.18.0
Entrypoint: [scorecard-test olm-crds-have-validation]
Labels:
        "suite":"olm"
        "test":"olm-crds-have-validation-test"
Results:
        State: fail

        Errors:
                timed out waiting for the condition

repo: operator-framework/operator-sdk


text:
add gcc to image dependencies, so it can be used to fully run operator-sdk cli

Closes 6171

Description of the change:
Added GCC to dependencies
Motivation for the change:
operator-sdk cli is not fully functional without it with default settings if run through docker image
For more details see #6171
Checklist
If the pull request includes user-facing changes, extra documentation is required:

[ ] Add a new changelog fragment in changelog/fragments (see changelog/fragments/00-template.yaml)
[ ] Add or update relevant sections of the docs website in website/content/en/docs

Re-running the docs test as it seemed to have a link response time flake, should be good to merge once that passes. Thanks for the contribution!

externals urls in docs were timing out, it seems that they are working from my location now
/retest

authors: rccrdpccl theishshah


text:
Support more authentication options

At present, rukpak exclusively supports SSH-based authentication, as indicated in the code here: https://github.com/operator-framework/rukpak/blob/05f3afd8eb38849c830fdcc213e44c4ce0065cd4/api/v1alpha1/bundle_types.go#L134. However, this limitation may prove restrictive, particularly for scenarios that require Git-based authentication. Expanding rukpak's capabilities to encompass a broader spectrum of authentication methods, such as Kerberos, JWT, OAuth, would be helpful.

Do you want to cover container registry authentication with this issue or create a separate one for it? This is often done with a kubernetes.io/dockerconfigjson secret.

repo: operator-framework/rukpak


text:
Educational Boxes

Change logo to make bigger

Change text size and headings of box to look cleaner

repo: ophthodoc/github-slideshow

license: MIT


text:
VoucherDB edit button not needed

System -> Access ->
it does not require a edit button. It's not possible anyway to edit voucher-type.

Thanks for the suggestion, but in this case I rather leave the save action as it is, the voucher server type may receive some additional attributes later on and no button at all also raises questions...

authors: AdSchellevis DokuKaefer

repo: opnsense/core


text:
mvc: regex conditional for UnqiueConstraint to fix #6775

Solution for unique constraint extension based on addFields extension with conditional regex matching. If this works for @AdSchellevis I will add a test case as well.

@AdSchellevis if you say know I have time to rework :)

@fichtner How about changing the exclude format to something like:
<filter><subnet> /^fe[89ab][0-9a-f]:/i </subnet><interface>.*</interface></filter>
Although not totally sure what the regex for interface should be, but it would make the filters very explicit.

Conceptually the match adds the field so the regex is a conditional extension for addFields. The match should either be on the anchor element (subnet value) or the full unconditional unique key of addFields -- but the latter is hard to control with complex unique keys if that ever happens. I've tried to use XML attributes but they disappear quickly in the constraints handling. Maybe that would be the most explicit solution. Rewriting the handling for addFields would also be possible to next filters inside: field1 as general container.

The addFields construction didn’t take this kind of filters into account. I guess the issue is that in some cases you just want to exclude a specific value from the list (Stephan’s original issue if I’m not mistaken) and sometimes the constraint has a hard relationship with the fields added.
My thought was if we make the target explicit for the exclusion, it would be much easier to read. Though I am still struggling a bit with what this filter should offer, in theory for this example it should add a token (interface) for all subnets matching the regex to determine uniqueness. In which case it would be more logical if addField could contain a condition inside the same construct. I’m just not sure if this could fix the other issue as well.
Looking at the code, I think it’s more about how the user/developer should define this than what it’s currently doing (which is probably fine, just need to check if Stephan’s use-case fits as well)

Ok, Stephan’s issue was entirely different: treating a special value as the blank value (“dynamic”) in this case. We discussed it this week and the best way to avoid the problem is migrate the “dynamic” value to a blank value “” in line with the model. That makes an extension unnecessary.
What I’m trying to do is to extend the construction of the primary key based on real word condition (link-local multiple addresses allowed but need @intX appended to be unique). If it’s too special maybe better to do the model validation manually, but the unique constraint handles 80% of the code already it doesn’t make much sense not to extend it and copy+even extend it.
Yep, it’s a presentation issue first and foremost. Either we can try to allow attributes for each field or we restructure addFields to make it easier to extend:
<addField><name>interface</name><parentMatch></parentMatch></addField>
and support multiple addField nodes, maybe even in addition to keeping addFields. And I’m not tied to addField or name or parentMatch at all… whatever makes the most sense and is easy to use. 😊

That sounds good indeed, stick the field to the condition, this should be relatively easy to fix and explain.

Hmm, I can't get getOption() to deal with "array" values in XML so multiple fields of addField are flattened to the last one. I'm doubting a bit if this is all worth it. The constructor comes all the way from BaseValidator.

I'm also fine by just fixing this in the vip model, but all things considered, all of this has quite a low priority and there are not a lot of similar issues we can reuse the same construct (that I'm aware of).

Yeah, let's fix it in the model validation then.

authors: AdSchellevis fichtner


text:
Themes - Tukan/Cicada - Sensei color fixes

some color fixes for sensei

merged, thanks!

authors: fichtner opnsenseuser

repo: opnsense/plugins


text:
WOL widget fix

Hi!
fix button binding after cutting scripts from widgets
ref. https://forum.opnsense.org/index.php?topic=22202.0
closes https://github.com/opnsense/plugins/issues/2285
Thanks!

Neat, thanks a lot. Can you bump the version of the widget and remove the revision line from Makefile?

@fichtner thanks!!

Merged, thanks! ❤
I invited you into GitHub org, mainly to make issue assignment possible. We really appreciate your help. 😊

THANKS!! I'm very flattered)

authors: fichtner kulikov-a


text:
Update our debugging instructions.

This PR attempts to streamline and simplify our debugging instructions, in particular, clarifying the instructions for what to do in the event of an error in the CI checks.

Thanks @U8NWXD! Fixed, PTAL.

repo: oppia/oppia-web-developer-docs


text:
Depend only on "slf4j-api"

I think that your depending on several logging libraries is not a good thing. IMO, a clean approach would be to depend only on "slf4j-api" (and maybe one of its implementations in scope test)
The change I'm proposing might break the build (I haven't tested it) but I just wanted to bring the topic to the table. Low level libraries such as yours, should only rely on "slf4j-api". The choosing of the implementation should be is up to the integrator.
If possible, you should also get rid of commons-logging.
What do you think?

Any deletion in  is rather pointless without a corresponding deletion in  of the child modules.
Untested pull requests are not acceptable, and any solution first requires a clear problem description. We use JIRA for issues, and a mailing list for discussions (ops4j@googlegroups.com).

Thanks, @pigelvy,for your PR.
Additionally to what @hwellmann was saying (fully agree) please make the change sensible by also adjusting the bnd instructions. Just changing the dependency-section in poms (even in sub projects as Harald suggests) will probably have no or (worse) bad effects.

please change sub poms
please change bnd instructions if required.

I personally don't remember why there are many apis. I could just imagine they exist to align conflicting logging api versions from other dependencies. Just a guess. Otherwise it would never make sense. Agreed, @pigelvy .

authors: hwellmann pigelvy tonit


text:
[Helm][Add] Support for k8s affinity & tolerations / ServiceMonitor relabelings and metricRelabelings

Improved helm chart with the following:

Bumping chart/app version to 0.11.0
Added support affinity and tolerations rules
Added support for Prometheus relabeling and metric relabeling via Prometheus OP's ServiceMonitor

Hello there, @Stephan3555 @iamabhishek-dubey
I would like to know when this code will be merged after the approval.
Thank you

Can I have some feedback on this?

authors: achetronic layoaster

repo: opstree/druid-exporter


text:
Formating of shellcode?

Stupid question, what is the format of shell code required 0x00,0x00  /x00/x00 etc ?

Ignore :)

repo: optiv/Ivy


text:
Updates to WMS 4861 and 2920

WMS ID: 4861
Changes include:

Updates to instructions to reflect recent changes in environment set up
Implement and update building blocks for reuseability

WMS ID: 2920
Changes include:

Updates to Monitor lab to reflect changes in building blocks

The other is 4841
[Oracle]http://www.oracle.com/
Jenny Chan, Consulting User Assistance Developer
Oracle Database
New York
From: Ramona Magadan @.>
Sent: Thursday, April 4, 2024 6:56 AM
To: oracle-livelabs/goldengate @.>
Cc: Jenny Chan @.>; Mention @.>
Subject: [External] : Re: [oracle-livelabs/goldengate] Updates to WMS 4861 and 2920 (PR #159)
@ramonamagadan18 commented on this pull request.
Hi @jwchan0319https://urldefense.com/v3/__https:/github.com/jwchan0319__;!!ACWV5N9M2RV99hQ!KuXrgAp5tOQ1PH7kUrt5O2jpXwBp7F6gGXfFPY-BbLetlSwTor45wv9beVZesUVUBwxWlMg1kXoSRgM0DfMY4xS0tRmiezfp$, it looks like you have updated more than two workshops, can you give us the WMS ID for the workshop you updated the "ogg-to-ggs" folder?
—
Reply to this email directly, view it on GitHubhttps://urldefense.com/v3/__https:/github.com/oracle-livelabs/goldengate/pull/159*pullrequestreview-1979505271__;Iw!!ACWV5N9M2RV99hQ!KuXrgAp5tOQ1PH7kUrt5O2jpXwBp7F6gGXfFPY-BbLetlSwTor45wv9beVZesUVUBwxWlMg1kXoSRgM0DfMY4xS0tfwh8hUF$, or unsubscribehttps://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/AQ3BWUK5MYTYSZEFQEWS7L3Y3UWTVAVCNFSM6AAAAABFWCHB76VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSNZZGUYDKMRXGE__;!!ACWV5N9M2RV99hQ!KuXrgAp5tOQ1PH7kUrt5O2jpXwBp7F6gGXfFPY-BbLetlSwTor45wv9beVZesUVUBwxWlMg1kXoSRgM0DfMY4xS0tSUS4Rjm$.
You are receiving this because you were mentioned.Message ID: @.@.>>

The other is 4841

repo: oracle-livelabs/goldengate


text:
WMS ID #11658 - Protecting Oracle DB with OCI IAM Domain Radius Proxy with MFA

WMS ID #11658
General requirements

Information in the workshop is adequate and updated
Code is correct and working
Links are correct
Make sure you enter the help email link in your manifest.json
Please make sure WMS URLs are updated as needed after your PR is approved

Checklist - Refer to the QA document for the complete list
Please confirm that the following is completed before submitting your PR

[x] All filenames are lower case (including folders, images, files, etc.)
[x] Filenames are descriptive
[x] Your workshop folder structure should be similar to the one used in the sample workshop (https://github.com/oracle-livelabs/common/tree/main/sample-livelabs-templates/sample-workshop)
[x] Are you using multiple versions (desktop/, sandbox/, tenancy/)? Make sure that each of them contains a manifest.json and an index.html
[x] Image references in markdown contain an alternate text

Added some more changes, please update the same.

repo: oracle-livelabs/security


text:
Allow initial node labels

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

We would like to use advanced scheduling features such as taints/tolerations, labelled nodes etc for scheduling our pods on specific worker node pools. However, the feature to specify initial node pools seems to be commented out and not available. Can we get that feature renabled so that we can label nodes during cluster creation and then use those labels to perform automated actions for further scheduling actions?
New or Affected Resource(s)

oke node-poos
Potential Terraform Configuration

commented-out-code
# We can may be parse labels as part of below code block
dynamic "node_shape_config" {
  ....
}

References

Hi,
We haven't implemented initial node labels yet. We're happy to accept contributions.

authors: hyder liafizan


text:
fix(database): cgroup v2 compatibility

The memory check in the runOracle script takes the cgroup version into
account.
Fixes #1939
Signed-off-by: Philippe Vanhaesendonck philippe.vanhaesendonck@oracle.com

@Djelibeybi / @gvenzl
I appreciate your input on this one.
I managed to do some testing with an OL8 host with cgroup v1 and v2 and as far as I can see it works as expected.
I used memory.high rather than memory.max to keep the memory pressure reasonable.
If you think it is good to go, I'll push this fix for the other versions as well

Looks good to me.

Applied the same changes to all scripts using /sys/fs/cgroup/memory/memory.limit_in_bytes.
Ready to be merged.

Needs @psaini79 to approve for the RAC case.

Is there a chance to expedite this for Single Instance, i.e., file a PR with these changes for just the SI changes? :)

I believe we gave @psaini79 sufficient time for review. I will merge it anyway.

authors: AmedeeBulle Djelibeybi gvenzl

repo: oracle/docker-images


text:
Use the Python bindings for in-toto/attestation

We should use the in-toto-attestation package that contains Python bindings for in-toto/attestation to validate the schema.

I looked into the library and feel that it is not suitable for our use case. The library exists to properly validate an artifact's provenance, rather than to verify the validity of a given provenance file. From the website for the most relevant method:

Performs complete in-toto supply chain verification for a final product. (Source)

authors: behnazh-w benmss

repo: oracle/macaron


text:
Require JDK 11, Maven plugin and dependency versions

This change:

Requires minimum Maven (3.5.2) and JDK (11) versions
Updates Maven plugin dependencies
Updates other dependencies
Small number of Java code changes for JDK 11 (e.g. asm library)

Why the JDK11 minimum? Are we using some JDK11 features?

@russgold, this change doesn't use any specific JDK 11 features.  Once we give people time to install JDK 11 and this PR is merged, then I'm open to using such features.

Full suite clean: http://wls-jenkins.us.oracle.com/job/weblogic-kubernetes-operator-javatest/1470/

authors: rjeberhard russgold

repo: oracle/weblogic-kubernetes-operator


text:
OWLS-69370: Introspect: Domain-in-Image: Add data home override support

Provide ability to centrally override default file store, and custom file stores for both domain-home-in-image and domain-on-PV installations.
Justification:

Aligns data storage with log storage
Makes it easy to centralize data storage

Implementation:

Add dataHome to Domain CR

If not set, default to overiding as /shared/data/[domain-uid]

If setting is "", means 'don't override'.

If setting is anything else, use this specific value.

Pass through as a well known env var to introspector and to 'custom sit-config'

Have introspector override location via sit-config

Overrides both default and custom file store 'Directory' attribute

Why is there a 'docs/charts/weblogic-operator-2.3.0.tgz' in the diff? Is this expected now?

It isn't strictly needed, but I think it'd be helpful that if the the dataHome is set, then the introspector and wl-start bash scripts should try and create this directory via a 'mkdir -p', and the script should fail if the command fails.  This is user-friendly as it will cause the job/pod to 'fail fast' before WebLogic itself attempts to create the directory and fails at runtime.

I'm not familiar with web-apps, but it looks like they can persist session state to files. I'm not sure, but it looks like this is configured on weblogic.management.configuration.WebAppComponentMBean /  SessionPersistentStoreDir and on WebServiceComponentBean which inherits from WebAppComponentMBean

Thanks. Let me take a  look at the WebAppComponentMBean and WebServiceComponentBean and get an understanding if we need to address this for them too.

Why is there a 'docs/charts/weblogic-operator-2.3.0.tgz' in the diff? Is this expected now?

When looking at the develop and master branches, these files looked to be committed.

Why is there a 'docs/charts/weblogic-operator-2.3.0.tgz' in the diff? Is this expected now?

When looking at the develop and master branches, these files looked to be committed.

Still looks strange to me - I don't remember seeing that before.

2nd commit incorporates changes based on the the code review comments:

Added tests for defining a dataHome with an empty ("") path.
When dataHome is not set or is "" means means 'don't override'.
bash scripts will try and create the dataHome directory (if override path provided) via a 'mkdir -p', and the script will fail (exit) if the command fails.

Still investigating the WebAppComponentMBean and WebServiceComponentBean to determine if we need to override the persistent store directory path.

Update If not set, default to overiding as /shared/data/[domain-uid] If setting is "", means 'don't override'. in the description so that it reflects the current behavior.

I should have noticed this earlier (sorry!), but it'd be good to update the documentation so that it covers dataHome.   Look for any mention of 'logHome' and twin up a similar discussion for dataHome - for example:
$ find ./docs-source -name "*.md" | xargs grep -l logHome
./docs-source/content/userguide/managing-domains/domain-lifecycle/startup.md
./docs-source/content/userguide/managing-domains/configoverrides/_index.md
./docs-source/content/userguide/managing-domains/_index.md
./docs-source/content/samples/simple/domains/domain-home-in-image/_index.md
./docs-source/content/samples/simple/domains/fmw-domain/_index.md
./docs-source/content/samples/simple/domains/domain-home-on-pv/_index.md

Apart from the missing doc, the change LGTM.

LGTM so far apart from missing WebAppComponentMBean/WebServiceComponentBean file based session state - which I assume should be included but still needs research. If this is added, the doc for dataHome throughout will need updated too...

Queried Steven Liu for verification of File based session state persistent store configuration and there isn't any way to override the persistent store directory through any mbean configuration.  Here is Steven's reply:
Hi Lenny,
There’s no configuration on MBean to specify the persistent store directory for File persistent session data.
There are different cases for how web container determins the directory:
If there’s no <persistent-store-dir> configured in session-descriptor or the <persistent-store-dir> is configured to be relative directory, the store directory will be created under ${domain_home}/servers/${server_name}/data/ directory.
If the <persistent-store-dir> is configured to be absolute directory, the configured directory will be used for persistent store.

Hope this helps!
-Steven

On Jun 20, 2019, at 9:03 AM, Lenny Phan lenny.phan@oracle.com wrote:
Hi Steven,
I have a couple of questions but let me give some background.  We're currently making a modification for the WebLogic K8s Operator where we are centralizing
persistent store directory location for both the default and custom file stores (OWLS-69370).  Since we're allowing the K8s Domain configuration to specify
this persistent store directory location for file stores, I'm also investigating whether this location can be used if a deployed web application specifies a
persistent store type of 'file'.  Is it possible to access the configuration of the persistent store directory through a configuration mbean and modify/update
the directory location?  I see WebAppComponentMBean/WebServiceComponentBean but don't see a way to access it when looking through the config mbean tree.
If it's not possible and configuration can only be done through the weblogic session descriptor than that's ok, I'm just verifying whether or not we can
override the persistent store directory location.
Thanks!
--Lenny

From the last review from Tom Barnes, added the ability to:

Create a symbolic link from the server's domain home 'data' directory to the centralized 'data home' directory specified by the 'dataHome' attribute in the CRD.  This allows each server's data directory to be centralized.

We provide a warning description/instructions and will fail server startup if there are files in both the  server's domain home 'data' directory and the centralized data directory (specified by 'dataHome' attribute) as we have no idea which files are important to the user's or are in conflict between the two directory locations.  As per the usual WebLogic approach to these kind of issues, we ask the user's to resolve the differences before restarting the server, if they intend to centralize their server's data storage.

Provided a container/server environment variable  ('KEEP_DEFAULT_DATA_HOME') that will  bypass the server startup failure due to data files being located in both the  server's domain home 'data' directory and the centralized data directory (specified by 'dataHome' attribute).  This allows the server to continue to startup and operate and keep its domain home 'data' directory in the default location while still allowing the override of the default file and custom file stores.

NOTE: This change does not override the WLDF diagnostics store as they are not uniquely named and so cannot be centralized, whereas the default and custom file stores are uniquely named.

Overall comments:

Unfortunately, the symbolic link support still seems fragile. Maybe turn it off via an experimental flag which can be enabled via a new env var, or, if you're ambitious, via a new experimental domain resource attribute?

Overall comments:
* dataHome should be documented in docs-source - I've posted potential locations in a previous comment

* if a line of a script can fail, this needs to cause the script to log an error and fail - I've just posted comments about two such locations

* otherwise all LGTM assuming 'ad hoc' testing is all good.

* unfortunately, the symbolic link support still seems fragile. Maybe turn it off pending future hardening JIRA (via an experimental flag which can be enabled via a new env var, or, if you're ambitious, via a new experimental domain resource attribute)?  maybe it should be enabled via a separate setting?

I agree that the symbolic link support is still a little fragile.  It's mainly contained in the startServer.sh script. We could just punt on it and go back to the original intent of just supporting file stores.  That is, separate the symbolic link feature as you previously suggested.

Looks good! I added a couple minor suggestions in case you'd like to address them.

Implemented your latest suggestions. Thank you.

Well, that was long strange trip. My apologies that the soft linking idea turned into a bit of a garden path. Here's my approval good sir.

No apologies needed.  Always learn something new, especially scripting as I hardly write scripts.  Thank you for your great reviews.

authors: lennyphan tbarnes-us


text:
Add Region Code to Event Lists

Do this on the home page and the full event list

Solved in Commit 646e2c7

repo: orange-alliance/the-orange-alliance

license: mit


text:
feat: support credential function

Resolves #33

Codecov Report

Merging #45 (74687ef) into main (aead42c) will decrease coverage by 10.73%.
The diff coverage is 0.00%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main      #45       +/-   ##
===========================================
- Coverage   69.69%   58.97%   -10.73%
===========================================
  Files           1        2        +1
  Lines          33       39        +6
===========================================
  Hits           23       23
- Misses          9       15        +6
  Partials        1        1

Impacted Files
Coverage Δ

credential.go
0.00% <0.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

repo: oras-project/oras-credentials-go


text:
Fix to Performance issue of docstore #13:

This is a part of the fix for https://github.com/orbitdb/orbit-db-docstore/issues/13.
Please refer to the above link for detail.

Close this as well.

repo: orbitdb/orbit-db-docstore


text:
make clean leaves dirty package.json files

We should change make clean to not do this:
11:20 ~/src/orbitdb/orbit-db (master) * 🐕  make clean
rm -rf orbitdb/
rm -rf node_modules/
rm package-lock.json
11:20 ~/src/orbitdb/orbit-db (master) * 🐕  git k
* master
RichardLitt	git@github.com:RichardLitt/orbit-db.git (fetch)
RichardLitt	git@github.com:RichardLitt/orbit-db.git (push)
origin	git@github.com:orbitdb/orbit-db.git (fetch)
origin	git@github.com:orbitdb/orbit-db.git (push)
On branch master
Your branch is ahead of 'origin/master' by 38 commits.
  (use "git push" to publish your local commits)
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	deleted:    package-lock.json
	modified:   package.json

no changes added to commit (use "git add" and/or "git commit -a")

Tried to reproduce that from master. It did remove package-lock.json but it didn't modify package.json. BTW, should make clean remove that lockfile?

Did you run npm install first?
package-lock.json should be checked in to source control, yeah. It shouldn't be removed.

Yep. You didn't install anything, just installed dependencies, right?

Yeah. Just tried again; the only thing make clean did that it shouldn't was delete the package-lock.json file, which it oughtn't to do.

I think it does the trick: https://github.com/orbitdb/orbit-db/pull/401/files ?

The intention for removing package-lock.json in clean was to provide a way to rebuild everything from scratch since package-lock can contain binary modules that are tied to  eg. OSX. By running make clean && make devs on Linux could get everything installed as their platform requirements.
This is very valuable functionality in the dev workflow. If we want to change clean to not remove package-lock, let's make sure there's a command that replaces it. I propose moving the removal of package-lock to make rebuild command (and in rebuild, run clean as well) as then:

make clean - remove all created files from the repo (ie. reset directory state)
 make rebuild - build everything from scratch

What do you think?

That makes a lot of sense to me! Thanks for explaining that. I think we should split it out into the two commands; at the moment, make clean implies that it should clean the slate, for me, and not that it should remove package-lock.json. If there are different use cases for the different commands, I don't see a major downside for adding rebuild. Let's do it.

Iirc yarn has a different/its own lockfile. I don't feel it defeats the purpose, which is to make sure that the deps are locked to certain versions thus avoiding the problem of pulling in broken deps (this has happened several times in the past when a patch version update broke something).
It's unfortunate that native bins for different platforms are not handled that well in npm, but I'm sure they'll find a solution for it eventually.

Yarn does have it's own lockfile. I think that the multi-command solution works the best, I think.

Got it! Just for the records, I didn't mean to criticize npm :)

which is to make sure that the deps are locked to certain versions thus avoiding the problem of pulling in broken deps

I had the feeling that if the lockfile is removed, installing things from scratch could cause that. I guess it's just a matter of doing a thorough review and diffing to make sure the package-lock changes aren't committed and packages aren't updated when they shouldn't, etc :)

Believe this was fixed in #499, feel free to reopen if not :)

repo: orbitdb/orbit-db


text:
My Withdraw is Not Received

Hello dear,I send my xlm to an exchange,and I forgot to give memo .so please look at that and send me xlm.
Transaction:
36b1c96bc758db55f7dae5ec1676e111e458ca649972c5f57c5e1edb53dabcc3

I did the same thing. Did you get help yet

Same mistake I also did.

This is not the place to raise these issues. Please contact the exchange in which you sent it to, as they are the only ones who can help.

We can't help you. You need to contact the destination exchange support team and provide details required to process your deposit manually. It's impossible to change/reverse/cancel your transaction.

authors: Yhines10 fishcharlie orbitlens rajanintheus rizwanmahi

repo: orbitlens/stellar-expert-explorer


text:
ssh-agent can't be forwarded to docker

Describe the bug
When running a docker vm and passing in the SSH_AUTH_SOCK to the vm, it doesn't seem to like the current location of the ssh-agent /var/folders/....
To Reproduce
┗╸❯❯❯ eval "$(ssh-agent)"
Agent pid 88033

┏╸~
┗╸❯❯❯ echo $SSH_AUTH_SOCK
/var/folders/wy/nzgfjd_x1ns__pj6h9gx59580000gp/T//ssh-Ck9M2PbxwC5K/agent.88032

┗╸❯❯❯ docker run -it --rm \
    -v $SSH_AUTH_SOCK:/agent.sock \
    -e SSH_AUTH_SOCK=/agent.sock \
    alpine
docker: Error response from daemon: error while creating mount source path '/var/folders/wy/nzgfjd_x1ns__pj6h9gx59580000gp/T/ssh-Ck9M2PbxwC5K/agent.88032': mkdir /var/folders/wy/nzgfjd_x1ns__pj6h9gx59580000gp/T/ssh-Ck9M2PbxwC5K/agent.88032: operation not supported.

Expected behavior
I'd expect it to be able to forward the ssh-agent like the documentation states.
Diagnostic report (REQUIRED)
OrbStack info:
Version: 1.4.3
Commit: 75d38a2c2d9a2b42d64378a8f50f31d4d566df10 (v1.4.3)
System info:
macOS: 14.3.1 (23D60)
CPU: arm64, 10 cores
CPU model: Apple M2 Pro
Model: Mac14,9
Memory: 16 GiB
Full report: https://orbstack.dev/_admin/diag/orbstack-diagreport_2024-03-19T20-18-55.729365Z.zip

Screenshots and additional context (optional)
No response

$SSH_AUTH_SOCK currently only works for macOS' default ssh-agent started by launchd. This limitation will be removed by #62
Use the command @slinorb suggested for now. (Also in the docs)

repo: orbstack/orbstack


text:
Unable to start

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Logs
Attach log files by opening the OrbStack menu and clicking “Show Logs”, or email them for privacy.
Info report

<paste here>

Additional context
Add any other context about the problem here.

Please fill out the entire issue template, attach logs, and share screenshots if possible.


text:
Tree 2.0 Improvements

Hello,
We're using the Tree 2.0 and it's working well, as designed.
Nevertheless, I've thought of potential improvements:

Identify the selected item (add a class like SapUiNodeSelected)
Option to set tree expanded by default
Activate / Deactivate collapsing (if somebody wants a static menu tree).

Basically, we're using it to generate a selection menu for a portal with a viewing frame embedded.

Hi Franck,
as far small change was possible...

the selected item is already marked by UI5 class (you can see the selection) and you can overwrite it if required.
this option was possible (there is a flag for it now)
this is too difficult for this component (at least I have not found a working solution in short time frame)

Karol

authors: KarolKalisz franckblais


text:
chore: release v0.1.0-alpha.0

🤖 New release

daktilo: 0.1.0-alpha.0

Changelog

This PR was generated with release-plz.

Codecov Report
All modified lines are covered by tests :white_check_mark:
:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
:loudspeaker: Thoughts on this report? Let us know!.

authors: codecov-commenter orhun

repo: orhun/daktilo


text:
Advance query in Filter field

I remember seeing a post on "introducing the full query syntax within the filter area" like
select *, in('Discuss')[in('Started')[name ='julie']] as roomId from item

but I can't find it anymore does anyone know where I can follow the progress on this issue ?
To put my problem in context here is my example:
I am building a chat room engine and I have a graph like so:
User---Started--->Room----Discuss--->Item<---Own---User

I would like to get all the Items and the roomId associated to the Item for a particular User.
select
    *, in('Discuss').in('Started')[name ='julie'] as roomId
from item

so this is going threw the right 'Room' and finds the one started by 'Julie' but it returns Julie's Id, how do I get with this query the Id of that room ? It's like i need to do a 'one back' and get @rid...
I am new to graphs so any pointers would be appreciated.

Bretto, you shouldn't post questions here. It just adds noise and is unlikely to be answered here anyway.
Better places to ask questions

https://groups.google.com/forum/#!forum/orient-database
http://stackoverflow.com

I did,
http://stackoverflow.com/questions/30407135/query-on-orientdb-graph
https://groups.google.com/forum/#!topic/orient-database/50zN5O1glNU
still waiting ...

authors: Bretto Ziink

repo: orientechnologies/orientdb


text:
Class diagrams in Studio

Let's say that I've imported a big database and I have a lot of classes and a big hierarchy tree.
Is there a way I could see the hierarchy easily, something like UML diagram, in Studio?

Hi @warriorkitty
We did have a UML diagram in studio before, but we removed it for security reason because it used a third party service.
We could implement it in studio using some javascript library like this
http://jointjs.com/demos/umlcd

Well, that would be really great. Also, after looking at the library, I don't see the reason why I couldn't try to implement it myself and send a PR if I finish it.
Could you tell me some guidelines for this? I can't find Studio "entry" inside the source.

hi @warriorkitty
you can find the code here
https://github.com/orientechnologies/orientdb-studio
This is a javascript application (bower/grunt/angularjs)
If you are familiar with angular you can try.
You can see the old logic of the UML diagram in
UML.html and UMLController in configuration-controller.js
If you have problem you can ask me

Thank you. I'll need some time but I'll try it. :)

There is a built in ability to view UML in Orienteer. Just check demo: select required classes and click "View UML". Service PlantUML which can be installed locally as embedded.

@PhantomYdn - looking at the demo, every record view ends in a null pointer exception. The demo is broken.
Scott

Thanks! Demo is open for everyone, so someone changed super-dashboard for all documents. Temporary fixed, but yea: it should not collapse with NPE.

Thanks for the fix. An automated daily reset of the demo database might help avoid that, at least from one day to the next.
Scott

@PhantomYdn Looks great, thank you. I will re-check why it didn't work on my iPad (maybe I just need to clear the cache). Works great in Firefox.
@maggiolo00 I will close this issue for now and I will contact you again if I implement something similar in Studio.

I'd like to reopen it, so if @warriorkitty or somebody else want to contribute with such new component, it could go as enhancement under this issue. The basic rule for a component to be quickly accepted by OrientDB team is:

don't include sw not compatible with Apache2 license
don't add dependencies unless is very very necessary

Nobody worked on this. Not relevant anymore, closing it.

Hello,
We are in Orienteer (http://orienteer.org) are working on some solution for visual modeling of data models. Once our system is working on OrientDB: it can be used also for dedicated modeling as well.
Our module Orienteer-Architect can be found here: https://github.com/OrienteerBAP/Orienteer
Please find some screenshot below.

authors: PhantomYdn lvca maggiolo00 smolinari warriorkitty