[operator] Update to 0.99 breaks certificates of both webhooks

The update breaks certificates for the ValidatingWebhookConfiguration and MutatingWebhookConfiguration. SecretName in the Certificate does not match the cert-manager.io/inject-ca-from in the ValidatingWebhookConfiguration and MutatingWebhookConfiguration:
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  labels:
    app.kubernetes.io/component: webhook
    app.kubernetes.io/instance: opentelemetry-operator
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: opentelemetry-operator
    app.kubernetes.io/version: 0.99.0
    helm.sh/chart: opentelemetry-operator-0.58.0
    helm.toolkit.fluxcd.io/name: opentelemetry-operator
    helm.toolkit.fluxcd.io/namespace: opentelemetry
  name: opentelemetry-operator-serving-cert
  namespace: opentelemetry
spec:
  dnsNames:
  - opentelemetry-operator-webhook.opentelemetry.svc
  - opentelemetry-operator-webhook.opentelemetry.svc.cluster.local
  issuerRef:
    kind: Issuer
    name: opentelemetry-operator-selfsigned-issuer
  secretName: opentelemetry-operator-controller-manager-service-cert      # NOTE THIS SECRET NAME
  subject:
    organizationalUnits:
    - opentelemetry-operator

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    cert-manager.io/inject-ca-from: opentelemetry/opentelemetry-operator-serving-cert     # COMPARE TO SECRET HERE
    controller-gen.kubebuilder.io/version: v0.14.0
  creationTimestamp: null
  labels:
    app.kubernetes.io/name: opentelemetry-operator
    helm.toolkit.fluxcd.io/name: opentelemetry-operator
    helm.toolkit.fluxcd.io/namespace: opentelemetry
  name: opampbridges.opentelemetry.io
spec

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  annotations:
    cert-manager.io/inject-ca-from: opentelemetry/opentelemetry-operator-serving-cert    # COMPARE TO SECRET HERE
  labels:
    app.kubernetes.io/component: webhook
    app.kubernetes.io/instance: opentelemetry-operator
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: opentelemetry-operator
    app.kubernetes.io/version: 0.99.0
    helm.sh/chart: opentelemetry-operator-0.58.0
    helm.toolkit.fluxcd.io/name: opentelemetry-operator
    helm.toolkit.fluxcd.io/namespace: opentelemetry
  name: opentelemetry-operator-mutation
webhooks:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingWebhookConfiguration
metadata:
  annotations:
    cert-manager.io/inject-ca-from: opentelemetry/opentelemetry-operator-serving-cert   # COMPARE TO SECRET HERE
  labels:
    app.kubernetes.io/component: webhook
    app.kubernetes.io/instance: opentelemetry-operator
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: opentelemetry-operator
    app.kubernetes.io/version: 0.99.0
    helm.sh/chart: opentelemetry-operator-0.58.0
    helm.toolkit.fluxcd.io/name: opentelemetry-operator
    helm.toolkit.fluxcd.io/namespace: opentelemetry
  name: opentelemetry-operator-validation
webhooks:

This is the reason why other people complain that their migrations fails. I am note sure if it is correct that those webhooks only handle v1alpha1 and not v1beta1. Are they just for the migration or do we need to worry that they do not work at all?

We found this by monitoring the prometheus metric certmanager_cainjector_missing_cert from certmanager which instantly hightlights the issue. Otherwise its quite hard to see unless you check the kube-apiserver logs.

The cert-manager.io/inject-ca-from annotation is meant to point to the name of a Certificate (compared to cert-manager.io/inject-ca-from-secret which is meant to point to a Secret).
The webhooks use cert-manager.io/inject-ca-from so the value must be a Certificate name, not a Secret name.  In this case, the value they're using (opentelemetry/opentelemetry-operator-serving-cert) appears to be correct.

/cc @swiatekm-sumo

/cc @Allex1

The cert-manager.io/inject-ca-from annotation is meant to point to the name of a Certificate (compared to cert-manager.io/inject-ca-from-secret which is meant to point to a Secret).
The webhooks use cert-manager.io/inject-ca-from so the value must be a Certificate name, not a Secret name. In this case, the value they're using (opentelemetry/opentelemetry-operator-serving-cert) appears to be correct.

Well kubernetes disagrees. It does not work that way and cert-manager complains about this setup. Upgrade webhooks do not work.
We manually upgraded the CRDs and it works now. But the upgrade totally failed on both Kops AWS and Azure AKS clusters.

I'd like to understand what the problem is exactly. Is it just the conversion webhook misbehaving, or all of them? The latter will be very confusing, as the changes in #1175 and #1776 haven't actually changed anything about the certmanager setup for ValidatingWebhookConfiguration and MutatingWebhookConfiguration. The CRDs have changed, and I can see the conversion webhook causing problems, but everything else should be fine.
Can everyone experiencing problems post more details of their environment? The following would help:

Operator Helm Chart values.yaml
Previous Operator Helm Chart version
cert-manager version
K8s Platform and version

@swiatekm-sumo I'm not the OP, but I am experiencing a cert-related issue with the conversion webhook specifically
after upgrading to operator-0.58.2 / operator-chart-0.99.0 + following the upgrade instructions here, we're noticing this specific dry-run failure:
failed to prune fields: failed add back owned items: failed to convert pruned object at version opentelemetry.io/v1beta1: conversion webhook for opentelemetry.io/v1alpha1, Kind=OpenTelemetryCollector returned invalid metadata: invalid metadata of type <nil> in input object

Your requested info:
Operator Helm Chart values.yaml
➜ helm get values otel-operator
USER-SUPPLIED VALUES:
kubeRBACProxy:
  enabled: false
manager:
  collectorImage:
    repository: otel/opentelemetry-collector-contrib
nodeSelector:
  node_pool: observability
replicaCount: 2
topologySpreadConstraints:
- labelSelector:
    matchLabels:
      app.kubernetes.io/component: controller-manager
      app.kubernetes.io/instance: otel-operator
      app.kubernetes.io/name: opentelemetry-operator
  maxSkew: 1
  topologyKey: kubernetes.io/hostname
  whenUnsatisfiable: ScheduleAnyway
- labelSelector:
    matchLabels:
      app.kubernetes.io/component: controller-manager
      app.kubernetes.io/instance: otel-operator
      app.kubernetes.io/name: opentelemetry-operator
  maxSkew: 1
  topologyKey: topology.kubernetes.io/zone
  whenUnsatisfiable: ScheduleAnyway

Previous Operator Helm Chart version
0.57.0 -> 0.58.2

cert-manager version
quay.io/jetstack/cert-manager-controller:v1.14.5

K8s Platform and version
GKE / 1.28.9

@parkedwards just to be sure I understand correctly, you upgrade the operator chart to 0.58.2, and then you get the error when trying to apply v1alpha1.OpenTelemetryCollector resources? Can you also post your v1alpha1.OpenTelemetryCollector resource that you get the error for?

@parkedwards just to be sure I understand correctly, you upgrade the operator chart to 0.58.2, and then you get the error when trying to apply v1alpha1.OpenTelemetryCollector resources? Can you also post your v1alpha1.OpenTelemetryCollector resource that you get the error for?

Exactly. The webhook TLS configuration is not right. Kubeapi server complains that it cannot load the cert. Cert-manager complains as well and reports the it as unready.

@parkedwards just to be sure I understand correctly, you upgrade the operator chart to 0.58.2, and then you get the error when trying to apply v1alpha1.OpenTelemetryCollector resources? Can you also post your v1alpha1.OpenTelemetryCollector resource that you get the error for?

@swiatekm-sumo - small correction - we performed the operator/chart upgrade to 0.58.2 AND the v1beta1.OpenTelemetryCollector version update in the manifests (we use gitops to manage), as described in these instructions

Update any manifests you have stored outside the cluster, for example in your infrastructure git repository.

Apply them, so they're all stored as v1beta1.
Update the OpenTelemetryCollector CRD to only store v1beta1

I can share one of my v1beta1 CR manifest here:
apiVersion: opentelemetry.io/v1beta1
kind: OpenTelemetryCollector
metadata:
  creationTimestamp: "2023-09-26T14:44:25Z"
  generation: 76
  labels:
    app: otelcol-loadbalancer
    app.kubernetes.io/managed-by: opentelemetry-operator
    kustomize.toolkit.fluxcd.io/name: opentelemetry-collector
    kustomize.toolkit.fluxcd.io/namespace: flux-system
  name: otelcol-loadbalancer
  namespace: opentelemetry
  resourceVersion: "543736253"
  uid: f4886fef-31a5-49cc-9f5a-3418913cdc5a
spec:
  config:
    exporters:
      loadbalancing:
        protocol:
          otlp:
            sending_queue:
              num_consumers: 100
              queue_size: 300
            timeout: 30s
            tls:
              insecure: true
        resolver:
          dns:
            hostname: otelcol-gateway-collector.opentelemetry.svc.cluster.local
        routing_key: traceID
      prometheus:
        add_metric_suffixes: false
        endpoint: <IP_ADDRESS>:9090
    receivers:
      otlp:
        protocols:
          grpc: {}
          http: {}
      prometheus/internal:
        config:
          scrape_configs:
          - job_name: otelcol-loadbalancer
            scrape_interval: 15s
            static_configs:
            - targets:
              - <IP_ADDRESS>:8888
    service:
      pipelines:
        metrics/prometheus:
          exporters:
          - prometheus
          processors: []
          receivers:
          - prometheus/internal
        traces:
          exporters:
          - loadbalancing
          processors: []
          receivers:
          - otlp
      telemetry:
        logs:
          level: panic
          output_paths:
          - stdout
  daemonSetUpdateStrategy: {}
  deploymentUpdateStrategy: {}
  ingress:
    route: {}
  managementState: managed
  mode: deployment
  nodeSelector:
    node_pool: application
  observability:
    metrics: {}
  podAnnotations:
    sidecar.istio.io/proxyCPU: 850m
    sidecar.istio.io/proxyCPULimit: 1000m
    sidecar.istio.io/proxyMemory: 400Mi
    sidecar.istio.io/proxyMemoryLimit: 700Mi
  podDisruptionBudget:
    maxUnavailable: 1
  podSecurityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault
  replicas: 10
  resources:
    limits:
      cpu: 2500m
      memory: 1Gi
    requests:
      cpu: 1500m
      memory: 600Mi
  securityContext:
    allowPrivilegeEscalation: false
    capabilities:
      drop:
      - ALL
    readOnlyRootFilesystem: true
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault
  serviceAccount: otelcol-loadbalancer
  targetAllocator:
    allocationStrategy: consistent-hashing
    filterStrategy: relabel-config
    observability:
      metrics: {}
    prometheusCR:
      podMonitorSelector: {}
      scrapeInterval: 30s
      serviceMonitorSelector: {}
    resources: {}
  upgradeStrategy: automatic
status:
  image: otel/opentelemetry-collector-contrib:0.99.0
  scale:
    replicas: 10
    selector: app=otelcol-loadbalancer,app.kubernetes.io/component=opentelemetry-collector,app.kubernetes.io/instance=opentelemetry.otelcol-loadbalancer,app.kubernetes.io/managed-by=opentelemetry-operator,app.kubernetes.io/name=otelcol-loadbalancer-collector,app.kubernetes.io/part-of=opentelemetry,app.kubernetes.io/version=latest,kustomize.toolkit.fluxcd.io/name=opentelemetry-collector,kustomize.toolkit.fluxcd.io/namespace=flux-system
    statusReplicas: 10/10
  version: 0.99.0

and then for context, this is the v1alpha1 version  (can ignore the template functions and be assured that they're being interpolated properly at apply time):
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
  name: otelcol-loadbalancer
  namespace: opentelemetry
  labels:
    app: otelcol-loadbalancer
spec:
  mode: deployment
  nodeSelector:
    node_pool: application
  podAnnotations:
    sidecar.istio.io/proxyCPU: 850m
    sidecar.istio.io/proxyCPULimit: 1000m
    sidecar.istio.io/proxyMemory: 400Mi
    sidecar.istio.io/proxyMemoryLimit: 700Mi
  replicas: ${otelcol_loadbalancer_replica_count:=1}
  serviceAccount: otelcol-loadbalancer
  config: |

    receivers:
      otlp:
        protocols:
          grpc:
          http:
      prometheus/internal:
        config:
          scrape_configs:
            - job_name: otelcol-loadbalancer
              scrape_interval: 15s
              static_configs:
                - targets: [<IP_ADDRESS>:8888]
    exporters:
      prometheus:
        endpoint: <IP_ADDRESS>:9090
        add_metric_suffixes: false
      loadbalancing:
        # ensures that spans are consistently routed to
        # the same gateway replica based on traceID
        routing_key: traceID
        protocol:
          # all configuration options from the OTLP exporter
          # apply here (except the endpoint)
          otlp:
            timeout: 30s
            sending_queue:
              queue_size: ${otelcol_loadbalancer_exporter_queue_size:=500}
              num_consumers: ${otelcol_loadbalancer_exporter_num_consumers:=10}
            tls:
              insecure: true
        # uses the DNS resolver to find the gateway collector pods
        resolver:
          dns:
            hostname: otelcol-gateway-collector.opentelemetry.svc.cluster.local
    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: []
          exporters: [loadbalancing]
        metrics/prometheus:
          receivers: [prometheus/internal]
          processors: []
          exporters: [prometheus]
      telemetry:
        logs:
          # https://pkg.go.dev/go.uber.org/zap/zapcore#Level
          level: ${otelcol_log_level:=panic}
          output_paths: [stdout]
  resources:
    requests:
      cpu: ${otelcol_loadbalancer_cpu_req}
      memory: ${otelcol_loadbalancer_mem_req}
    limits:
      cpu: ${otelcol_loadbalancer_cpu_limit}
      memory: ${otelcol_loadbalancer_mem_limit}
  podSecurityContext:
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault
  securityContext:
    allowPrivilegeEscalation: false
    capabilities:
      drop:
        - ALL
    readOnlyRootFilesystem: true
    runAsNonRoot: true
    runAsUser: 10001
    seccompProfile:
      type: RuntimeDefault

It would really help me if someone were able to reproduce this problem in a KiND cluster and post their reproduction steps. I've tried several combinations, including upgrading 0.56.0 -> 0.57.0 -> 0.58.0, with cert-manager 1.6.1 and 1.14.1, and always ended up in a valid state with the conversion webhook working correctly.

@parkedwards just to be sure I understand correctly, you upgrade the operator chart to 0.58.2, and then you get the error when trying to apply v1alpha1.OpenTelemetryCollector resources? Can you also post your v1alpha1.OpenTelemetryCollector resource that you get the error for?

Exactly. The webhook TLS configuration is not right. Kubeapi server complains that it cannot load the cert. Cert-manager complains as well and reports the it as unready.

Thing is, this configuration hasn't changed, and as far I can see has always been this way. It'd have to be a bug (as our current use of the cert-manager annotation is correct as per their documentation) in CA injection specifically for CRDs, and likely only affecting specific cert-manager versions, and possibly only a specific platform.
This is why I'm asking for as much information as possible about your environments. I'm hoping to see some commonalities that would let me get to the bottom of things. I'd also really like to see the error logs you and @jan-kantert mentioned.
And on a related note, I see @parkedwards using istio. Anyone else in this thread also in that boat?

It would really help me if someone were able to reproduce this problem in a KiND cluster and post their reproduction steps. I've tried several combinations, including upgrading 0.56.0 -> 0.57.0 -> 0.58.0, with cert-manager 1.6.1 and 1.14.1, and always ended up in a valid state with the conversion webhook working correctly.

@parkedwards just to be sure I understand correctly, you upgrade the operator chart to 0.58.2, and then you get the error when trying to apply v1alpha1.OpenTelemetryCollector resources? Can you also post your v1alpha1.OpenTelemetryCollector resource that you get the error for?

Exactly. The webhook TLS configuration is not right. Kubeapi server complains that it cannot load the cert. Cert-manager complains as well and reports the it as unready.

Thing is, this configuration hasn't changed, and as far I can see has always been this way. It'd have to be a bug (as our current use of the cert-manager annotation is correct as per their documentation) in CA injection specifically for CRDs, and likely only affecting specific cert-manager versions, and possibly only a specific platform.
This is why I'm asking for as much information as possible about your environments. I'm hoping to see some commonalities that would let me get to the bottom of things. I'd also really like to see the error logs you and @jan-kantert mentioned.
And on a related note, I see @parkedwards using istio. Anyone else in this thread also in that boat?

We use linkerd. I have to check the cert-manager version. We run Kubernetes 1.26 and the latest compatible cert-manager version.


[SP-5702] Backport of PDI-18096 - Missing alert message in Ubuntu 18.…

…04 (8.3 Suite)
cherry-pick of 9e654c9
@ppatricio

:white_check_mark: Build finished in 18m 12s
Build command:
mvn clean verify -B -e -Daudit -amd -pl ui

:ok_hand: All tests passed!
Tests run: 1100, Failures: 0, Skipped: 0    Test Results

:information_source:  This is an automatic message


Using JKBMS name the is advertised in place of SerialBattery(JKBMS_BLE).

Is your feature request related to a problem? Please describe.
Hi
With the JKBMS app we can change the name of the BMS
This name is advertised as you can see with bluetoothctl scan on
(my BMS's)
Device C8:47:8C:EC:F8:F9 JKBMS-Display
Device C8:47:8C:ED:06:11 JKBMS-Heating
But you are not using this name, you replace it with SerialBattery(JKBMS_BLE).
Describe the solution you'd like
I would like to have the advertised name used in Device/Name on Venus OS
Describe alternatives you've considered
An alternative coud be using the name in config.ini
BLUETOOTH_BMS = JKBMS-Heating C8:47:8C:ED:06:11, JKBMS-Display C8:47:8C:EC:F8:F9
Additional context
No response

Can you send a screenshot of the JKBMS where you entered the name?
Please post a screenshot of all values on the Device in the remote console/GUI -> SerialBattery -> Device.

BTW, the name can already be set in the config.ini or by changing it in the remote console/GUI -> SerialBattery -> Device -> Name

regarding config.ini how can I add the name for each mac address ?

It's still in the alpha test phase, so there is no documentation yet except the config default file: https://github.com/Louisvdw/dbus-serialbattery/blob/4af10dd9d323ee9e88c82d8cec3b69a9d04fddfe/etc/dbus-serialbattery/config.default.ini#L197-L201
Please enter the name via GUI and the entry will be added automatically to the config file. I don't know how it behaves for the Bluetooth connected devices, but it's planned to link the name to the unique identifier, so that if the port changes the name get not lost. See https://github.com/Louisvdw/dbus-serialbattery/issues/100#issuecomment-1585743408.

In the JKBMS app it looks like this:

the name can be adjusted by user

On DBUS we can access this value under:
com.victronenergy.battery.ttyUSB1 and com.victronenergy.battery.ttyUSB2

After the reboot  of cerbo gx or reinserting USBs the port assignment may change

On DBUS we can access this value under:
com.victronenergy.battery.ttyUSB1 and com.victronenergy.battery.ttyUSB2

Ok, when I was testing this, I got another field. If you open a BMS in the app and scroll down to the limits there is also a User Private Data field or something like that. What is in this field in your case?

After the reboot of cerbo gx or reinserting USBs the port assignment may change

We are working on it in https://github.com/Louisvdw/dbus-serialbattery/issues/718

ups, written in wrong topic: https://github.com/Louisvdw/dbus-serialbattery/issues/718#issuecomment-1596268819


Add keywords used in SingleStore Portal

Use the same list of keywords as in SingleStore Portal UI.

Let's keep it as Draft until we find a way to tune completion in SQLTools to take this into account properly.


Error on install or build from source

Hi,
I've tried googling this, it's really annoying as I've not had many problems with this plugin before...
Installing the 'vagrant-hostsupdater-1.0.2.gem' plugin. This can take a few minutes...
/usr/lib/ruby/2.3.0/rubygems/specification.rb:946:in `all=': undefined method `group_by' for nil:NilClass (NoMethodError)
    from /usr/lib/ruby/vendor_ruby/vagrant/bundler.rb:275:in `with_isolated_gem'
    from /usr/lib/ruby/vendor_ruby/vagrant/bundler.rb:131:in `install_local'
    from /usr/lib/ruby/vendor_ruby/vagrant/plugin/manager.rb:47:in `install_plugin'
    from /usr/share/vagrant/plugins/commands/plugin/action/install_gem.rb:37:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/warden.rb:34:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/builder.rb:116:in `call'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in `block in run'
    from /usr/lib/ruby/vendor_ruby/vagrant/util/busy.rb:19:in `busy'
    from /usr/lib/ruby/vendor_ruby/vagrant/action/runner.rb:66:in `run'
    from /usr/share/vagrant/plugins/commands/plugin/command/base.rb:14:in `action'
    from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:32:in `block in execute'
    from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:31:in `each'
    from /usr/share/vagrant/plugins/commands/plugin/command/install.rb:31:in `execute'
    from /usr/share/vagrant/plugins/commands/plugin/command/root.rb:56:in `execute'
    from /usr/lib/ruby/vendor_ruby/vagrant/cli.rb:42:in `execute'
    from /usr/lib/ruby/vendor_ruby/vagrant/environment.rb:268:in `cli'
    from /usr/bin/vagrant:173:in `<main>'

Would this happen to be a problem with Ubuntu?
It's 16.04 64-bit, stock vagrant, stock ruby

:wink: Fixed as per
http://stackoverflow.com/questions/36811863/cant-install-vagrant-plugins-in-ubuntu-16-04

Thanks for the update @Lewiscowles1986


Additional check and optional chaining before accessing properties

Summary
Fixes #9211

Screenshot/Video
https://github.com/rancher/dashboard/assets/135728925/8864cef6-5aa8-47b2-9236-1c48e7f53b35

Would it make sense to add a guard clause to the beginning of this timer that does something along the lines of this?
if (!this.doc?.toc || this.doc.toc.length === 0) {
  this.selected = null;
  return;
}

I like it, thanks!


fix(material/tabs): emit selected index change

Fixes a bug where upon deleting any of the tabs before selected greater index eg. (['one, 'two', 'three']) 0 index gets deleted while 1 index being selected but it doesn't emit that new tab have been selected and return new index, as first index becoming the zeroth index
Fixes #26816

@crisbeto thoughts on this?


Remove turbolinks from Gemfile

It looks like this hasnt been included in the bundle since 0acabd3

Thanks @benreyn !


Mprof chunks

Final checks to merge mprof-checks with main

Too many conflicts with main branch.
Renaming mprof-chunks to main


receives GatsbyImageData type not JSON

Solves the error 'Error: Interface field HomepageImage.gatsbyImageData expects type JSON but ContentfulAsset.gatsbyImageData is type GatsbyImageData.'
when running 'gatsby develop' command.

For what it's worth, I have gone ahead and updated dependencies and the schema customization for all the different homepage starter variations in this PR: https://github.com/gatsbyjs/homepage-starters/pull/141
Feel free to give it a review!


Added InvoiceTotalValue, updated Price and tests, added 'NP' Tax

Added InvoiceTotalValue and some getters.
Added tests and updated tests for Price.
Tax can also be 'NP' when Tax is not applied.
From WFirma docs:

This is a good api.

Generalnie to uwag nie mam, ale te testy musza przejść xD

lokalnie przechodzą mi około 70% czasu. Tu widać 1%.


Any Tips and Tricks?

Hi Everyone!
I've recently started using this package to document my APIs and, while the documentation is great at showing what can be done / cannot be done, I have found some difficulties around the best way of documenting my apis. Here are some questions I haven't found an answer yet.

I'm using passport, how do I authenticate the GET requests this package is making?
if I'm specifying the @apiResourceCollection and @apiResourceModel attributes why is it not creating the response from a factory I have defined and is using my db to get the first model?
do you recommend using a separate DB full of fake data to generate the various responses or should I rather be using json response files?
How do I define different responses based on different parameters passed to the api?
How do I define different responses based on different access token scopes when using passport?
How do I mark some parameters as required when another field is empty or missing?

I think this package is great but it lacks something like a video tutorial that explains what the different configuration options and parameters do and why should I choose one way of doing things rather than another.

I'm using passport, how do I authenticate the GET requests this package is making?

Authentication is currently a tricky issue. The best thing you can do for now is add an "Authorization" header with your token (or query/body parameters) for when the response call is made. Maybe this is something we can tackle in greater detail in v5.

if I'm specifying the @apiResourceCollection and @apiResourceModel attributes why is it not creating the response from a factory I have defined and is using my db to get the first model?

Usually this means that the factory attempt failed. Try running with --verbose to see what the problem was.

do you recommend using a separate DB full of fake data to generate the various responses or should I rather be using json response files?

Whichever is easier for you. It's probably easier to keep a separate database up to date than manually manage response files.

How do I define different responses based on different parameters passed to the api?

Right now, you can't do that. However you can use the each of the @response* tags in conjunction with status codes to indicate different responses, including multiple responses for the same status code. Something like:
@response 400 {"error": "invalid arguments"}
@response 400 {"error": "missing data"}

We can probably add some feature to improve this going forward. Maybe something like @response <400, missing value> {"error": "missing value"}

How do I define different responses based on different access token scopes when using passport?

...
Maybe custom logic or a middleware? Also remember that there is a plugin system, so you can write a plugin that modifies or sets responses.

How do I mark some parameters as required when another field is empty or missing?

You add it in the description of that field.

I think this package is great but it lacks something like a video tutorial that explains

Probably, but that's an opporutnity that someone else can pick up. I'm not into creating video tutorials. Anyone in the community can do that.
The documentation is pretty comprehensive (I hope), and if you see something that isn't clear, you're welcome to send in a PR. In the future, we're looking to make the docs more guide-y, not just reference materials, so you can also point out any places you think are lacking..

Hi @lucadegasperi I'm closing this issue since I don't have the permissions to transfer to another repository. Scribe has been released now, so you shuoold open this issue in that repo if you still think it's relevant.
In the meantime, the docs for Scribe have been revamped to make things clearer, and we'll also be releasing some more helpful material in the near future.


System artifact type removed

What is the intention of this removal and how should we seek to cleanly integrate Eventually with external systems going forward?

Good question. From my (limited) experience, I think external systems are "unnecessary complexity", especially when they’re used mainly to represent long-running external integration processes that are eventually handled as internal aggregates. This additional layer tends to be redundant, and treating external systems as internal representations can be seen as an anti-pattern. Basically, I'm questioning the need for "eventually" to support internal copies of the external streams... something that can be achieved with simpler mechanisms.
A cleaner approach is refactoring the design using a command adapter. This adapter can map external events directly to internal commands targeting an aggregate, eliminating the need for an intermediary "system" layer. If you've found scenarios where this pattern doesn’t apply or if the system abstraction proves useful, feel free to share your use cases and we can discuss alternative solutions.

I see your points.  I will admit that it's tempting to use Eventually for everything due to it's simple building blocks, strict message type safety and abstracted storage mechanisms.
For example, in my application I record incoming webhooks using an eventually system.  This obviously gives me a way to record the webhook and also the abilty to use policies to send commands to relevent aggregates depending on the data that was received.  The actual external system that I receive webhooks from has no api to query historical data, so it's very convenient and useful to store this data as it comes in using Eventually's event store. This storage abstraction perfectly meets this use case IMHO and doesn't require me to write boilerplate to store this data otherwise and then feed it into the domain model.  Another advantage is that I can easily replay these events to policies or read models if needed by changing a subscription offset.
All that being said, I could refactor my webook system into an aggregate instead but that still does bring up the anti-pattern you mentioned of storing redundant or unnecessary external data in a domain service.  To me, the tools available within eventually are just too powerful not to use.  The typing magic is what tempts me the most to contort eventually into solving problems that the framework probably wasn't intended to solve.
Another example of how I use external systems is with a CommandScheduler system that schedules future timeout commands using BullMQ.  I know very well that I don't need to implement this as an Eventually system but I find it very useful to use that system's internal event stream as a poor mans(or not so poor) logging/tracing facility.  Again, perhaps redundant data and using the framework for unintended purposes.  Something I may need to reconsider.
All-in-all I welcome the removal of the system artifact, I just wanted to mention my current use-cases.  Maybe I am trying to contort Eventually into handling more things than it should.  Either way, thanks @Rotorsoft for this great framework.  It has given me the opportunity to learn a great deal about event driven systems in general.

Ok so lets say in the case of webhook recording and without the System artifact I would use the store() directly to store the incoming webhook stream in my web application layer.
const IncomingWebhookEvents = {
    WebhookArrived: z.object({
      typescript: z.string(),
      provide: z.string(),
    }),
  };

  const committed = await store.commit<typeof IncomingWebhookEvents>(
    "incoming-webhooks",
    [{
        stream: "incoming-webhooks",
        name: "WebhookArrived",
        data: {
          typescript: "would",
          provide: "intellisense?",
        },
      }],
    { correlation: "sdfasdfasdf", causation: {} }
  );

I'm not very adept at Typescript generics so the above I don't think quite works.  It was very convenient to use a System artifact where I could use Zod objects for my messages and Eventually would infer typing, validate my messages, etc.  Going the above route, the messages for my sub-streams are not tracked in the builder so I'm on my own with validation, etc.  I feel like this adds more complexity since I will have to build more boilerplate to do what an Eventually System would do for me but perhaps I'm just being stubborn and trying to avoid writing extra application code?😅

You should probably build a generic utility function to do this... shouldn't be too hard to refactor it out of the existing handler. At some point I will have to do it anyway to remove some of the code related to non-reducibles streams.
Guess you are also aware that the webhook recorder you are describing is kind of a "best effort" approach since you can loose events for a few reasons and a more robust solution with "at-least-once" delivery guarantees will require retries and/or backfilling logic on the producer or consumer side

You should probably build a generic utility function to do this...

Yes, I need to actually learn how to work with and write complex generics in Typescript.  I will admit I still don't understand exactly how all the typing magic works in Eventually.

Guess you are also aware that the webhook recorder you are describing is kind of a "best effort" approach since you can loose events for a few reasons....

Indeed I have run into concurrency issues with the store when webhooks arrive too fast.  I added a backed-off retry wrapper to my CatchWebhook command call which alleviated the issue.  (IMHO This sort of behavior I believe should be added to eventually with sane defaults.)
That reminds me....and it's a moot point now but when I started using a System for this type of stream I realized that the PG store implementation would allow for duplicate version numbers for system streams.  The database would block it though since there was an indexed constraint on the events table for the version field.  While I was tinkering I actually removed the constraint in the database index to allow for duplicate versions for the very reason of more reliability for writing system streams.  My reasoning for the hack was that the store implementation already did the job of enforcing contiguous version numbers for reducible streams.  I figured that I could get away the cheat for a system stream.  It helped for my use-case but indeed I should probably be flogged for doing so.
That also reminds me, the event store should probably allow writing streams without versioning for streams the don't require strict order such as these types of sub-streams.

Answered in #84


In some cases, curClass is applied to the last menu item, not to the really current one.

The problem is in the function getSection. You just should break the "for" loop after getting the first 'true' result:
`
  for(var section in onePageNav.sections) {
    if((onePageNav.sections[section] - windowHeight) < windowPos) {
      returnValue = section;
      break; // --- Add this line ---
    }
  }
  return returnValue;
};

`

Hmm, but is that really the true result? It depends if the truth is what you click or what has gone past the halfway point on the screen.


Type safe component injection

This allows to:
@ApplicationScoped
public static class Configurer {
    @Inject
    LogComponent log;

    @PostConstruct
    void setUpLogComponent() {
        log.setBasicPropertyBinding(true);
        log.setExchangeFormatter(new MyExchangeFormatter());
    }

    public LogComponent getLog() {
        return log;
    }
}

@ApplicationScoped
public static class Holder {
    private LogComponent log;

    @Inject
    public Holder(LogComponent log) {
        this.log = log;
    }

    public LogComponent getLog() {
        return log;
    }
}

Hmm would users want to write this much code for setting up a component?
You already have component dsl
https://camel.apache.org/manual/latest/component-dsl.html
Isnt there something we can do with this instead that makes this better?

Or maybe have the @Produces annotatatio (or whatever its called in CDI) In Camel you can use @BindToRegistry for this - but in Spring Boot its @Bean or @Produces or what its named.
@Produces
public LogComponent createMyFancyLogComponent(LogComponent log) {
   log.setXXXX
   return log;
}

We can make it take in itself as argument (if that is possible) where you just get a basic new LogComponent using its no-arg ctr.

We could automatically declare a ComponentsBuilderFactory bean so that users can write:
@Produces
public LogComponent createMyFancyLogComponent(ComponentsBuilderFactory builder) {
   return builder.log()...build();
}

The initial motivation behind this enhancement are:

make it possible to use @Inject to get component as you would do with @BeanInject inside a route but more familiar for CDI developer
make it possible to get a reference of a component created at build time as by using the component-dsl or by producing a custom component via @Produces one would override the component created and pre-configured at build time

We could automatically declare a ComponentsBuilderFactory bean so that users can write:
@Produces
public LogComponent createMyFancyLogComponent(ComponentsBuilderFactory builder) {
   return builder.log()...build();
}

That requires a camel-componentdsl extension, will open an issue

Created: https://github.com/apache/camel-quarkus/issues/1376


Set up CI tests

Either through package bots or some other solution, package bots may be the easiest though.

To clarify, this should have full browser support.


[MM-47041] fix escape key not closing channel switcher issue

Summary
fix escape key not closing channel switcher issue
Ticket Link
fixes https://mattermost.atlassian.net/browse/MM-47041
Related Pull Requests
NA
Screenshots
NA
Release Note
NA

Successfully triggered e2e testing!
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/244350

/e2e-test

Successfully triggered e2e testing!
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/245543

/e2e-cancel

Successfully canceled pipelines:
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/245543

/update-branch

/e2e-test

Successfully triggered e2e testing!
https://git.internal.mattermost.com/qa/cypress-ui-automation/-/pipelines/245547

@furqanmlk Should I merge it

https://mattermost-webapp-pr-11155.test.mattermost.cloud

@AshishDhama
Issue is fixed and E2E passed
Good to merge

Will try to auto merge this PR once all tests and checks are passing. This might take up to an hour.

Trying to auto merge this PR.

Cherry pick is scheduled.

Pull Request successfully merged
SHA: 45a4e4f52752a2baa2869f4843e1d23cea0dcceb

/cherry-pick cloud

Cherry pick is scheduled.


HDDS-9926. Publish WIP website to staging branch (1/2)

Part 1/2. Followed up by #56
Create a staging branch for the new website where builds can be pushed. Add a description of it in the README and auto publishing information to .asf.yaml. See staging branches for .asf.yaml documention.
Testing
I don't think changes to .asf.yaml can be tested until the change is merged.

Thanks for the review @adoroszlai. I will merge this and we can try it out with #56


chore(packages): update react and co. to 15.5.0

Closes #84

Codecov Report

Merging #85 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master      #85   +/-   ##
=======================================
  Coverage   91.89%   91.89%
=======================================
  Files           1        1
  Lines          37       37
  Branches        8        8
=======================================
  Hits           34       34
  Misses          3        3

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5fb3da2...fe7af02. Read the comment docs.

Also closes #86 and #87


AMBARI-25032 Cover Service controllers with unit tests

What changes were proposed in this pull request?
Following files to cover:
app/controllers/main/service/add_controller.js
app/controllers/main/service/item.js
How was this patch tested?
22045 passing (31s)
48 pending

Refer to this link for build results (access rights to CI server needed):
https://builds.apache.org/job/Ambari-Github-PullRequest-Builder/4725/
Test PASSed.


feat: add session key plugin abi and plugingen

https://alchemyinsights.slack.com/archives/C04RHSDSP9U/p1700594853613719?thread_ts=1700590335.741369&cid=C04RHSDSP9U

PR-Codex overview
Focus of the PR:
This PR adds a new plugin called "SessionKeyPlugin" to the accounts package.
Detailed summary:

Export SessionKeyPluginGenConfig from packages/accounts/plugindefs/index.ts.
Import dependencies and define SessionKeyPluginGenConfig in packages/accounts/plugindefs/sessionkey/config.ts.
Import dependencies and define SessionKeyPlugin and SessionKeyPluginExecutionFunctionAbi in packages/accounts/src/msca/plugins/session-key.ts.
Export SessionKeyPluginAbi in packages/accounts/plugindefs/sessionkey/abi.ts.

The following files were skipped due to too many changes: packages/accounts/plugindefs/sessionkey/abi.ts

✨ Ask PR-Codex anything about this PR by commenting with /codex {your question}

you'll need to run yarn generate again now that msca-base has the provider decorators available in it


Inject Spark default configurations

Overview : Spark Development Strategy
Branch : spark-branch
Context:
pandas-profiling relies on default configurations to do computations.
Problem:
As we integrate a spark backend, we will require different default configurations based on whether the backend is spark or pandas. Thus, get_config (in profile_report.py - see architecture diagram) needs to properly detect whether the underlying dataframe is spark or pandas, and then fetch the appropriate config.
Solution Ideas:
We could use the multimethod approach to properly dispatch a function call to the PandasSetting (inherited from the current Setting (config.py) or SparkSetting)

Hi, @chanedwin is this still open?


XLA Slow operation alarms: "The operation took ..."

Hello, we are having logs like this in our Elixir project:
The operation took 2m32.409760523s

********************************
[Compiling module _Function_4.57852891_4_in_Axon.Loop.build_batch_fn_2_.32279] Very slow compile? If you want to file a bug, run with envvar XLA_FLAGS=--xla_dump_to=/tmp/foo and attach the results.
********************************

As they are logged as errors they appear in our production logging system. I have tracked down and found that they are coming from: XLA.
Do you know if there is a way to disable them ?

There is no way to cancel it upstream, I believe. You would have to ask on the official repo, in this repo we only build the executable.

This happens from really expensive compilations. What specifically are you doing? Maybe we can find a way to simplify the executable you're trying to compile

An example would be if you're training an RNN, and unrolling the entire sequence then it will result in this error

I don't think there's anything actionable on our side, so I'm going to close this.


docs: fix css color names display

Changed the number of items per row and boom, it's fixed ;)
It's even on par with the Material Design docs on https://material.io/design/color/the-color-system.html#tools-for-picking-colors :D

Hacktoberfest ? :trollface:

@clementprevot precisely... plus it's been bugging me for a while... so may as well make it count ;)


Do you still maintain this project?

i  found this project last update was 4 years ago , do you still maintain this project?

早就没有了，以前为sails项目开发的，sails框架已经没落了


Return all symbols in navto for empty string pattern

Fixes #55483.

Does navto do an after-the-fact filter today? Or does it filter as it aggregates symbols? Also curious if you've tried this on slightly bigger codebases like VS Code or TypeScript itself.

Does navto do an after-the-fact filter today? Or does it filter as it aggregates symbols? Also curious if you've tried this on slightly bigger codebases like VS Code or TypeScript itself (for both Go To Symbol in Editor and Go To Symbol in Workspace).

Do you mean if vscode is going to filter the navto results TS Server sends? If so, it doesn't. I'll wait to merge this until we decide on the changes needed on the editor side.

We might also want to consider doing https://github.com/microsoft/TypeScript/issues/48194, but I don't know what was discussed/decided about it the last time it was brought up.

@typescript-bot perf test this

@gabritto The results of the perf run you requested are in!
Here they are:

I just remembered the benchmark sends a navto request with some pre-defined string... So the perf tests are not relevant here. But I tested this locally and there isn't a delay on the vscode codebase, but for the TS codebase there's a ~1.5s delay between the command and the results showing up.

No, I was asking if it's the case that running navTo with "getTypeFrom" will walk across the whole project and then filter the symbols based on getTypeFrom, or if the filtering is done during the walk itself.

No, I was asking if it's the case that running navTo with "getTypeFrom" will walk across the whole project and then filter the symbols based on getTypeFrom, or if the filtering is done during the walk itself.

It'll walk across all files in all the projects, collect all named declarations (if they haven't been computed yet), and then look at every named declaration to see if it matches "getTypeFrom".


question about pointpillars.egg

pointpillars.egg==info is mentioned in requirements.txt and probably is used when running setup.py
can you please mention where to install it from?

Sorry, I understood it will be built when we run setup.py
but I am facing this error when trying to run: python3 setup.py build_ext


Revise font sizes in all components for l/xl size to be at least 16px. But it's cannot be done right away, we need some time to think about it


no sound

im running the lavalink on VPS Linux server with IPv6
and the bot running on my pc and it works well but when i move the bot into the VPS the sessionId not sent idk why
i asked in lavalink's server and they said its from the client
also latest version of lavalink-client

also tried that on another RDP Windows and same thing the sessionId is not sent

Do you listen to the "sendRawData" function on the raw event?
Do you have the Voice intent enabled?
You can use the debugEvents option in the advanceOptions from the Manager, to enable the "debug" event.

Yeah i set everything
Also the same code works on my local pc normally but when i copy the code to vps it doesn't

I will try debug

If it works on your local machine but not on your remote machine it's not due to the library that's weird

If its not related to lavalink and not related to client so what is the issue

this what is shown when i activated debugEvent

The id you provide in manager.init, must be the bot's user id

thx fixed, its wierd btw


Updated typo in readme.md

The function is .printPositions() not .printPosition() 😄
Loving the library btw! Very helpful ❤

Thank you for noticing!


Fix lazy load crash async

Due to lazy load make async not work, I change the mode from lazy(select) loading to select in loading https://docs.sqlalchemy.org/en/14/orm/loading_relationships.html
In this way, there is no need to query again.  But at the same time, if we don't need relationships, it is a waste.
https://docs.sqlalchemy.org/en/14/orm/extensions/asyncio.html#synopsis-orm
And I didn't think there is other ways to solve this problem currently.

Another option is only use in specific query, but still need to pay attention to whether the schema uses lazy loading.
stmt = select(A).options(selectinload(A.bs))

Another option is only use in specific query, but still need to pay attention to whether the schema uses lazy loading.
stmt = select(A).options(selectinload(A.bs))


Fixed: #4054 Re-Write Docs for First Class Python Support [Basic Example]

Pull Request
Re-write Docs for First Class Python Support [Basic Example]
Fixes: #4054
Description
Rewrite Docs for Python 1-simple, 2-custom-build-logic and 3-multi-module Examples
Related Issues

Link to related issue #4054.

Checklist

[x] Updated Documentation

Status
Updated & Require Review!!!

Looks great, thanks!


gk-deploy check() does not take into account "Terminating" pods

Hi all.
Here is the situation: while deploying glusterfs on Kubernetes with gk-deploy, it takes a while (15 secs maybe) for the volumes to be ready (at least on my cluster).
For this reason the deploy-hekety pod cannot start right away. It eventually works (fourth or fifth try) but the check() function cannot see that the pod is running if it's not on the first line of kubectl output.
Here is an example (the terminating pods are from previous failed gk-deploy runs):
Waiting for deploy-heketi pod to start ...
Checking status of pods matching '--selector=deploy-heketi=pod':
deploy-heketi-6c7d48f8b-9wdh6   0/1       Terminating         0         28m
deploy-heketi-6c7d48f8b-9wdh6   0/1       Terminating   0         32m
deploy-heketi-6c7d48f8b-fnd7s   0/1       Terminating   0         20m
deploy-heketi-6c7d48f8b-gz7wl   0/1       Terminating   0         20m
deploy-heketi-6c7d48f8b-pgg6n   0/1       Terminating   0         46m
deploy-heketi-6c7d48f8b-rtgfj   1/1       Running   0         4m

Here is the reason why the pods are being terminated:
Events:
  Type     Reason                 Age                 From                          Message
  ----     ------                 ----                ----                          -------
  Normal   Scheduled              32m                 default-scheduler             Successfully assigned deploy-heketi-6c7d48f8b-pgg6n to kubernetes-minion-2
  Normal   SuccessfulMountVolume  32m                 kubelet, kubernetes-minion-2  MountVolume.SetUp succeeded for volume "db"
  Normal   SuccessfulMountVolume  32m                 kubelet, kubernetes-minion-2  MountVolume.SetUp succeeded for volume "heketi-service-account-token-w56ll"
  Warning  FailedMount            21m (x5 over 30m)   kubelet, kubernetes-minion-2  Unable to mount volumes for pod "deploy-heketi-6c7d48f8b-pgg6n_default(e106b34f-5e67-11e8-82af-080027169818)": timeout expired waiting for volumes to attach or mount for pod "default"/"deploy-heketi-6c7d48f8b-pgg6n". list of unmounted volumes=[config]. list of unattached volumes=[db config heketi-service-account-token-w56ll]
  Warning  FailedMount            20m (x14 over 32m)  kubelet, kubernetes-minion-2  MountVolume.SetUp failed for volume "config" : secrets "heketi-config-secret" not found
  Warning  FailedMount            19m                 kubelet, kubernetes-minion-2  Unable to mount volumes for pod "deploy-heketi-6c7d48f8b-pgg6n_default(e106b34f-5e67-11e8-82af-080027169818)": timeout expired waiting for volumes to attach or mount for pod "default"/"deploy-heketi-6c7d48f8b-pgg6n". list of unmounted volumes=[db config heketi-service-account-token-w56ll]. list of unattached volumes=[db config heketi-service-account-token-w56ll]

Technically the script is taking the Terminating pods into account. It's looking for any pods that match a given pod selector, and then making sure all of them are reporting ready, in this case 1/1. If there are any pods that aren't 1/1, check() will loop until they do or timeout is hit.
The real question is why those Terminating pods are lingering so long. What was the error that cause you to try and redeploy in the first place? Can you abort, do a force delete on all remaining pods, and try again? If so, check to see if kubelet has logged anything useful about these mount failures.

I'll see if I can reproduce the issue...

Any luck reproducing the issue?
I'll close this if I don't hear anything within the week.

Hi @jarrpa
I was not able to reproduce the terminating containers issue.... :(

Closing this for now.


Add LVARRAY_ERROR_IF_PRINTF() macro to prinnt fancyer messages on errors

Attempt to solve issue #254.
Added new macro to use printf on device with clearer message.
Still not perfect, we don't know were we are when the error is raised.
Now the dimensions are correctly printed:
***** ERROR
***** LOCATION: /work206/workrd/users/lacoste_x/remote_builds/GEOSX/src/coreComponents/LvArray/src/ArraySlice.hpp:295
***** Block: [3, 0, 0]
***** Thread: [16, 0, 0]
***** Controlling expression (should be false): index < 0 || index >= m_dims[ 0 ]
***** MSG: Array Bounds Check Failed: index=8 m_dims[0]=8

PRId64 is in inttypes.h https://www.cplusplus.com/reference/cinttypes/,
Int are casted into int64 to be sure not to have overflow.

Any reason you closed this, it seems quite nice.

It raised errors in geosx that i failed to fix. And i have no time at the
moment to do it.
You can reopen if you want.
Regards,
XL
Le mar. 7 juin 2022, 18:59, Ben Corbett @.***> a écrit :

Any reason you closed this, it seems quite nice.
—
Reply to this email directly, view it on GitHub
https://github.com/GEOSX/LvArray/pull/255#issuecomment-1148931613, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAL44MTWSSLOKQSY6SLZJ23VN55X7ANCNFSM5RVPHDXQ
.
You are receiving this because you modified the open/close state.Message
ID: @.***>


Fix date parsing in scienta reader

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 2 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 84.925%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pynxtools_xps/scienta/scienta_mappings.py
0
2
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2997

Relevant Lines:
3529

💛  - Coveralls

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 2 (0.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 84.925%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pynxtools_xps/scienta/scienta_mappings.py
0
2
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
2997

Relevant Lines:
3529

💛  - Coveralls


elm-make hangs on type mismatch

Made a small type error that apparently puts elm-make indefinitely in a busy loop:
minMax list =
  case list of
    x :: xs ->
      let
        step a (lo, hi) = (min a lo, max a hi)
      in
        List.foldl step x xs   -- should be (x, x) here

    [] ->
      Debug.crash "don't care"

elm-make 0.17 (Elm Platform 0.17.0) installed with brew install elm on El Capitan.

I think this is a duplicate of https://github.com/elm-lang/elm-compiler/issues/1231


Two different plugin set for Vim and Neovim

Should I prepare two different bundle path for Vim and Neovim if they use different plugin sets?  I just found I have to use the following function calls to make the proper plugin set working correctly when I switch back and forth.
call dein#clear_state() | call dein#recache_runtimepath()

The only way I can think about to solve this problem is to create two bundle folders for Vim and Neovim. Does there any better way to solve this problem?
Any help would be much appreciated.
Mark

no need you can use {merge : 0} ,the plugin will not be copy to cache dir,also you can use if has('nvim') block

Yes, so no problem.

I see, it works great. Thanks for your help!

One more question, does there any function to regenerate merged folder?

call dein#recache_runtimepath()

I see, so dein#recache_runtimepath() regenerate everything. Thanks.

To load less plugins in nvim, for example, instead of
  call dein#add('Shougo/deoplete.nvim')

you do
  if !has('nvim') | call dein#add('Shougo/deoplete.nvim',{'merged':0}) | endif

After this change you need to call one time
call dein#recache_runtimepath()

else you will get Duplicated source: around  Use :messages / see above for error details.

if is better for it.  :help dein-options-if
call dein#add('Shougo/deoplete.nvim',{'if': `has("nvim")`})

This worked:
call dein#add('Shougo/deoplete.nvim',{'if':'!has("nvim")','merged':0})


How to raise an Exception

This is not a bug but a support request.
Is there a way to raise a specific exception with moto?
I mean, I have a client, and when it is called by some arguments, I would like to raise an Exception.
Thanks you

Hi @KiraPC, Moto should throw the same exceptions as AWS does, if all the requirements are met (missing parameters, invalid values, etc).
There's no build-in method to force an error though.
Which exception do you need to raise, on which service/method?

Hi @bblommers thanks you for the quickly response.
No specific exception, I was just thinking about some possibile scenarios in my application tests.
Anyway, I got the point, I'll try to figured out in another way.


CVDP overwrites data when run on multiple models

If run on multiple models the CVDP output looks ok on the first glance (as many *.nc files as models, as many panels in each figure as models), but all of these data sets and panels contain the same data (most probably only from one of these models).
Recipe: recipe_cvdp.yml

The reason for the overwriting of data iss, that the at the point where cvdp_wrapper.py writes the master namefile for the *.ncl program () the model name is not part of the path.
This causes the namelist_byvar point to all data sets (with *) and not to one specific one. Therefore only one (last or first I guess) is read in by the *.ncl routines.
Changing:
<
    content.append("{0} | {1} | {2} | {3}\n".format(
        attributes[0]["alias"], ppath, attributes[0]["start_year"],
        attributes[0]["end_year"]))

to
<
    content.append("{0} | {1}{0} | {2} | {3}\n".format(
        attributes[0]["alias"], ppath, attributes[0]["start_year"],
        attributes[0]["end_year"]))

solves that.


Prerelease/list with parent record data tests

What does this PR do?
Adds LWC tests for the listWithParentRecordData component.
These tests provide 100% line coverage. The branch coverage is artificially low as the only if statement has an unreachable branch.
What issues does this PR fix or reference?
n/a
The PR fulfills these requirements:
[x] Tests for the proposed changes have been added/updated.
[x] Code linting and formatting was performed.
Functionality Before
n/a
Functionality After

@pozil comments resolved, please reeval


Evaluate case with trailing spaces and

For instance, this:
  - input: ":services.esper.net MODE #foo-bar +o foobar  "
    atoms:
      source: "services.esper.net"
      verb: "MODE"
      params:
        - "#foo-bar"
        - "+o"
        - "foobar"
- ""

This case is very dodgy and handled very strangely by various software. Look at it more closely, see what software does today and how it tends to be handled, update Modern with what we decide.
08:31:11 < SaberUK> 1459 says:
08:31:11 < SaberUK> "all parameters are separated by one (or more) ASCII space character(s) (0x20)."
08:31:11 < SaberUK> "<middle>   ::= <Any *non-empty* sequence of octets not including SPACE or NUL or CR or LF, the first of which may not be ':'>"

Decided to go with the 'common behaviour' of making them trailing, see fef8835d2f24246ce960bbc13d9f2a2a9a911162