[question] What should I do when there is no report data?

The problem is that when I run curl --insecure -H "Authorization: Bearer ${token}" "https://${meteringRoute}/api/v1/reports/get?name=${reportName}&namespace=metering&format=$reportFormat", I got no data after this.
The target I want is that I can see the report data with the command curl --insecure -H "Authorization: Bearer ${token}" "https://${meteringRoute}/api/v1/reports/get?name=${reportName}&namespace=metering&format=$reportFormat"

The steps and info:

I created a report named namespace-cpu-request, and it status is finished.

[root@openstack-ipi metering-operator]# oc get report
NAME                    QUERY                   SCHEDULE   RUNNING    FAILED   LAST REPORT TIME       AGE
namespace-cpu-request   namespace-cpu-request              Finished            2020-08-11T00:00:00Z   89m

there is the describe about my report namespace-cpu-request

[root@openstack-ipi metering-operator]# oc describe report namespace-cpu-request
Name:         namespace-cpu-request
Namespace:    metering
Labels:       <none>
Annotations:  <none>
API Version:  metering.openshift.io/v1
Kind:         Report
Metadata:
  Creation Timestamp:  2020-08-10T07:35:59Z
  Generation:          4
  Resource Version:    9822237
  Self Link:           /apis/metering.openshift.io/v1/namespaces/metering/reports/namespace-cpu-request
  UID:                 944c8aa6-f2dc-44aa-9af8-bfb074d0ed2c
Spec:
  Query:            namespace-cpu-request
  Reporting End:    2020-08-11T00:00:00Z
  Reporting Start:  2020-08-10T00:00:00Z
  Run Immediately:  true
Status:
  Conditions:
    Last Transition Time:  2020-08-10T07:36:12Z
    Last Update Time:      2020-08-10T07:36:12Z
    Message:               Report has finished reporting. Report has reached the configured spec.reportingEnd: 2020-08-11 00:00:00 +0000 UTC
    Reason:                Finished
    Status:                False
    Type:                  Running
  Last Report Time:        2020-08-11T00:00:00Z
  Table Ref:
    Name:  report-metering-namespace-cpu-request
Events:    <none>

after set the correct meteringRoute, eportName=namespace-cpu-request, reportFormat=csv, curl the url but got no data

[root@openstack-ipi metering-operator]# curl --insecure -H "Authorization: Bearer ${token}" "https://${meteringRoute}/api/v1/reports/get?name=${reportName}&namespace=metering&format=$reportFormat"
[root@openstack-ipi metering-operator]#

the other info I think not correct is there are many blanks with the kubectl get reportdatasources, the result is different with https://github.com/kube-reporting/metering-operator/blob/master/Documentation/install-metering.md#verifying-operation:

[root@openstack-ipi metering-operator]# kubectl get reportdatasources -n $METERING_NAMESPACE | grep -v raw
NAME                                         EARLIEST METRIC   NEWEST METRIC   IMPORT START   IMPORT END   LAST IMPORT TIME   AGE
node-allocatable-cpu-cores                                                                                6d5h
node-allocatable-memory-bytes                                                                                6d5h
node-capacity-cpu-cores                                                                                6d5h
node-capacity-memory-bytes                                                                                6d5h
persistentvolumeclaim-capacity-bytes                                                                                6d5h
persistentvolumeclaim-phase                                                                                6d5h
persistentvolumeclaim-request-bytes                                                                                6d5h
persistentvolumeclaim-usage-bytes                                                                                6d5h
pod-limit-cpu-cores                                                                                6d5h
pod-limit-memory-bytes                                                                                6d5h
pod-persistentvolumeclaim-request-info                                                                                6d5h
pod-request-cpu-cores                                                                                6d5h
pod-request-memory-bytes                                                                                6d5h
pod-usage-cpu-cores                                                                                6d5h
pod-usage-memory-bytes                                                                                6d5h
report-namespace-cpu-request                                                                                93m

Dear friends, for the above 3 and 4 issues, could you help me to correct them?

@xkwangcn If none of the custom columns are getting populated when you look at that ReportDataSource output, it most likely points to an issue where metering can't correctly import data from Prometheus, or it cannot store that imported data into Hive/Presto database tables. I would poke around the reporting-operator container logs for more information, but another quick debugging check if checking if the StorageLocation custom resource's .Status field has been populated with a database location. You can do that by running the following command:
$ kubectl get storagelocation -o yaml
...

@timflannagan1 Thanks for you reply.
there is the yaml contents of storagelocation, is there some useful infomation?
[root@bastion ~]# kubectl get storagelocation -o yaml
apiVersion: v1
items:
- apiVersion: metering.openshift.io/v1
  kind: StorageLocation
  metadata:
    annotations:
      storagelocation.metering.openshift.io/is-default: "true"
    creationTimestamp: "2020-08-10T06:39:56Z"
    generation: 1
    labels:
      metering.openshift.io/ns-prune: metering
      metering.openshift.io/prune: openshift-metering-default-storage-location
      operator-metering: "true"
    name: hive
    namespace: metering
    ownerReferences:
    - apiVersion: metering.openshift.io/v1
      kind: MeteringConfig
      name: operator-metering
      uid: 1de5b37e-dad3-11ea-b156-d2067f089d1c
    resourceVersion: "73794683"
    selfLink: /apis/metering.openshift.io/v1/namespaces/metering/storagelocations/hive
    uid: 4e10da53-dad4-11ea-a790-025539722618
  spec:
    hive:
      databaseName: metering
      unmanagedDatabase: false
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

there is a part of the log about reporting-operator：
[root@openstack-ipi ~]# oc logs reporting-operator-74d545cc9-jrj7n -c reporting-operator
time="2020-08-10T14:25:54Z" level=info msg="syncing ReportDataSource metering/pod-request-memory-bytes" app=metering component=reportDataSourceWorker logID=Y2SJyc6CKE
time="2020-08-10T14:25:54Z" level=info msg="existing Prometheus ReportDataSource discovered, tableName: hive.metering.datasource_metering_pod_request_memory_bytes" app=metering component=reportDataSourceWorker logID=Y2SJyc6CKE namespace=metering reportDataSource=pod-request-memory-bytes
time="2020-08-10T14:25:55Z" level=error msg="error collecting metrics" app=metering chunkSize=5m0s component=PrometheusImporter endTime="2020-08-10 14:25:24.866301506 +0000 UTC" error="failed to perform Prometheus query: Get https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query_range?end=2020-08-10T12%3A30%3A00Z&query=kubelet_volume_stats_used_bytes%0A&start=2020-08-10T12%3A25%3A00Z&step=60.000: dial tcp <IP_ADDRESS>:9091: i/o timeout" logID=ZrVq34bAk2 namespace=metering reportDataSource=persistentvolumeclaim-usage-bytes startTime="2020-08-10 12:25:24.866301506 +0000 UTC" stepSize=1m0s tableName=hive.metering.datasource_metering_persistentvolumeclaim_usage_bytes
time="2020-08-10T14:25:55Z" level=error msg="error syncing ReportDataSource \"metering/persistentvolumeclaim-usage-bytes\", adding back to queue" ReportDataSource=metering/persistentvolumeclaim-usage-bytes app=metering component=reportDataSourceWorker error="ImportFromLastTimestamp errored: failed to perform Prometheus query: Get https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query_range?end=2020-08-10T12%3A30%3A00Z&query=kubelet_volume_stats_used_bytes%0A&start=2020-08-10T12%3A25%3A00Z&step=60.000: dial tcp <IP_ADDRESS>:9091: i/o timeout" logID=LDtabTp5qp
time="2020-08-10T14:25:55Z" level=info msg="Event(v1.ObjectReference{Kind:\"ReportDataSource\", Namespace:\"metering\", Name:\"persistentvolumeclaim-usage-bytes\", UID:\"d1c4d1f3-fa14-43ff-9edb-8c58be1a1c3e\", APIVersion:\"metering.openshift.io/v1\", ResourceVersion:\"7999276\", FieldPath:\"\"}): type: 'Warning' reason: 'FailedPrometheusQuery' Unable to import metrics after Prometheus query failure. Check the reporting-operator container logs for more information." app=metering
time="2020-08-10T14:25:55Z" level=info msg="no data in table hive.metering.datasource_metering_pod_request_memory_bytes: backfilling from 2020-08-10 12:25:54.98032587 +0000 UTC until 2020-08-10 14:25:54.98032587 +0000 UTC" app=metering chunkSize=5m0s component=PrometheusImporter logID=jVEHNRGh3V namespace=metering reportDataSource=pod-request-memory-bytes stepSize=1m0s tableName=hive.metering.datasource_metering_pod_request_memory_bytes
time="2020-08-10T14:25:55Z" level=warning msg="time range 2020-08-10 12:25:54.98032587 +0000 UTC to 2020-08-10 14:25:54.98032587 +0000 UTC exceeds PrometheusImporter MaxQueryRangeDuration 10m0s, newEndTime: 2020-08-10 12:35:54.98032587 +0000 UTC" app=metering chunkSize=5m0s component=PrometheusImporter logID=jVEHNRGh3V namespace=metering reportDataSource=pod-request-memory-bytes stepSize=1m0s tableName=hive.metering.datasource_metering_pod_request_memory_bytes
time="2020-08-10T14:26:05Z" level=info msg="syncing ReportDataSource metering/pod-persistentvolumeclaim-request-info" app=metering component=reportDataSourceWorker logID=KbYSrZkJOT
time="2020-08-10T14:26:05Z" level=info msg="existing Prometheus ReportDataSource discovered, tableName: hive.metering.datasource_metering_pod_persistentvolumeclaim_request_info" app=metering component=reportDataSourceWorker logID=KbYSrZkJOT namespace=metering reportDataSource=pod-persistentvolumeclaim-request-info
time="2020-08-10T14:26:05Z" level=info msg="no data in table hive.metering.datasource_metering_pod_persistentvolumeclaim_request_info: backfilling from 2020-08-10 12:26:05.78672582 +0000 UTC until 2020-08-10 14:26:05.78672582 +0000 UTC" app=metering chunkSize=5m0s component=PrometheusImporter logID=Bgovz82EgF namespace=metering reportDataSource=pod-persistentvolumeclaim-request-info stepSize=1m0s tableName=hive.metering.datasource_metering_pod_persistentvolumeclaim_request_info
time="2020-08-10T14:26:05Z" level=warning msg="time range 2020-08-10 12:26:05.78672582 +0000 UTC to 2020-08-10 14:26:05.78672582 +0000 UTC exceeds PrometheusImporter MaxQueryRangeDuration 10m0s, newEndTime: 2020-08-10 12:36:05.78672582 +0000 UTC" app=metering chunkSize=5m0s component=PrometheusImporter logID=Bgovz82EgF namespace=metering reportDataSource=pod-persistentvolumeclaim-request-info stepSize=1m0s tableName=hive.metering.datasource_metering_pod_persistentvolumeclaim_request_info
time="2020-08-10T14:26:17Z" level=info msg="\"GET http://<IP_ADDRESS>:8081/healthy HTTP/1.1\" from <IP_ADDRESS>:58398 - 200 30B in 43.212288ms" app=metering component=api
time="2020-08-10T14:26:24Z" level=error msg="error collecting metrics" app=metering chunkSize=5m0s component=PrometheusImporter endTime="2020-08-10 14:25:54.537857123 +0000 UTC" error="failed to perform Prometheus query: Get https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query_range?end=2020-08-10T12%3A30%3A00Z&query=kube_node_status_allocatable_cpu_cores+%2A+on%28node%29+group_left%28provider_id%29+max%28kube_node_info%29+by+%28node%2C+provider_id%29%0A&start=2020-08-10T12%3A25%3A00Z&step=60.000: dial tcp <IP_ADDRESS>:9091: i/o timeout" logID=YjkfcMSrDt namespace=metering reportDataSource=node-allocatable-cpu-cores startTime="2020-08-10 12:25:54.537857123 +0000 UTC" stepSize=1m0s tableName=hive.metering.datasource_metering_node_allocatable_cpu_cores
time="2020-08-10T14:26:24Z" level=error msg="error syncing ReportDataSource \"metering/node-allocatable-cpu-cores\", adding back to queue" ReportDataSource=metering/node-allocatable-cpu-cores app=metering component=reportDataSourceWorker error="ImportFromLastTimestamp errored: failed to perform Prometheus query: Get https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query_range?end=2020-08-10T12%3A30%3A00Z&query=kube_node_status_allocatable_cpu_cores+%2A+on%28node%29+group_left%28provider_id%29+max%28kube_node_info%29+by+%28node%2C+provider_id%29%0A&start=2020-08-10T12%3A25%3A00Z&step=60.000: dial tcp <IP_ADDRESS>:9091: i/o timeout" logID=9IrpmHeyNw
time="2020-08-10T14:26:24Z" level=info msg="Event(v1.ObjectReference{Kind:\"ReportDataSource\", Namespace:\"metering\", Name:\"node-allocatable-cpu-cores\", UID:\"030fe380-27b0-4ad2-8d49-cbe63336872a\", APIVersion:\"metering.openshift.io/v1\", ResourceVersion:\"7999269\", FieldPath:\"\"}): type: 'Warning' reason: 'FailedPrometheusQuery' Unable to import metrics after Prometheus query failure. Check the reporting-operator container logs for more information."  Check the reporting-operator container logs for more information."  Check the reporting-operator container logs for more information." app=metering

If the status field hasn't been populated, then we can assume that the Hive database hasn't been established, which helps explain why you're not seeing any metrics being imported from Prometheus to those corresponding database tables. Regarding those reporting-operator container logs you pasted, it looks there are some potential problems with the reporting-operator to Prometheus connection that's causing an i/o timeout. What environment are you running this in (I gather Openshift based on those logs)? It looks like you deployed a real recent version of metering as that event logging wasn't added until the last couple of weeks.

@xkwangcn Also, not entirely up-to-date on the Openstack IPI experience, so I would double-check we're not seeing those dial tcp i/o timeout errors propagate to the Pods in the openshift-monitoring namespace as that would help rule out something that's problematic with Prometheus vs. something that's problematic with metering.

@timflannagan1 Thank you very much, it's helpful to me.
My environment is the openshift 4.4 - CRC: https://developers.redhat.com/blog/2019/09/05/red-hat-openshift-4-on-your-laptop-introducing-red-hat-codeready-containers/
The metering code branch is release-4.7(or master code, I am not very sure)
Three months ago, I install metering on openshift 4 - CRC environment, it could get the data from report. Is the problem related metering versions? or Openshift version?
Is "the Hive database hasn't been established" the mainly reason? for hive database, is there a method to debug the real reason in my environment?

Ah gotcha, that helps. I haven't tried using the 4.4.x CRC version, but I'm played around with the 4.5 version. Have you double-checked that the prometheus-k8s and cluster-monitoring operators have enabled? Also, can you paste the MeteringConfig custom resource you used to deploy metering?
CC @bentito who is more familiar with CRC and may be able to help you further debug any issues.

@xkwangcn yep I have Metering working on CRC. Here's a gist with some notes, as @timflannagan1 said, verify the needed operators are enabled: https://gist.github.com/bentito/67e6128f6488949c1bc90b032afbfedd
Also, I've had success with:
crc version
CodeReady Containers version: 1.13.0+8070bae
OpenShift version: 4.5.1 (embedded in binary)

Which I believe is one off the most recent. So you might try an upgrade if it's not too disruptive to your workflow.

@timflannagan1 @bentito Thank you very much.
As far as I know, on CRC 4.3, we need to enable the prometheus-k8s and cluster-monitoring operators manually.
But on CRC 4.4, according to oc get co, it seems the ClusterOperator including monitoring, so I didn't enabled them manually.
[root@openstack-ipi metering-operator]# oc get co
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.4.8     True        False         False      52d
cloud-credential                           4.4.8     True        False         False      52d
cluster-autoscaler                         4.4.8     True        False         False      52d
console                                    4.4.8     True        False         False      52d
csi-snapshot-controller                    4.4.8     True        False         False      52d
dns                                        4.4.8     True        False         False      34d
etcd                                       4.4.8     True        False         False      52d
image-registry                             4.4.8     True        False         False      52d
ingress                                    4.4.8     True        False         False      52d
insights                                   4.4.8     True        False         False      52d
kube-apiserver                             4.4.8     True        False         False      52d
kube-controller-manager                    4.4.8     True        False         False      52d
kube-scheduler                             4.4.8     True        False         False      52d
kube-storage-version-migrator              4.4.8     True        False         False      52d
machine-api                                4.4.8     True        False         False      52d
machine-config                             4.4.8     True        False         False      52d
marketplace                                4.4.8     True        False         False      34d
monitoring                                 4.4.8     True        False         False      52d
network                                    4.4.8     True        False         False      52d
node-tuning                                4.4.8     True        False         False      52d
openshift-apiserver                        4.4.8     True        False         False      22d
openshift-controller-manager               4.4.8     True        False         False      4d7h
openshift-samples                          4.4.8     True        False         False      52d
operator-lifecycle-manager                 4.4.8     True        False         False      52d
operator-lifecycle-manager-catalog         4.4.8     True        False         False      52d
operator-lifecycle-manager-packageserver   4.4.8     True        False         False      2d19h
service-ca                                 4.4.8     True        False         False      52d
service-catalog-apiserver                  4.4.8     True        False         False      52d
service-catalog-controller-manager         4.4.8     True        False         False      52d
storage                                    4.4.8     True        False         False      52d

[root@openstack-ipi metering-operator]# oc get clusterversion version -ojsonpath='{range .spec.overrides[*]}{.name}{"\n"}{end}' | nl -v 0
     0	cluster-monitoring-operator
     1	machine-config-operator
     2	etcd-quorum-guard
     3	machine-api-operator
     4	cluster-autoscaler-operator
     5	insights-operator
     6	prometheus-k8s
     7	cloud-credential-operator
     8	csi-snapshot-controller-operator
     9	cluster-storage-operator
    10	kube-storage-version-migrator-operator

This is my meteringconfig file:
[root@openstack-ipi metering-operator]# cat manifests/deploy/openshift/metering-ansible-operator/meteringconfig.yaml
apiVersion: metering.openshift.io/v1
kind: MeteringConfig
metadata:
  name: operator-metering
spec:
  storage:
    type: "hive"
    hive:
      type: "sharedPVC"
      sharedPVC:
        claimName: "metering-nfs"

Anyway, I will upgrade my CRC version, and to check these logs again.
Thanks for your help.

@xkwangcn Yeah I've seen similar output when inspecting the co CR when nothing disabled by default, has been enabled, and I've just typically ignored that information after poking around the openshift-monitoring namespace and not seeing any of the relevant Pods come up. I'm not entirely sure if you need to explicitly enable cluster-monitoring, but you need to enable the prometheus-k8s operator at the very least and point metering to use that service DNS (as we default to using the thanos-querier service which cluster-monitoring spins up) in the MeteringConfig CR.

I'm upgrading to 1.14 of crc so thought I'd post steps and output as I go:
Right after initial crc start:
crc-macos-1.14.0-amd64  $ oc get co
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.5.4     True        False         False      14d
cloud-credential                           4.5.4     True        False         False      14d
cluster-autoscaler                         4.5.4     True        False         False      14d
config-operator                            4.5.4     True        False         False      14d
console                                    4.5.4     True        False         False      14d
csi-snapshot-controller                    4.5.4     True        False         False      14d
dns                                        4.5.4     True        False         False      3m5s
etcd                                       4.5.4     True        False         False      14d
image-registry                             4.5.4     True        False         False      14d
ingress                                    4.5.4     True        False         False      14d
insights                                   4.5.4     True        False         False      14d
kube-apiserver                             4.5.4     True        False         False      14d
kube-controller-manager                    4.5.4     True        False         False      14d
kube-scheduler                             4.5.4     True        False         False      14d
kube-storage-version-migrator              4.5.4     True        False         False      14d
machine-api                                4.5.4     True        False         False      14d
machine-approver                           4.5.4     True        False         False      14d
machine-config                             4.5.4     True        False         False      14d
marketplace                                4.5.4     True        False         False      2m33s
monitoring                                 4.5.4     True        False         False      14d
network                                    4.5.4     True        False         False      14d
node-tuning                                4.5.4     True        False         False      14d
openshift-apiserver                        4.5.4     True        False         False      14d
openshift-controller-manager               4.5.4     True        False         False      14d
openshift-samples                          4.5.4     True        False         False      14d
operator-lifecycle-manager                 4.5.4     True        False         False      14d
operator-lifecycle-manager-catalog         4.5.4     True        False         False      14d
operator-lifecycle-manager-packageserver   4.5.4     True        False         False      14d
service-ca                                 4.5.4     True        False         False      14d
storage                                    4.5.4     True        False         False      14d

Then after patch adding the three cluster operators mentioned in my gist:
oc get co
NAME                                       VERSION   AVAILABLE   PROGRESSING   DEGRADED   SINCE
authentication                             4.5.4     True        False         False      14d
cloud-credential                           4.5.4     True        False         False      14d
cluster-autoscaler                         4.5.4     True        False         False      14d
config-operator                            4.5.4     True        False         False      14d
console                                    4.5.4     True        False         False      14d
csi-snapshot-controller                    4.5.4     True        False         False      14d
dns                                        4.5.4     True        False         False      6m30s
etcd                                       4.5.4     True        False         False      14d
image-registry                             4.5.4     True        False         False      14d
ingress                                    4.5.4     True        False         False      14d
insights                                   4.5.4     True        False         False      14d
kube-apiserver                             4.5.4     True        False         False      14d
kube-controller-manager                    4.5.4     True        False         False      14d
kube-scheduler                             4.5.4     True        False         False      14d
kube-storage-version-migrator              4.5.4     True        False         False      14d
machine-api                                4.5.4     True        False         False      14d
machine-approver                           4.5.4     True        False         False      14d
machine-config                             4.5.4     True        False         False      14d
marketplace                                4.5.4     True        False         False      5m58s
monitoring                                 4.5.4     True        False         False      14d
network                                    4.5.4     True        False         False      14d
node-tuning                                4.5.4     True        False         False      14d
openshift-apiserver                        4.5.4     True        False         False      14d
openshift-controller-manager               4.5.4     True        False         False      14d
openshift-samples                          4.5.4     True        False         False      14d
operator-lifecycle-manager                 4.5.4     True        False         False      14d
operator-lifecycle-manager-catalog         4.5.4     True        False         False      14d
operator-lifecycle-manager-packageserver   4.5.4     True        False         False      14d
service-ca                                 4.5.4     True        False         False      14d
storage                                    4.5.4     True        False         False      14d

So it seems like the same list and that's not a good way to tell.

Then I am working with a good metering CR:
cat $METERING_CR_FILE
apiVersion: metering.openshift.io/v1
kind: MeteringConfig
metadata:
  name: "operator-metering"
  annotations:
    "ansible.operator-sdk/verbosity": "1"
spec:
  storage:
    type: "hive"
    hive:
      type: "sharedPVC"
      sharedPVC:
        createPVC: true
        storageClass: " "
        size: 25Gi

It's a bit odd, probably using a bug, but it works like a charm for CRC.

With METERING_CR_FILE pointed at that file, I install metering using the manual deploy tool:
make bin/deploy-metering
bin/deploy-metering install

and all running pods in about 5 minutes:

And the reportdatasources are filling up:

@timflannagan1 @bentito Thank you for your patient reply, it is very detailed and helpful to me.
I checked my environment and found there is no pod in openshift-monitoring namespace:
[root@openstack-ipi metering-operator]# oc get all -n openshift-monitoring
NAME                                  TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                      AGE
service/alertmanager-main             ClusterIP   <IP_ADDRESS>    <none>        9094/TCP                     54d
service/alertmanager-operated         ClusterIP   None             <none>        9093/TCP,9094/TCP,9094/UDP   54d
service/cluster-monitoring-operator   ClusterIP   None             <none>        8080/TCP                     54d
service/grafana                       ClusterIP   <IP_ADDRESS>    <none>        3000/TCP                     54d
service/kube-state-metrics            ClusterIP   None             <none>        8443/TCP,9443/TCP            54d
service/node-exporter                 ClusterIP   None             <none>        9100/TCP                     54d
service/openshift-state-metrics       ClusterIP   None             <none>        8443/TCP,9443/TCP            54d
service/prometheus-adapter            ClusterIP   <IP_ADDRESS>     <none>        443/TCP                      54d
service/prometheus-k8s                ClusterIP   <IP_ADDRESS>   <none>        9091/TCP,9092/TCP            54d
service/prometheus-operated           ClusterIP   None             <none>        9090/TCP,10901/TCP           54d
service/prometheus-operator           ClusterIP   None             <none>        8080/TCP                     54d
service/telemeter-client              ClusterIP   None             <none>        8443/TCP                     54d
service/thanos-querier                ClusterIP   <IP_ADDRESS>   <none>        9091/TCP,9092/TCP            54d

NAME                                         HOST/PORT                                                 PATH   SERVICES            PORT    TERMINATION          WILDCARD
route.route.openshift.io/alertmanager-main   alertmanager-main-openshift-monitoring.apps-crc.testing          alertmanager-main   web     reencrypt/Redirect   None
route.route.openshift.io/grafana             grafana-openshift-monitoring.apps-crc.testing                    grafana             https   reencrypt/Redirect   None
route.route.openshift.io/prometheus-k8s      prometheus-k8s-openshift-monitoring.apps-crc.testing             prometheus-k8s      web     reencrypt/Redirect   None
route.route.openshift.io/thanos-querier      thanos-querier-openshift-monitoring.apps-crc.testing             thanos-querier      web     reencrypt/Redirect   None

But could you tell me how to enable the prometheus-k8s operator? I tried the command and got some errors:
[root@openstack-ipi metering-operator]# oc scale --replicas=1 statefulset --all -n openshift-monitoring; oc scale --replicas=1 deployment --all -n openshift-monitoring
error: no objects passed to scale
error: no objects passed to scale

Another question is what oc patch clusterversion/version --type='json' -p '[{"op":"remove", "path":"/spec/overrides/2"}]' -oyaml mean? I run it and got the following result:
[root@openstack-ipi metering-operator]# oc patch clusterversion/version --type='json' -p '[{"op":"remove", "path":"/spec/overrides/2"}]' -oyaml
apiVersion: config.openshift.io/v1
kind: ClusterVersion
metadata:
  creationTimestamp: "2020-06-20T06:57:32Z"
  generation: 8
  name: version
  resourceVersion: "10729305"
  selfLink: /apis/config.openshift.io/v1/clusterversions/version
  uid: ea63250c-ba62-43f7-92ce-441fff7a2cd5
spec:
  channel: stable-4.4
  clusterID: f74f375c-92a1-4df0-b4f7-2ece81a18b15
  overrides:
  - group: apps/v1
    kind: Deployment
    name: cluster-monitoring-operator
    namespace: openshift-monitoring
    unmanaged: true
  - group: apps/v1
    kind: Deployment
    name: machine-config-operator
    namespace: openshift-machine-config-operator
    unmanaged: true
  - group: apps/v1
    kind: Deployment
    name: prometheus-k8s
    namespace: openshift-cloud-credential-operator
    unmanaged: true
  - group: apps/v1
    kind: Deployment
    name: cloud-credential-operator
    namespace: openshift-cloud-credential-operator
    unmanaged: true
  - group: apps/v1
    kind: Deployment
    name: csi-snapshot-controller-operator
    namespace: openshift-cluster-storage-operator
    unmanaged: true
  - group: apps/v1
    kind: Deployment
    name: cluster-storage-operator
    namespace: openshift-cluster-storage-operator
    unmanaged: true
  - group: apps/v1
    kind: Deployment
    name: kube-storage-version-migrator-operator
    namespace: openshift-kube-storage-version-migrator-operator
    unmanaged: true
  upstream: https://api.openshift.com/api/upgrades_info/v1/graph
status:
  availableUpdates:
  - force: false
    image: quay.io/openshift-release-dev/ocp-release@sha256:bf373a678979c1bf09069eb34f51e8c8180ef3488a8f6d915a99047320e81c24
    version: 4.4.11
  - force: false
    image: quay.io/openshift-release-dev/ocp-release@sha256:2e4bbcf4dff0857bec6328c77d3a0480c1ae6778d48c7fba197f54a3e1912c72
    version: 4.4.12
  - force: false
    image: quay.io/openshift-release-dev/ocp-release@sha256:15280aba8f1c82fe39180a617e3b4886401f6c2aef63c7962203aa10530d1db8
    version: 4.4.9
  - force: false
    image: quay.io/openshift-release-dev/ocp-release@sha256:74b5cefea8c8bac158468458dbcb0fdb213aafdcf5b11c9aaefc75e2f7b9fe96
    version: 4.4.16
  - force: false
    image: quay.io/openshift-release-dev/ocp-release@sha256:cf3f799779fb0646c43dd16d376bf67fddd29597009d21223f956f5dd7a4c02f
    version: 4.4.15
  - force: false
    image: quay.io/openshift-release-dev/ocp-release@sha256:83ac468a022d681475f3016858de4bc917c2ea214bee395f8f4210f4784aafd7
    version: 4.4.14
  - force: false
    image: quay.io/openshift-release-dev/ocp-release@sha256:0d1ffca302ae55d32574b38438c148d33c2a8a05c8daf97eeb13e9ab948174f7
    version: 4.4.10
  - force: false
    image: quay.io/openshift-release-dev/ocp-release@sha256:1b15aef0cf352b49be0b22f273663719dfdc111737e58a9080595623e47d7dd8
    version: 4.4.13
  conditions:
  - lastTransitionTime: "2020-06-20T07:31:00Z"
    message: Done applying 4.4.8
    status: "True"
    type: Available
  - lastTransitionTime: "2020-06-20T07:25:30Z"
    status: "False"
    type: Failing
  - lastTransitionTime: "2020-08-13T08:44:57Z"
    message: Cluster version is 4.4.8
    status: "False"
    type: Progressing
  - lastTransitionTime: "2020-08-12T09:35:36Z"
    status: "True"
    type: RetrievedUpdates
  - lastTransitionTime: "2020-06-20T07:03:50Z"
    message: 'Cluster cannot be upgraded for multiple reasons: UnsupportedConfigOverrides_UnsupportedConfigOverridesSet,ClusterVersionOverridesSet'
    reason: MultipleReasons
    status: "False"
    type: Upgradeable
  - lastTransitionTime: "2020-06-20T07:39:01Z"
    message: 'Cluster operator etcd cannot be upgraded: UnsupportedConfigOverridesUpgradeable:
      setting: [useUnsupportedUnsafeNonHANonProductionUnstableEtcd]'
    reason: UnsupportedConfigOverrides_UnsupportedConfigOverridesSet
    status: "False"
    type: UpgradeableClusterOperators
  - lastTransitionTime: "2020-06-20T07:39:01Z"
    message: Disabling ownership via cluster version overrides prevents upgrades.
      Please remove overrides before continuing.
    reason: ClusterVersionOverridesSet
    status: "False"
    type: UpgradeableClusterVersionOverrides
  desired:
    force: false
    image: quay.io/openshift-release-dev/ocp-release@sha256:26760772b0128f11b3c3c13eeebf1238cf9b86ea5377808febdd14d4d00a2c31
    version: 4.4.8
  history:
  - completionTime: "2020-06-20T07:31:00Z"
    image: quay.io/openshift-release-dev/ocp-release@sha256:26760772b0128f11b3c3c13eeebf1238cf9b86ea5377808febdd14d4d00a2c31
    startedTime: "2020-06-20T06:57:32Z"
    state: Completed
    verified: false
    version: 4.4.8
  observedGeneration: 7
  versionHash: NDhxuKfI-gQ=

Hi @xkwangcn yep, you use the patch command to enable any of those cluster operators that are disabled by default, including Prometheus. So you need to run the command:
oc get clusterversion version -ojsonpath='{range .spec.overrides[*]}{.name}{"\n"}{end}' | nl -v 0

Then run the oc patch... command using the number shown of Prometheus. When you run the above command again Prometheus will be gone because it is no longer disabled, and depending on order, remaining cluster operators may be renumbered. It's clunky, but that's how it is done.

Hello, @bentito, I run the command refer to your above reply, it's successful to enable them.

Firstly, I see their number from:

[root@openstack-ipi metering-operator]# oc get clusterversion version -ojsonpath='{range .spec.overrides[*]}{.name}{"\n"}{end}' | nl -v 0
     0	cluster-monitoring-operator
     1	machine-config-operator
     2	etcd-quorum-guard
     3	machine-api-operator
     4	cluster-autoscaler-operator
     5	insights-operator
     6	prometheus-k8s
     7	cloud-credential-operator
     8	csi-snapshot-controller-operator
     9	cluster-storage-operator
    10	kube-storage-version-migrator-operator

Secondly,  enable prometheus-k8s, cluster-monitoring-operator, cluster-storage-operator with the correct numbe.

I learn a lot from you and know more about metering and CRC. Thanks your help.
Maybe this issue could be closed now?

@xkwangcn Awesome, yeah let's close this issue out and feel free to open any subsequent issues. Have fun with your metering and CRC adventures.

@timflannagan1 hello, I encountered a similar problem, but the reason looks different, and I need your help again☺.
The current situation is that the report can be successfully generated but got no data by "curl" command.

About versions info: I install metering 4.7 version on my Openshift 4.2 (OCP 4.2) environment.
About the report info:

[root@bastion metering-operator]# oc get report
NAME                    QUERY                   SCHEDULE   RUNNING    FAILED   LAST REPORT TIME       AGE
namespace-cpu-request   namespace-cpu-request              Finished            2020-09-09T23:59:59Z   4s
[root@bastion metering-operator]# oc describe report namespace-cpu-request
Name:         namespace-cpu-request
Namespace:    metering
Labels:       <none>
Annotations:  <none>
API Version:  metering.openshift.io/v1
Kind:         Report
Metadata:
  Creation Timestamp:  2020-09-09T01:45:43Z
  Generation:          4
  Resource Version:    99704351
  Self Link:           /apis/metering.openshift.io/v1/namespaces/metering/reports/namespace-cpu-request
  UID:                 2c830cf2-f23e-11ea-b85b-025539e47b10
Spec:
  Query:            namespace-cpu-request
  Reporting End:    2020-09-09T23:59:59Z
  Reporting Start:  2020-09-08T00:00:00Z
  Run Immediately:  true
Status:
  Conditions:
    Last Transition Time:  2020-09-09T01:45:46Z
    Last Update Time:      2020-09-09T01:45:46Z
    Message:               Report has finished reporting. Report has reached the configured spec.reportingEnd: 2020-09-09 23:59:59 +0000 UTC
    Reason:                Finished
    Status:                False
    Type:                  Running
  Last Report Time:        2020-09-09T23:59:59Z
  Table Ref:
    Name:  report-metering-namespace-cpu-request
Events:    <none>

the reportdatasources in not correct, but I don't know the reason. The OCP is different with CRC, so the monitoring is not needed enabled manually?

[root@bastion metering-operator]# kubectl get reportdatasources -n metering | grep -v raw
NAME                                         EARLIEST METRIC   NEWEST METRIC   IMPORT START   IMPORT END   LAST IMPORT TIME   AGE
node-allocatable-cpu-cores                                                                                15h
node-allocatable-memory-bytes                                                                                15h
node-capacity-cpu-cores                                                                                15h
node-capacity-memory-bytes                                                                                15h
persistentvolumeclaim-capacity-bytes                                                                                15h
persistentvolumeclaim-phase                                                                                15h
persistentvolumeclaim-request-bytes                                                                                15h
persistentvolumeclaim-usage-bytes                                                                                15h
pod-limit-cpu-cores                                                                                15h
pod-limit-memory-bytes                                                                                15h
pod-persistentvolumeclaim-request-info                                                                                15h
pod-request-cpu-cores                                                                                15h
pod-request-memory-bytes                                                                                15h
pod-usage-cpu-cores                                                                                15h
pod-usage-memory-bytes                                                                                15h
report-namespace-cpu-request                                                                                4m10s

the status value is hive: databaseName: metering, is it correct?

[root@bastion metering-operator]# kubectl get storagelocation -o yaml
apiVersion: v1
items:
- apiVersion: metering.openshift.io/v1
  kind: StorageLocation
  metadata:
    annotations:
      storagelocation.metering.openshift.io/is-default: "true"
    creationTimestamp: "2020-09-08T10:11:03Z"
    generation: 2
    labels:
      metering.openshift.io/ns-prune: metering
      metering.openshift.io/prune: openshift-metering-default-storage-location
      operator-metering: "true"
    name: hive
    namespace: metering
    ownerReferences:
    - apiVersion: metering.openshift.io/v1
      kind: MeteringConfig
      name: operator-metering
      uid: 272ee47d-f1bb-11ea-b85b-025539e47b10
    resourceVersion: "99146477"
    selfLink: /apis/metering.openshift.io/v1/namespaces/metering/storagelocations/hive
    uid: 99e39f37-f1bb-11ea-baef-025538ab22c7
  spec:
    hive:
      databaseName: metering
      unmanagedDatabase: false
  status:
    hive:
      databaseName: metering
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

The logs in reporting-operator:

time="2020-09-09T01:56:41Z" level=error msg="error syncing ReportDataSource \"metering/persistentvolumeclaim-capacity-bytes\", adding back to queue" ReportDataSource=metering/persistentvolumeclaim-capacity-bytes app=metering component=reportDataSourceWorker error="ImportFromLastTimestamp errored: failed to perform Prometheus query: Get https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query_range?end=2020-09-09T00%3A01%3A00Z&query=kubelet_volume_stats_capacity_bytes%0A&start=2020-09-08T23%3A56%3A00Z&step=60.000: dial tcp: lookup thanos-querier.openshift-monitoring.svc on <IP_ADDRESS>:53: no such host" logID=PcR8xdb1eg
time="2020-09-09T01:56:41Z" level=info msg="no data in table hive.metering.datasource_metering_node_allocatable_cpu_cores: backfilling from 2020-09-08 23:56:41.256053217 +0000 UTC until 2020-09-09 01:56:41.256053217 +0000 UTC" app=metering chunkSize=5m0s component=PrometheusImporter logID=YGq3DXjY9J namespace=metering reportDataSource=node-allocatable-cpu-cores stepSize=1m0s tableName=hive.metering.datasource_metering_node_allocatable_cpu_cores
time="2020-09-09T01:56:41Z" level=warning msg="time range 2020-09-08 23:56:41.256053217 +0000 UTC to 2020-09-09 01:56:41.256053217 +0000 UTC exceeds PrometheusImporter MaxQueryRangeDuration 10m0s, newEndTime: 2020-09-09 00:06:41.256053217 +0000 UTC" app=metering chunkSize=5m0s component=PrometheusImporter logID=YGq3DXjY9J namespace=metering reportDataSource=node-allocatable-cpu-cores stepSize=1m0s tableName=hive.metering.datasource_metering_node_allocatable_cpu_cores
time="2020-09-09T01:56:41Z" level=error msg="error collecting metrics" app=metering chunkSize=5m0s component=PrometheusImporter endTime="2020-09-09 01:56:41.256053217 +0000 UTC" error="failed to perform Prometheus query: Get https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query_range?end=2020-09-09T00%3A01%3A00Z&query=kube_node_status_allocatable_cpu_cores+%2A+on%28node%29+group_left%28provider_id%29+max%28kube_node_info%29+by+%28node%2C+provider_id%29%0A&start=2020-09-08T23%3A56%3A00Z&step=60.000: dial tcp: lookup thanos-querier.openshift-monitoring.svc on <IP_ADDRESS>:53: no such host" logID=YGq3DXjY9J namespace=metering reportDataSource=node-allocatable-cpu-cores startTime="2020-09-08 23:56:41.256053217 +0000 UTC" stepSize=1m0s tableName=hive.metering.datasource_metering_node_allocatable_cpu_cores
time="2020-09-09T01:56:41Z" level=error msg="error syncing ReportDataSource \"metering/node-allocatable-cpu-cores\", adding back to queue" ReportDataSource=metering/node-allocatable-cpu-cores app=metering component=reportDataSourceWorker error="ImportFromLastTimestamp errored: failed to perform Prometheus query: Get https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query_range?end=2020-09-09T00%3A01%3A00Z&query=kube_node_status_allocatable_cpu_cores+%2A+on%28node%29+group_left%28provider_id%29+max%28kube_node_info%29+by+%28node%2C+provider_id%29%0A&start=2020-09-08T23%3A56%3A00Z&step=60.000: dial tcp: lookup thanos-querier.openshift-monitoring.svc on <IP_ADDRESS>:53: no such host" logID=R4aEEi9J7N
time="2020-09-09T01:56:41Z" level=info msg="no data in table hive.metering.datasource_metering_pod_persistentvolumeclaim_request_info: backfilling from 2020-09-08 23:56:41.240444364 +0000 UTC until 2020-09-09 01:56:41.240444364 +0000 UTC" app=metering chunkSize=5m0s component=PrometheusImporter logID=NygESy9nG2 namespace=metering reportDataSource=pod-persistentvolumeclaim-request-info stepSize=1m0s tableName=hive.metering.datasource_metering_pod_persistentvolumeclaim_request_info
time="2020-09-09T01:56:41Z" level=warning msg="time range 2020-09-08 23:56:41.240444364 +0000 UTC to 2020-09-09 01:56:41.240444364 +0000 UTC exceeds PrometheusImporter MaxQueryRangeDuration 10m0s, newEndTime: 2020-09-09 00:06:41.240444364 +0000 UTC" app=metering chunkSize=5m0s component=PrometheusImporter logID=NygESy9nG2 namespace=metering reportDataSource=pod-persistentvolumeclaim-request-info stepSize=1m0s tableName=hive.metering.datasource_metering_pod_persistentvolumeclaim_request_info
time="2020-09-09T01:56:41Z" level=error msg="error collecting metrics" app=metering chunkSize=5m0s component=PrometheusImporter endTime="2020-09-09 01:56:41.240444364 +0000 UTC" error="failed to perform Prometheus query: Get https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query_range?end=2020-09-09T00%3A01%3A00Z&query=kube_pod_spec_volumes_persistentvolumeclaims_info%0A&start=2020-09-08T23%3A56%3A00Z&step=60.000: dial tcp: lookup thanos-querier.openshift-monitoring.svc on <IP_ADDRESS>:53: no such host" logID=NygESy9nG2 namespace=metering reportDataSource=pod-persistentvolumeclaim-request-info startTime="2020-09-08 23:56:41.240444364 +0000 UTC" stepSize=1m0s tableName=hive.metering.datasource_metering_pod_persistentvolumeclaim_request_info
time="2020-09-09T01:56:41Z" level=error msg="error syncing ReportDataSource \"metering/pod-persistentvolumeclaim-request-info\", adding back to queue" ReportDataSource=metering/pod-persistentvolumeclaim-request-info app=metering component=reportDataSourceWorker error="ImportFromLastTimestamp errored: failed to perform Prometheus query: Get https://thanos-querier.openshift-monitoring.svc:9091/api/v1/query_range?end=2020-09-09T00%3A01%3A00Z&query=kube_pod_spec_volumes_persistentvolumeclaims_info%0A&start=2020-09-08T23%3A56%3A00Z&step=60.000: dial tcp: lookup thanos-querier.openshift-monitoring.svc on <IP_ADDRESS>:53: no such host" logID=XYj5psZ0qp
time="2020-09-09T01:56:47Z" level=info msg="\"GET http://<IP_ADDRESS>:8081/ready HTTP/1.1\" from <IP_ADDRESS>:45154 - 200 30B in 23.196045ms" app=metering component=api
time="2020-09-09T01:56:50Z" level=info msg="\"GET http://<IP_ADDRESS>:8081/healthy HTTP/1.1\" from <IP_ADDRESS>:45154 - 200 30B in 16.536083ms" app=metering component=api
time="2020-09-09T01:57:47Z" level=info msg="\"GET http://<IP_ADDRESS>:8081/ready HTTP/1.1\" from <IP_ADDRESS>:45154 - 200 30B in 36.186298ms" app=metering component=api
time="2020-09-09T01:57:50Z" level=info msg="\"GET http://<IP_ADDRESS>:8081/healthy HTTP/1.1\" from <IP_ADDRESS>:45154 - 200 30B in 18.608184ms" app=metering component=api
time="2020-09-09T01:58:47Z" level=info msg="\"GET http://<IP_ADDRESS>:8081/ready HTTP/1.1\" from <IP_ADDRESS>:45154 - 200 30B in 33.351678ms" app=metering component=api
time="2020-09-09T01:58:50Z" level=info msg="\"GET http://<IP_ADDRESS>:8081/healthy HTTP/1.1\" from <IP_ADDRESS>:45154 - 200 30B in 24.869043ms" app=metering component=api

Thanks you very much.

@xkwangcn if it's a 4.2 cluster, I imagine the thanos querier functionality hadn't been added yet. Try using the prometheus-k8s service in the openshift-metering namespace instead of the default prometheus URL. There should be docs on how to configure the reporting-operator to do that.

https://github.com/kube-reporting/metering-operator/blob/master/Documentation/configuring-reporting-operator.md#prometheus-connection

ok, thanks for your reply, I will  try using the prometheus-k8s service in the openshift-monitoring namespace.


We want to use _putenv_s also in MinGW builds

Currently this only works for MSVC builds, but MinGW builds have the same requirement.

@ptosco : think it's worth trying to setup a mingw build as part of the CI process?


Feature - delete a vehicle

What it Does

Closes issue #42
This change add Vehicle deletion capability through swiping.

How I Tested

Add a new vehicle, if there is no existing Vehicle.
Swipe from right to left.
Click on "Delete" Button.
Vehicle will get deleted permanently.

For example:

Run the application
Tap the "Settings" Button.
Tap "Add Vehicle" Button.
Fill in the details of the new vehicle.
Tap "Add".
Vehicle will get added.
Now to delete the vehicle, swipe from right to left, and click the "Delete" Button.
Vehicle will get deleted.
Restart the application to confirm that deletion has persisted.

Notes

N/A

Screenshot

Closing this PR because this functionality exists


when mode props value is ‘date time’, to select ‘time’ and click cancel button would be invalid.

Solution: modify index.js
TimePickerAndroid.open(timeOptions).then(({action, minute, hour}) => {
if (action === TimePickerAndroid.timeSetAction) {
let selectedDate = new Date(year, month, day, hour, minute);
this.props.onConfirm(selectedDate);
} else {
this.props.onCancel()
}
});

Hey!
I just commited a fix, could you give it a shot and tell me if it works for you?
I'll push it to npm then :)
Thanks man!

very well！

it does not work.

I'm reopening, could you provide an example sto that I can reproduce it?
What are you using? iOS or Android?

android ， i have to write like this to prevent bug
<DateTimePicker
                                           isVisible={this.state.isEndDateTimePickerVisible}
                                           mode='datetime'
                                           onConfirm={(date) => {
                                               this.setState({
                                                   isEndDateTimePickerVisible: false
                                               });

                                               if (!(date instanceof Date) || !isFinite(date)) {
                                                   return;
                                               }

                                               let time = Moment(date);
                                               this.setState({
                                                   endTime: time

                                               });

                                           }}
                                           onCancel={() => {
                                               this.setState({
                                                   isEndDateTimePickerVisible: false
                                               });
                                           }}
                                       />

@lhr000lhr it is still working correctly for me even while removing that "fix" on a Nexus5X (language Italian).
What model is you device?
Is it an emulator?
What's the language you set?
And what is its Android version?

i have tested in serveral devices containing android 4.1 - 6.0 .It's really easy to recurrence this bug. i'd like to commit a demo,if it's helpful to fix it.

here is that page's source code. thers is nothing special,but the bug comes every time.
MeetingEditTime.js.zip

I have a feeling this bug is caused by the language of your system, could you try with a device in english language?

this emulator is in English.

I might have fixed it, could you try the version in the master branch?
Still don't know why it did work on other devices though... 🤔

@lhr000lhr did you test? I'd like to close this issue :)

no yet. i'll test it as soon as possible.(:з」∠)

Closing, let me know if the issue arises again 👍


Crashes upon opening.

Whenever I open it on Android, it momentarily opens without the notes visible, and then crashes.
I can still tap and hold it to bring up an option to write a new note; that allows me to write the note, but pressing save causes the crash. Only happened since the rewrite.

Thanks for reporting this issue. I pushed out an update to Google Play last night that should resolve the issue and get the app opening again for you.

I'll look into the right-to-left support for a point release, likely something in Compose that I just overlooked. Definitely wasn't intentional that it was removed.

I'll look into the right-to-left support for a point release, likely something in Compose that I just overlooked. Definitely wasn't intentional that it was removed.

Cool, thanks


Auth options for Heroku

HI
Was trying this out and found the need to have the auth option on redis when deployed on Heroku (worked fine locally without)
So added some options and updated the README.md for your review
Cheers
Stujo

:+1:
This is EXACTLY what i needed.
I came here to click the fork button when I saw your pull request, well done !
I would love to see this included in npm :-)

Thanks @mcoeur - I hope it works well for you

Looking good! Will test & merge soon.

Thanks a lot! I've just released this change:
published version 1.0.0 to npm

:+1:


Error lavaplayer Spotify links for lavalink v3

This error occurs when you put music links or Spotify playlists and it becomes an infinite loop

This is not applicable to this repository.


CMake revived

I though I'd give it a try as well. It is based on #107. I tried to fix the issues mentioned there.
I moved the commands for Travis CI into separate scripts, to make them easier to read and modify.

Coverage decreased (-82.6%) to 0.0% when pulling 476d6be43ce141922738d9e087e9515813ede391 on MaartenBent:cmake into 85cdafb0cbbac742f86f3f7c8fd8657fe4ff774f on tbeu:master.

Thanks a lot. This looks very promising and I am going to check it.
I am currently working on the conan support, but not yet based on cmake generator.

Can you please check that -no-undefined -export-symbols<EMAIL_ADDRESS>is set for the LD_FLAGS, too.

Do not worry about AppVeyor CI: I cancelled the jobs to check out CMake support there.

I have made the config input files an exact copy of the files that are used as input for configure (but with CMake defines). I'm aware that this probably breaks building with older Visual Studio versions because it uses a modified matio_pubconf.h. I'll integrate these modifications later.

I think these are all my changes for now.
If you need help with AppVeyor, let me know. I'd suggest to not run CMake in the main directory, but create and go into e.g. cmake_build. In build_script you can use something like:
cmake --build . --config $env:configuration -- /logger:"C:\Program Files\AppVeyor\BuildAgent\Appveyor.MSBuildLogger.dll"

I think these are all my changes for now.

💯 Thank you.

If you need help with AppVeyor, let me know

Yes, something is broken, but I have no clue how to fix the env variable check for %build_with%=="cmake".

Do you know why PACKAGE_VERSION cannot be set on Linux?
[ 75%] Built target matio
[ 87%] Built target matdump
[ 93%] Building C object CMakeFiles/test_mat.dir/test/test_mat.c.o
/home/tbeu/matio-cmake/test/test_mat.c: In function ‘main’:
/home/tbeu/matio-cmake/test/test_mat.c:3840:34: error: ‘PACKAGE_VERSION’ undeclared (first use in this function); did you mean ‘H5_PACKAGE_VERSION’?
                        prog_name,PACKAGE_VERSION);
                                  ^~~~~~~~~~~~~~~
                                  H5_PACKAGE_VERSION
/home/tbeu/matio-cmake/test/test_mat.c:3840:34: note: each undeclared identifier is reported only once for each function it appears in
CMakeFiles/test_mat.dir/build.make:62: recipe for target 'CMakeFiles/test_mat.dir/test/test_mat.c.o' failed
make[2]: *** [CMakeFiles/test_mat.dir/test/test_mat.c.o] Error 1
CMakeFiles/Makefile2:141: recipe for target 'CMakeFiles/test_mat.dir/all' failed
make[1]: *** [CMakeFiles/test_mat.dir/all] Error 2
Makefile:129: recipe for target 'all' failed
make: *** [all] Error 2
tbeu@laptop:~/matio-cmake$ cmake --version
cmake version 3.10.2

CMake suite maintained and supported by Kitware (kitware.com/cmake).
tbeu@laptop:~/matio-cmake$

It is missing in lines 199, 208 and 244 of matioConfig.h.

Maybe it is a protected name, its also used by https://cmake.org/cmake/help/latest/manual/cmake-packages.7.html. VERSION is also not set. I'll work around it.
I see Travis does not build test_snprintf, because it has a native snprintf implementation, but it still tries to tun test_snprintf. I'll always enable the test_snprintf project on unix.

The environment value build_with did not change for different jobs. I worked around it by extracting it from APPVEYOR_JOB_NAME environment variable.

Thank you again so far. What is left for me to do is to update the NEWS (requires a rebase of this branch) and to mention CMake support in the two README files.

I'll rebase it and smash all these small commits into one.

I'll rebase it and smash all these small commits into one.

OK, I'll wait then.

I first need to fix Travis. It doesn't like the version number: https://travis-ci.org/github/tbeu/matio/jobs/723872609#L846

Hm, do not see what was changed. It was all green this morning when I restarted the Travis job.

Changing find_package(HDF5) to find_package(HDF5 1.8) broke it. Setting CMAKE_PREFIX_PATH correctly seems to have fix it.

Changing find_package(HDF5) to find_package(HDF5 1.8) broke it. Setting CMAKE_PREFIX_PATH correctly seems to have fix it.

Ah, now I see. The line number L846 was not correctly displayed when clicking the link. hence my first confusion.

Changing find_package(HDF5) to find_package(HDF5 1.8) broke it. Setting CMAKE_PREFIX_PATH correctly seems to have fix it.

Ah, now I see. The line number L846 was not correctly displayed when clicking the link. hence my first confusion.

I added you as a contributor such that you should be able to cancel or restart the Travis jobs.

Thanks.
CMake jobs are building successful now, so I'll rebase, squash and force-push. Then I think it can be merged.

Awesome work guys!!!


Inferred rules not working in v2.1.4

Versions

vee-validate: 2.1.4
vue: 2.5.17

Describe the bug
Inferred rules are not working in v2.1.4 of vee-validate
To reproduce
Steps to reproduce the behavior:

Go to the demos guide
Update the vee-validate dependency to 2.1.4
Select the inferred rules demo
You will notice that the validation does not work after this update

Expected behavior
I expected the validation error messages to show if I enter an invalid email.
Desktop (please complete the following information):

OS: mac OSX mojave
Browser: chrome
Version: 70.0.3538.102

In 2.1.4 the inferred rules have been disabled by default since it caused conflicts and unexpected results to some people.
It is an opt-in feature now, you can turn it on using validity option:
Vue.use(VeeValidate, {
  validity: true
});


trouble getting started using gdx-video for Android with Android Studio

I am new to Java/Android development.  Using Android Studio 1.5.1.  I've built gdx-video and gdx-video-android to two jar files using jdk1.8.0_66\bin\jar.exe cfv filename.jar *.  I added the two files to a libs folder just under my libgdx project (at the same level as core and android folders).  In my project's build.gradle I added these lines to both the core and android dependencies blocks:
compile fileTree(dir: '../libs', include: '*.jar')

then resync'd gradle and added the following inside the ApplicationAdapter's create():
	videoPlayer = VideoPlayerCreator.createVideoPlayer();
	videoPlayer.resize(Gdx.graphics.getWidth(), Gdx.graphics.getHeight());
	videoPlayer.setOnVideoSizeListener(new VideoPlayer.VideoSizeListener() {
		@Override
		public void onVideoSize(float v, float v2) {
			videoLoaded = true;
		}
	});

Android Studio asks to import the unknown class com.badlogic.gdx.video.VideoPlayer, I respond with Alt+Enter and it prompts again for the same import.  If I add com.bad.logic.gdx.video.VideoPlayer manually, .video is not recognized.
What step am I missing?  Thank you.

It sounds like the project isn't correctly included in the classpath. Are you sure this is the normal way of including libraries for your project?
Unfortunately I don't have any experience with android studio, and I don't have a lot of experience with gradle (I'm still one of those maven people... :wink:).


Root minimizer broken?

I was running a test fit with hawc_hal last night and today. Today I spent some time creating a minimal example.
Using the HAWC public data set and a stripped down version of the basic example from the readme of hawc_hal, I have found that although the root minimizer is giving difficulties, minuit does not appear to have the same issue. It may be that a simple fix is available. I mentioned this on a HAWC call earlier today and an undergrad pointed out to me privately that allegedly newer versions of pyROOT  use ROOT.double() rather than ROOT.Double(), so this may be the issue (though there may be others). I created my environment yesterday using
conda create --name new_hal -c conda-forge -c threeml numpy scipy matplotlib ipython numba reproject "astromodels>=2" "threeml>=2" root
conda activate new_hal
pip install --no-binary :all: root_numpy
pip install git+https://github.com/threeml/hawc_hal.git

I then used this environment on a CentOS 7 machine.
Here is the example script
from hawc_hal import HAL, HealpixConeROI
import matplotlib.pyplot as plt
from threeML import *

# Define the ROI
ra_crab, dec_crab = 83.63, 22.02
data_radius = 3.0
model_radius = 8.0

roi = HealpixConeROI(data_radius=data_radius,
                     model_radius=model_radius,
                     ra=ra_crab,
                     dec=dec_crab)

# Instance the plugin
maptree = "HAWC_9bin_507days_crab_data.hd5"   # This can be either a ROOT or a hdf5 file
response = "HAWC_9bin_507days_crab_response.hd5" # This can be either a ROOT or hdf5 file

hawc = HAL("HAWC",
           maptree,
           response,
           roi)

# Use from bin 1 to bin 9
hawc.set_active_measurements(1, 9)

# Define model as usual
spectrum = Log_parabola()
source = PointSource("crab", ra=ra_crab, dec=dec_crab, spectral_shape=spectrum)

spectrum.piv = 7 * u.TeV
spectrum.piv.fix = True

spectrum.K = 1e-14 / (u.TeV * u.cm ** 2 * u.s)  # norm (in 1/(keV cm2 s))
spectrum.K.bounds = (1e-25, 1e-19)  # without units energies are in keV

spectrum.beta = 0  # log parabolic beta
spectrum.beta.bounds = (-4., 2.)

spectrum.alpha = -2.5  # log parabolic alpha (index)
spectrum.alpha.bounds = (-4., 2.)

model = Model(source)

data = DataList(hawc)

print("Perform fit using minuit")
jl = JointLikelihood(model, data, verbose=False)
jl.set_minimizer("minuit")
jl.fit()
jl.get_errors()

print("")
print("")

print("Now using Root")
jl2 = JointLikelihood(model, data, verbose=False)
jl2.set_minimizer("root")
jl2.fit()
print("And now everything goes wrong...")
jl2.get_errors()

The python traceback before the core dump is
  File "root_example.py", line 62, in <module>
    jl2.get_errors()
  File "/data/disk01/home/cbrisboi/hawc_software/miniconda3/envs/new_hal/lib/python3.7/site-packages/threeML/classicMLE/joint_likelihood.py", line 385, in get_errors
    errors = self._minimizer.get_errors()
  File "/data/disk01/home/cbrisboi/hawc_software/miniconda3/envs/new_hal/lib/python3.7/site-packages/threeML/minimizer/minimization.py", line 1082, in get_errors
    errors_dict = self._get_errors()
  File "/data/disk01/home/cbrisboi/hawc_software/miniconda3/envs/new_hal/lib/python3.7/site-packages/threeML/minimizer/ROOT_minimizer.py", line 212, in _get_errors
    err_low = ROOT.Double(0)
  File "/data/disk01/home/cbrisboi/hawc_software/miniconda3/envs/new_hal/lib/python3.7/site-packages/ROOT/_facade.py", line 163, in _fallback_getattr
    raise AttributeError("Failed to get attribute {} from ROOT".format(name))
AttributeError: Failed to get attribute Double from ROOT

The output of the script is contained in this logfile:
minimal.log
This has a relatively simple workaround, by simply using minuit rather than root, but still should be addressed somehow.

Hi Chad! I can reproduce this error.
Note that the example is not executable as is, but the missing files can actually be downloaded from
https://data.hawc-observatory.org/datasets/crab_data/public_data/crab_2017/HAWC_9bin_507days_crab_response.hd5 and
https://data.hawc-observatory.org/datasets/crab_data/public_data/crab_2017/HAWC_9bin_507days_crab_data.hd5


Blueprints: revisit naming and location.

This is a non-obvious name for something that is a template for something else... let's get the (beginner friendly, clear and unambiguous) terminology sorted.

Code gardening.


us-al-prattville

http://www.prattvilleal.gov/departments/geographic-information-systems.html
says they offer address data, but you have to contact them, so i'm sure they want money.
"For further information, please contact the GIS Coordinator, Ryan Pecharka, at<PHONE_NUMBER> or by email."
<EMAIL_ADDRESS>

Closing as stale.


another fuzzing segfault

yosys -S
module a(b);integer
inout b;reg c;assign&0=0;assign 0=0;always
i=0;always
if(8)b=_;always
if(8)b=M&0;endmodule

 Yosys 0.5+327 (git sha1 b2544cf, afl-clang 3.5.0-10 -fPIC -Os)

-- Parsing `/tmp/min.v' using frontend `verilog' --

1. Executing Verilog-2005 frontend.
Parsing Verilog input from `/tmp/min.v' to AST representation.
Generating RTLIL representation for module `\a'.
Warning: Ignoring assignment to constant bits at /tmp/min.v:2:
    old assignment: 1'0 = 1'0
    new assignment: { } = { }.
Warning: Ignoring assignment to constant bits at /tmp/min.v:2:
    old assignment: 0 = 0
    new assignment: { } = { }.
Warning: Identifier `\i' is implicitly declared at /tmp/min.v:3.
Warning: Identifier `\_' is implicitly declared at /tmp/min.v:4.
Warning: Identifier `\M' is implicitly declared at /tmp/min.v:5.
Successfully finished Verilog frontend.

-- Running command `synth' --

2. Executing SYNTH pass.

2.1. Executing HIERARCHY pass (managing design hierarchy).

2.2. Executing PROC pass (convert processes to netlists).

2.2.1. Executing PROC_CLEAN pass (remove empty switches from decision trees).
Found and cleaned up 1 empty switch in `\a.$proc$/tmp/min.v:4$3'.
Found and cleaned up 1 empty switch in `\a.$proc$/tmp/min.v:3$2'.
Cleaned up 2 empty switches.

2.2.2. Executing PROC_RMDEAD pass (remove dead branches from decision trees).
 Executing PROC_INIT pass (extract init attributes).

2.2.4. Executing PROC_ARST pass (detect async resets in processes).

2.2.5. Executing PROC_MUX pass (convert decision trees to multiplexers).
Creating decoders for process `\a.$proc$/tmp/min.v:4$3'.
  creating decoder for signal `$2\b[31:0]'.
  creating decoder for signal `$3\b[31:0]'.
Creating decoders for process `\a.$proc$/tmp/min.v:3$2'.
  creating decoder for signal `$0\b[31:0]'.
  creating decoder for signal `$1\b[31:0]'.
Creating decoders for process `\a.$proc$/tmp/min.v:2$1'.
  creating decoder for signal `$0\i[0:0]'.

2.2.6. Executing PROC_DLATCH pass (convert process syncs to latches).
No latch inferred for signal `\a.\b' from process `\a.$proc$/tmp/min.v:4$3'.
No latch inferred for signal `\a.\b' from process `\a.$proc$/tmp/min.v:3$2'.
No latch inferred for signal `\a.\i' from process `\a.$proc$/tmp/min.v:2$1'.

2.2.7. Executing PROC_DFF pass (convert process syncs to FFs).

2.2.8. Executing PROC_CLEAN pass (remove empty switches from decision trees).
Removing empty process `a.$proc$/tmp/min.v:4$3'.
Removing empty process `a.$proc$/tmp/min.v:3$2'.
Removing empty process `a.$proc$/tmp/min.v:2$1'.
Cleaned up 0 empty switches.

2.3. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \a..
  removing unused non-port wire \i.
  removing unused non-port wire \c.
  removed 2 unused temporary wires.

2.4. Executing CHECK pass (checking for obvious problems).
checking module a..
Warning: Wire a.\M is used but has no driver.
found and reported 1 problems.

2.5. Executing OPT pass (performing simple optimizations).

2.5.1. Executing OPT_CONST pass (perform const folding).

2.5.2. Executing OPT_SHARE pass (detect identical cells).
Finding identical cells in module `\a'.
Removed a total of 0 cells.

2.5.3. Executing OPT_MUXTREE pass (detect dead branches in mux trees).
Running muxtree optimizier on module \a..
  Creating internal representation of mux trees.
  No muxes found in this module.
Removed 0 multiplexer ports.

2.5.4. Executing OPT_REDUCE pass (consolidate $*mux and $reduce_* inputs).
  Optimizing cells in module \a.
Performed a total of 0 changes.

2.5.5. Executing OPT_SHARE pass (detect identical cells).
Finding identical cells in module `\a'.
Removed a total of 0 cells.

2.5.6. Executing OPT_RMDFF pass (remove dff with constant values).
Replaced 0 DFF cells.

2.5.7. Executing OPT_CLEAN pass (remove unused cells and wires).
Finding unused cells or wires in module \a..

2.5.8. Executing OPT_CONST pass (perform const folding).

2.5.9. Finished OPT passes. (There is nothing left to do.)

2.6. Executing WREDUCE pass (reducing word size of cells).
Removed top 31 bits (of 32) from port B of cell a.$and$/tmp/min.v:5$4 ($and).

Program received signal SIGSEGV, Segmentation fault.
(anonymous namespace)::WreduceWorker::run_cell (this=0x7fffffffc630, cell=0x203f500)
    at passes/opt/wreduce.cc:208
warning: Source file is more recent than executable.
208
(gdb)

With current git head (Yosys 0.5+366, git commit 4cec1c0) this is just a syntax error.


Test with pytest-randomly

This is a great project to check that random test ordering doesn't break anythign.

Done in c4c62e2d1fd081edb367268e25e63733bb8dcc91


Add a "Developer Guide" section to the network-policy-api website #165

This PR will close #165
I mainly refer to The Gateway API's developer guide and change/remove/add something that special to network policy api project.

@astoycos
,
@Dyanngg
, @danwinship
This PR has been waiting for review for two weeks, so I'm reaching out to follow up. As a new contributor, I'm still getting familiar with the process here.
If you don't have the capacity to review it, could you help me find another reviewer who might be available?
Thanks!

/ok-to-test

/remove-lifecycle stale

/lgtm

/ok-to-test

Hi @tssurya thanks for opening it again.  I have checked the doc and tried a few ways to find someone who can approve this.

@jgao1025 yes it's on my list will certainly take a look thank you for your contribution


DIG.PWAutoLogin version 0.2.3

Checklist for Pull Requests

[ ] Have you signed the Contributor License Agreement?
[ ] Is there a linked Issue?

Manifests

[ ] Have you checked that there aren't other open pull requests for the same manifest update/change?
[ ] This PR only modifies one (1) manifest
[ ] Have you validated your manifest locally with winget validate --manifest <path>?
[ ] Have you tested your manifest locally with winget install --manifest <path>?
[ ] Does your manifest conform to the 1.9 schema?

Note: <path> is the directory's name containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

[Policy] Reset Feedback

[Policy] Changes-Requested

[Policy] Needs-Author-Feedback

=== manifests\d\DIG\PWAutoLogin\0.2.3 ===
Missing Properties value based on version 0.2.1:
Installers
I think this error can be due to dropped x86 support..


[NEW ALGORITHM] Full Binary Tree

Issue will be closed if:

You mention more than one algorithm. You can create a separate issue for each algorithm once the current one is completed.
You propose an algorithm that is already present or has been mentioned in a previous issue.
You create a new issue without completing your previous issue.

Note: These actions will be taken seriously. Failure to follow the guidelines may result in the immediate closure of your issue.

Name:
```[NEW ALGORITHM]` Full Binary Tree``
About:
A full binary tree is a binary tree with either zero or two child nodes for each node.

Labels:
new algorithm, gssoc-ext, hacktoberfest, level1

Assignees:

[yes ] Contributor in GSSoC-ext
[ yes] Want to work on it

Please assign me this issue
@pankaj-bind

please /assign me this issue.

Please assign me the issue
On Tue, 29 Oct 2024, 12:44 am Ayush Kumar Dubey, @.***>
wrote:

please /assign me this issue.
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2442419166,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6BPR4BQVUMTR6FEOLTZ52EIJAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBSGQYTSMJWGY
.
You are receiving this because you authored the thread.Message ID:
@.***>

please assign this issue to me @pankaj-bind

Please assign this to me @pankaj-bind
On Tue, 29 Oct 2024, 4:24 pm gurnoorkaur-13, @.***>
wrote:

please assign this issue to me @pankaj-bind
https://github.com/pankaj-bind
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2443885112,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6AZXCHHWHV4AWYHHYTZ55SOFAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBTHA4DKMJRGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

What to resolve in the pr #1375
On Tue, 29 Oct 2024, 7:49 pm Pankaj Kumar Bind, @.***>
wrote:

Closed #1378 https://github.com/AlgoGenesis/C/issues/1378 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#event-14985413917, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6A6ZKH7WKUFFDPJ3VDZ56KNJAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUHE4DKNBRGM4TCNY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Why previous pr was revert and label are not showing in leaderboard sir
please check 🥺
On Tue, 29 Oct 2024, 7:51 pm Dipanita Mondal, @.***>
wrote:

What to resolve in the pr #1375
On Tue, 29 Oct 2024, 7:49 pm Pankaj Kumar Bind, @.***>
wrote:

Closed #1378 https://github.com/AlgoGenesis/C/issues/1378 as completed.
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#event-14985413917, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6A6ZKH7WKUFFDPJ3VDZ56KNJAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUHE4DKNBRGM4TCNY
.
You are receiving this because you authored the thread.Message ID:
@.***>

Why previous pr was revert and label are not showing in leaderboard sir please check 🥺 On Tue, 29 Oct 2024, 7:51 pm Dipanita Mondal, @.> wrote:
…
What to resolve in the pr #1375 On Tue, 29 Oct 2024, 7:49 pm Pankaj Kumar Bind, @.> wrote: > Closed #1378 <#1378> as completed. > > — > Reply to this email directly, view it on GitHub > <#1378 (comment)>, or > unsubscribe > https://github.com/notifications/unsubscribe-auth/A7SRZ6A6ZKH7WKUFFDPJ3VDZ56KNJAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUHE4DKNBRGM4TCNY > . > You are receiving this because you authored the thread.Message ID: > @.***> >

yes because of the wrong submission, you have submitted the wrong programs since starting, change all the things all will sort out

Wrong program means
On Tue, 29 Oct 2024, 8:04 pm Pankaj Kumar Bind, @.***>
wrote:

Why previous pr was revert and label are not showing in leaderboard sir
please check 🥺 On Tue, 29 Oct 2024, 7:51 pm Dipanita Mondal, @.
> wrote: … <#m_-8621179043038434674_> What to resolve in the pr #1375
https://github.com/AlgoGenesis/C/pull/1375 On Tue, 29 Oct 2024, 7:49 pm
Pankaj Kumar Bind, @.> wrote: > Closed #1378
https://github.com/AlgoGenesis/C/issues/1378 <#1378
https://github.com/AlgoGenesis/C/issues/1378> as completed. > > — >
Reply to this email directly, view it on GitHub > <#1378 (comment)
https://github.com/AlgoGenesis/C/issues/1378#event-14985413917>, or >
unsubscribe >
https://github.com/notifications/unsubscribe-auth/A7SRZ6A6ZKH7WKUFFDPJ3VDZ56KNJAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJUHE4DKNBRGM4TCNY

. > You are receiving this because you authored the thread.Message ID: >
@.***> >

yes because of the wrong submission, you have submitted the wrong programs
since starting, change all the things all will sort out
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2444450349,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6D5OVPLO3CEUUQ2GQDZ56MGZAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ2TAMZUHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

you have submitted cpp programs naming .c

you have to correct all

you have done same thing in this also https://github.com/AlgoGenesis/C/pull/1375

C++ or C program
On Tue, 29 Oct 2024, 8:08 pm Dipanita Mondal, @.***>
wrote:

Why I should to submit sir
On Tue, 29 Oct 2024, 8:08 pm Pankaj Kumar Bind, @.***>
wrote:

you have submitted cpp programs naming .c
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2444460492,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6CXY7Z3P2ATDGCSFU3Z56MUVAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ3DANBZGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

Sir
On Tue, 29 Oct 2024, 8:08 pm Dipanita Mondal, @.***>
wrote:

C++ or C program
On Tue, 29 Oct 2024, 8:08 pm Dipanita Mondal, @.***>
wrote:

Why I should to submit sir
On Tue, 29 Oct 2024, 8:08 pm Pankaj Kumar Bind, @.***>
wrote:

you have submitted cpp programs naming .c
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2444460492,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6CXY7Z3P2ATDGCSFU3Z56MUVAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ3DANBZGI
.
You are receiving this because you authored the thread.Message ID:
@.***>

we accept only C program

Okay sir
On Tue, 29 Oct 2024, 8:09 pm Pankaj Kumar Bind, @.***>
wrote:

we accept only C program
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2444465090,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6AI3OJQTT2ITZZD4BTZ56M3TAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ3DKMBZGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

I will correct all things as soon as possible
On Tue, 29 Oct 2024, 8:10 pm Dipanita Mondal, @.***>
wrote:

Okay sir
On Tue, 29 Oct 2024, 8:09 pm Pankaj Kumar Bind, @.***>
wrote:

we accept only C program
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2444465090,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6AI3OJQTT2ITZZD4BTZ56M3TAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ3DKMBZGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Okay after correcting drop a message here

Okay sir thank you
On Tue, 29 Oct 2024, 8:11 pm Pankaj Kumar Bind, @.***>
wrote:

Okay after correcting drop a message here
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2444470009,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6DRGCTABSHTXSQ4HLLZ56NCXAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ3TAMBQHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

I have resolved the problem
On Tue, 29 Oct 2024, 8:21 pm Dipanita Mondal, @.***>
wrote:

Okay sir thank you
On Tue, 29 Oct 2024, 8:11 pm Pankaj Kumar Bind, @.***>
wrote:

Okay after correcting drop a message here
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2444470009,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6DRGCTABSHTXSQ4HLLZ56NCXAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ3TAMBQHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Please check my pull requests sir
On Tue, 29 Oct 2024, 11:40 pm Dipanita Mondal, @.***>
wrote:

I have resolved the problem
On Tue, 29 Oct 2024, 8:21 pm Dipanita Mondal, @.***>
wrote:

Okay sir thank you
On Tue, 29 Oct 2024, 8:11 pm Pankaj Kumar Bind, @.***>
wrote:

Okay after correcting drop a message here
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2444470009,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6DRGCTABSHTXSQ4HLLZ56NCXAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ3TAMBQHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Please merge my all pull requests sir I have resolved the problem  @ pankaj
Kumar Bind
On Tue, 29 Oct 2024, 11:40 pm Dipanita Mondal, @.***>
wrote:

Please check my pull requests sir
On Tue, 29 Oct 2024, 11:40 pm Dipanita Mondal, <
@.***> wrote:

I have resolved the problem
On Tue, 29 Oct 2024, 8:21 pm Dipanita Mondal, <
@.***> wrote:

Okay sir thank you
On Tue, 29 Oct 2024, 8:11 pm Pankaj Kumar Bind, <
@.***> wrote:

Okay after correcting drop a message here
—
Reply to this email directly, view it on GitHub
https://github.com/AlgoGenesis/C/issues/1378#issuecomment-2444470009,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A7SRZ6DRGCTABSHTXSQ4HLLZ56NCXAVCNFSM6AAAAABQXOHKDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBUGQ3TAMBQHE
.
You are receiving this because you authored the thread.Message ID:
@.***>

Please assign me this issue
@pankaj-bind


BatchDelete and BatchUpdate operation for Postgres is not working correctly

At the moment, the BatchDelete and BatchUpdate operation for Postgres is not working correctly. v.6.2.8
After a long debugging, I managed to find out the following:
When GetRelationalCommandTemplate is called, the alias for the table is determined as far as I understand based on the first letter of the table name. In my case it was "...AS a". During the cast of RestructureForBatch, "DELETE i" is replaced with "DELETE". It turns out that these methods will work only for tables whose name begins with "i".
The tests pass because the table in the tests is called Items.

Fixed with v6.2.9


Http String Not Mapped Into Metadata-Existing Enum Type

Describe the bug
In example below, the expected value of Action should be Action = UnifiedRoleScheduleRequestActions.adminRemove , but it's instead Action = "adminRemove",
Docs Link: https://docs.microsoft.com/en-us/graph/api/rbacapplication-post-roleeligibilityschedulerequests?view=graph-rest-1.0&tabs=csharp#request-1
Http Request:
POST https://graph.microsoft.com/beta/roleManagement/directory/roleEligibilityScheduleRequests
Content-Type: application/json

{
    "action": "adminRemove",
    "roleDefinitionId": "8424c6f0-a189-499e-bbd0-26c1753c96d4",
    "directoryScopeId": "/",
    "principalId": "071cc716-8147-4397-a5ba-b2105951cc0b"
}

Generated C# Snippet:
GraphServiceClient graphClient = new GraphServiceClient( authProvider );

var unifiedRoleEligibilityScheduleRequest = new UnifiedRoleEligibilityScheduleRequestObject
{
	Action = "adminRemove",
	RoleDefinitionId = "8424c6f0-a189-499e-bbd0-26c1753c96d4",
	DirectoryScopeId = "/",
	PrincipalId = "071cc716-8147-4397-a5ba-b2105951cc0b"
};

await graphClient.RoleManagement.Directory.RoleEligibilityScheduleRequests
	.Request()
	.AddAsync(unifiedRoleEligibilityScheduleRequest);

Expected C# Code:
GraphServiceClient graphClient = new GraphServiceClient( authProvider );

var unifiedRoleEligibilityScheduleRequest = new UnifiedRoleEligibilityScheduleRequestObject
{
	Action = UnifiedRoleScheduleRequestActions.adminRemove,
	RoleDefinitionId = "8424c6f0-a189-499e-bbd0-26c1753c96d4",
	DirectoryScopeId = "/",
	PrincipalId = "071cc716-8147-4397-a5ba-b2105951cc0b"
};

await graphClient.RoleManagement.Directory.RoleEligibilityScheduleRequests
	.Request()
	.AddAsync(unifiedRoleEligibilityScheduleRequest);

Metadata description:
<EnumType Name="unifiedRoleScheduleRequestActions">
    <Member Name="adminAssign" Value="1"/>
    <Member Name="adminUpdate" Value="2"/>
    <Member Name="adminRemove" Value="3"/>
    <Member Name="selfActivate" Value="4"/>
    <Member Name="selfDeactivate" Value="5"/>
    <Member Name="adminExtend" Value="6"/>
    <Member Name="adminRenew" Value="7"/>
    <Member Name="selfExtend" Value="8"/>
    <Member Name="selfRenew" Value="9"/>
    <Member Name="unknownFutureValue" Value="10"/>
</EnumType>

Screenshots

Hey @fey101,
The unifiedRoleScheduleRequestActions enum seems to have now been removed and the property changed to a string.

It looks like this is a doc issue.
The first http example in the docs calls the v1.0 endpoint while the second example calls the beta endpoint.
Beta metadata has the property as string while v1.0 metadata has the property as an enum thus explaining the inconsistency in the snippets.
We would need to change the url in the http example from
https://graph.microsoft.com/beta/roleManagement/directory/roleEligibilityScheduleRequests

to
https://graph.microsoft.com/v1.0/roleManagement/directory/roleEligibilityScheduleRequests

From the docs this appears fixed shown above. This is also fixed as per raptor reports.


User is unable to authenticate with magic link

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Navigate to sig-up page
Enter email & click on 'Continue' button
Open email > copy magic link > open new tab
Paste to browser address bar & prefix the link with dev link in the following format: http://localhost:8082/v/15361796/136890
Press enter
Switch to the tab where user was trying to sign in

Expected Result:
User should be signed in
Actual Result:
User is not signed in until the user refreshes the page
Workaround:
Can the user still use Expensify without this being fixed? Have you informed them of the workaround?
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[x] MacOS / Chrome / Safari
[ ] MacOS / Desktop

Version Number: Dev
Reproducible in staging?: dev
Reproducible in production?: dev
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
Expensify/Expensify Issue URL:
Issue reported by: @Natnael-guchima
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1692948638904319
View all open jobs on GitHub

:wave: Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open StagingDeployCash deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

Identify the pull request that introduced this issue and revert it.
Find someone who can quickly fix the issue.
Fix the issue yourself.

I know @tgolen is out for the rest of the day, grabbing this

This is not reproducible on staging, so not a deploy blocker.

@kavimuru I am unable to reproduce this 👀

Hello @NicMendonca did you try on development environment? I think the issue only exists on dev currently.

@Natnael-Guchima Does it work if you manually enter the code?

@tgolen yes it works fine when you entered the magic code manually

One user pastes the magic, they should be navigated into the app, rather the they are stuck at enter magic code page. The same flow works fine on staging.

is it a frontend issue, or a backend issue?

I am not sure. But I guess it is front-end issue that is related to navigation.

Could you please try some of the following and add the information to this issue?

Look at JS console for any errors
Look at the network requests to see if requests are successful
For requests that are successful for validating the magic code, can you please include their requestID in case I need to look up the logs for those requests on the server?

@tgolen
Response to the request:
{
"httpCode": 200,
"jsonCode": 200,
"authResponseMessage": "200 OK",
"requestID": "7fdee47cc8ef11ac-MRS"
}
Console log:

Now the issue is reproducible on staging:
https://github.com/Expensify/App/assets/57330233/c683bf4a-7429-4c24-976d-6aad508e3049
And it works fine on prod:
https://github.com/Expensify/App/assets/57330233/5d5bb161-30d9-4b24-8b15-cfe9d5c9ad89

OK, thank you! @johnmlee101 or @NikkiWines Do either of you might know what's going on here?

Has this always worked on staging? Some random part in the back of my subconscious thinks this flow only worked on prod but I can't for the life of me remember why. However the fact that the page just kind of sticks is very odd. Let me test and see

Okay I couldn't reproduce on staging but it was realllllllly slow. Which honestly feels like a performance regression. It took like 10 seconds to load the page, and another 5 seconds after to actually update the original sign in page with the code

@tgolen this issue is now reported by applause as a deploy blocker here

I'm going to close this issue as a duplicate.

@tgolen my report came first. The duplicate one is the one reported by applause. Can you please add my name on the other issue as a reporter?

Sure, updated 👍

Thanks 👍


refactor: vc proposal.

Codecov Report
Patch coverage: 73.09% and project coverage change: -2.22% :warning:

Comparison is base (bc3ccbc) 85.10% compared to head (52925b2) 82.89%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main      #17      +/-   ##
==========================================
- Coverage   85.10%   82.89%   -2.22%
==========================================
  Files          72       72
  Lines        8324     8498     +174
==========================================
- Hits         7084     7044      -40
- Misses        983     1167     +184
- Partials      257      287      +30

Files Changed
Coverage Δ

presexch/api.go
43.17% <0.00%> (-0.16%)
:arrow_down:

util/json/json.go
43.85% <0.00%> (-35.09%)
:arrow_down:

sdjwt/common/common.go
93.36% <22.22%> (-2.80%)
:arrow_down:

verifiable/jws.go
76.00% <37.50%> (-4.44%)
:arrow_down:

verifiable/credential.go
80.71% <71.67%> (-9.88%)
:arrow_down:

verifiable/common.go
75.21% <77.89%> (-4.00%)
:arrow_down:

verifiable/credential_sdjwt.go
90.44% <80.00%> (-0.96%)
:arrow_down:

verifiable/presentation.go
84.96% <82.95%> (-2.89%)
:arrow_down:

verifiable/credential_jwt.go
92.24% <87.50%> (+2.24%)
:arrow_up:

presexch/definition.go
84.68% <90.90%> (-2.31%)
:arrow_down:

... and 13 more

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Make debugLog() return a beast::Journal (RIPD-1209)

Previously, writes using debugLog() tagged every entry with TRC:.  With this change users of debugLog() must specify the severity level they want their information logged at.  Using the debugLog() becomes much more similar to using a beast::Journal.
Since Severity levels were attached to all debugLog() writes, please look over the Severities to see if you agree with the new levels.
There are two separate commits so the changes to beast can have a separate commit message from the changes to rippled.

We should never be logging anything "fatal" to the debug journal - it's never turned on unless explicitly requested, so anything written to it will end up in a bitbucket.

That's fine, but there's fatal-style stuff happening (e.g., unhanded exceptions) where there is not necessarily a Journal readily available.  And Derek said that all of our servers are running with --debug, so our servers will capture debugLog() writes.  What do you suggest?

As long as the limitations of debugJournal are understood, I'm fine with this as is - wasn't suggesting any change was needed. Only that writes to it might not show up when expected.

[Current coverage][cc-pull] is 69.79%

Merging [#1761][cc-pull] into [develop][cc-base-branch] will increase coverage by <.01%

@@            develop      #1761   diff @@
==========================================
  Files           857        857
  Lines         67573      67570     -3
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits          47156      47158     +2
+ Misses        20417      20412     -5
  Partials          0          0

[][cc-pull]

Powered by Codecov. Last updated by [d22eb0c...d57087a][cc-compare]
[cc-base-branch]: https://codecov.io/gh/ripple/rippled/branch/develop?src=pr
[cc-compare]: https://codecov.io/gh/ripple/rippled/compare/d22eb0caa25ecfbd373cc9af0347e56031a23646...d57087a72764ad17aee58de00edbf5244e2e4421
[cc-pull]: https://codecov.io/gh/ripple/rippled/pull/1761?src=pr

Rebased to 0.32.1-b1.

Looks good and the log levels seem reasonable to me. I don't know if there's any need for two separate commits. I know src/beast is separate, but are src/ripple and src/ripple/beast? :+1:

@ximinez: Good point about squashing the commits.    I agree that squashing is probably safe.  I'll wait until @nbougalis has finished his review.

I did leave one comment; I don't think it's currently a problem but someone should look into it.
We should consider changing setDebugLogSink so that it can never only be called at most once. Otherwise, it's possible (albeit unlikely) to have Stream objects that reference a Sink that has been destroyed.

Regarding changing setDebugLogSink() to be callable only once, that could be done by adding assert (holder_ == nullptr) here: https://github.com/ripple/rippled/blob/develop/src/ripple/basics/impl/Log.cpp#L371
But then we'd need to adjust the ReportUncaughtException unit test, which replaces the DebugLogSink so it can observe the log write: https://github.com/ripple/rippled/blob/develop/src/ripple/core/tests/ReportUncaughtException.test.cpp#L93-L94

:+1:


Licensed groups in preview?

The doc says: "The group-based licensing feature currently is in public preview."
Is it correct?
This feature has been around for a long time and the other documentation about how to use it does not mention the feature being in preview, which is important information.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 5e434b86-3ce5-0e90-1ad0-b7f35f4c88df
Version Independent ID: 66d94ffb-9140-4960-ccb2-54e54d1ece86
Content: Users, groups, licensing, and roles in Azure Active Directory
Content Source: articles/active-directory/enterprise-users/directory-overview-user-model.md
Service: active-directory
Sub-service: enterprise-users
GitHub Login: @curtand
Microsoft Alias: curtand

@jorge-at123
Thanks for your feedback! I've assigned this issue to the author who will investigate and update as appropriate.

Hello @JamesTran-MSFT and @curtand! Is there any update here?
Thank you, guys.

Hello @JamesTran-MSFT and @curtand!
This is important in determining whether we can use this feature in production as the document says it's in preview.
I would appreciate it if you guys could update here.
Thank you.

@jorge-at123
Thank you for following up and I apologize for the delayed resolution.
After looking into this further - from our What's new in Azure Active Directory documentation, it links to the Archive for What's new in Azure Active Directory doc, which states:

Group-based licensing is now generally available - November/December 2018 update.
I've created a PR to update the documentation and will now close out this issue. Please allow some time for the changes to reflect and if you don't see the document update, please let me know.
I will be more than happy to re-open this issue and look into what happened.
Thank you for your time and patience!


Scanning projects that depend on datahub-client shows an unlikely vulnerability due to an old guava dependency

Describe the bug
Scanning projects that depend on datahub leads to an unnecessary guava 15 vulnerability flag. It doesn't seem like the dependency actually depends on it, and this is likely only appearing bc internal pom files for building the client artifact are being published in the artifact itself.
To Reproduce
Steps to reproduce the behavior:

Create a Java project that depends on 'io.acryl:datahub-client:0.8.26'
Scan it with OWASP's dependency checker
View report

Expected behavior
Generally I don't think the pom file in META-INF/maven needs to be published with the jar file, which would probably mitigate this issue.
Screenshots
Scanning my project which depends on the datahub-client leads to this output.
datahub-client-0.8.36.jar/META-INF/maven/com.google.guava/guava/pom.xml<EMAIL_ADDRESS>cpe:2.3:a:google:guava:15.0:*:*:*:*:*:*:*) : CVE-2018-10237, CVE-2020-8908

Desktop (please complete the following information):
Probably not relevant but:

OS: macOS Monterey
Browser: Although not used
Version: io.acryl:datahub-client:0.8.26

Additional context
N/A

I believe the pom files are included as a part of the Shadow gradle plugin we use that specifies which dependencies we are leveraging. The file will be there, but it will show the updated version (27.0.1) and shouldn't trigger the warning.

PR with changes has been merged, closing. Let us know if this doesn't resolve your issue and we can either reopen or open a new one 😄


add Python 3.11 wheels

behind CIBW_PRERELEASE_PYTHONS flag for now (wait for 3.11 rc)

It works! need to wait for upload, because 3.11 wheels shouldn't be uploaded before beta 4 at the earliest, expected in July.
closes #1697