Using date picker without inputElement

Hi
I am trying to use the date picker without the date picker being in control of where the selected date is written.
I am doing this using something like this
 <!doctype html>
<html>
<head>
    <script src='../bower_components/webcomponentsjs/webcomponents-lite.js'></script>
    <link rel='import' href='../bower_components/vaadin-date-picker/vaadin-date-picker-light.html'>
    <link rel='import' href='../bower_components/paper-button/paper-button.html'>
</head>
<body unresolved>
    <dom-module id='base-page'>
        <template>
            <paper-button on-tap='tap'>Click me</paper-button>
            <vaadin-date-picker-light id='myDateTime' value='{{myDate}}'>
            </vaadin-date-picker-light>
        </template>
    </dom-module>
    <script>
        HTMLImports.whenReady(function() {Polymer({
            is: 'base-page',
            properties: {
                myDate: {
                    type: String,
                    value: '',
                    observer: '_myDateChanged'
                }
            },

            _myDateChanged: function() {

            },

            tap: function() {
                this.$.myDateTime.open();
            }
        });});
    </script>
    <base-page></base-page>
</body>

But whenever I select a date it throws an error
vaadin-date-picker-behavior.html:349 Uncaught TypeError: Cannot read property 'focus' of null
_focus: function() {
  this.inputElement.focus();
},

How can I use the date picker without an input element?

Hi! It is not possible to use the vaadin-date-picker-light element without an input element.
I would suggest to try placing a hidden input element inside the vaadin-date-picker-light as a workaround.
You can also try to use the vaadin-date-picker-overlay instead of vaadin-date-picker-light in your element.


chore(build): switched build system to Gulp

Fixes #38
Changes:

Replicated the build system using Gulp.
Added "serve" task to spawn a webserver
Webserver will listen for changes and auto-reload using liveReload
Fixed https://docs.angularjs.org/error/$location/nobase
Added correct 404 template

Todo:

[x] Karma unit test task
[x] Eslint linting task
[x] Remove Gruntfile and Grunt dependencies

Run gulp serve to spawn the webserver and browse to http://localhost:9000/example.
All changes made in either the example folder or src folder will automatically reload the browser page.
No LiveReload browser extension required, gulp-connect uses https://github.com/mklabs/tiny-lr.

Any outstanding issues on this PR?

@MichielDeMey sorry for the delay. was travelling recently.
LGTM. Thanks for the contributions!!! :smile:


Improved parsing finatra request models.

Currently when processing request model standard swagger annotations are not respected. That means that class:
case class StudentWithRoute(
  @RouteParam id: String,
  @Inject request: Request,
  @ApiModelProperty(name = "first_name", required = true) firstName: String,
  @ApiModelProperty(name = "first_name", required = true) lastName: String,
  gender: Gender,
  birthday: LocalDate,
  grade: Int,
  emails: Array[String],
  address: Option[Address]
)

is resolved to:
{
  "firstName": "string",
  "lastName": "string",
  "gender": "Male",
  "birthday": "2019-04-09",
  "grade": 0,
  "emails": [
    "string"
  ],
  "address": {
    "street": "string",
    "zip": "string"
  }
}

rather than:
{
  "first_name": "string",
  "last_name": "string",
  "gender": "Male",
  "birthday": "2019-04-09",
  "grade": 0,
  "emails": [
    "string"
  ],
  "address": {
    "street": "string",
    "zip": "string"
  }
}

The purpose of this change is to leverage vanilla swaggerModelConverters when processing finatra Request model rather than rely on custom ast generation. Thanks that standard swagger annotations (like ApiModelProperty) are respected when docs for body parameter are generated. Also more complex types (like a hash map of objects) are properly represented.

@lukhar Thanks for this fix!!!

@lukhar Built a version 19.3.1 that includes this fix, should be in sonatype tomorrow


custom-config.json is now replacing the default-config.json

The custom-config.json is now replacing the default-config.json. The default-config.json was still used when running a private docker base and this caused the local query interface to query wikidata instead of the local instance.
There might be a better solution in which it automatically detects the template but I am not aware of such method.

Name change conserved in entrypoint.sh update

The jenkins failure is because of https://docs.travis-ci.com/user/pull-requests/#pull-requests-and-security-restrictions
I don't have any easy way to test if it's actually green or red. Let me check.


OSError: dlopen: cannot load any more object with static TLS

getting this error when running the code

Generally, this seems to occur when you are importing python modules that dynamically load in libraries at run time. The native libraries that the gym monitor loads in to help create a display for visualization could potentially trigger this error. When multiple libraries are dynamically loaded for a single program, some kind of circular dependency bug will occasionally happen that causes the static TLS error - here's a detailed explanation https://gcc.gnu.org/ml/gcc/2015-02/msg00097.html. It probably also has to do with what specific platform you're running on, etc.
I've never experienced this error while running this code, but I would suggest changing the order of imports as you run it (this seemed to fix this problem when I saw it occur elsewhere)  and making sure you're only importing python modules that you really need.

I'm running this in Ubuntu 14.04 without GPU. I haven't changed anything in your code so I am just trying to run your code itself. I did try rearranging the import but I still get an error. The code only works if I set RENDER_ENV= False.

Then it sounds like the error occurs when OpenAI gym’s pyglet dependency is loading the native libraries it uses for graphics rendering. I am not sure what exactly is going on at that level that causes this problem, sorry. Not really anything I can do to help

Then it sounds like the error occurs when OpenAI gym’s pyglet dependency is loading the native libraries it uses for graphics rendering. I am not sure what exactly is going on at that level that causes this problem, sorry. Not really anything I can do to help

On Oct 24, 2016, at 1:34 PM, Gabriel de la Cruz<EMAIL_ADDRESS>wrote:
I'm running this in Ubuntu 14.04 without GPU. I haven't changed anything in your code so I am just trying to run your code itself. I did try rearranging the import but I still get an error. The code only works if I set RENDER_ENV= False.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub https://github.com/pemami4911/deep-rl/issues/1#issuecomment-255809475, or mute the thread https://github.com/notifications/unsubscribe-auth/AF_H3Zkh-Z6JXXY_vB1uBFadlPD8pceAks5q3OwKgaJpZM4KZPqR.


Template string literal highlighting breaks on ternary operator with typeof

Bug Report
🔎 Search Terms
template string literal highlighting
🕗 Version & Regression Information
VSCode 1.53.2 + TypeScript 4.1.5
⏯ Playground Link
Workbench Repro
Workbench Repro
💻 Code
function HighlightingWorksFineHere(): void {}
`${0 ? typeof 0 ? 0 : 0 : 0}`;
function ButHereItIsBroken(): void {}

function HighlightingWorksFineHere(): void {}
`${0 ? typeof 0 : 0}`;
function ButHereItIsBroken(): void {}

🙁 Actual behavior
Highlighting breaks after template literal with ternary operator and typeof in VSCode (seems fine in playground though), looks like the closing backtick is not recognized or treated as opening backtick.

This seems to be fixed in VSCode Insiders. Specifically, using VSCode 1.56.0-insider.


Add License

Greets...
Any chance you can add a license to this repo? Thanks!

The license is MIT. I added the LICENSE file in the repo.
Thanks for the feed-back!


DateTime field not indexed

Looking into the bundle while running a solr:index:populate certain entities do not get indexed. While doing some debugging I ended up with a \DateTime object which was trying to be used as an entity/document.
    /**
     * @var \DateTime
     *
     * @Solr\Field(type="date")
     *
     * @ORM\Column(name="timestamp_start", type="datetime", nullable=true)
     */
    private $timestampStart;

So because it is not a string representation it's skipping the indexing for the entity with this property entirely. When I remove this field definition (only text-type fields are left then), the indexing runs smoothly.

it is now possible to specify the getter property with parameters. In your case
    /**
     * @var \DateTime
     *
     * @Solr\Field(type="datetime", getter="format('d.m.Y')")
     *
     * @ORM\Column(name="timestamp_start", type="datetime", nullable=true)
     */
    private $timestampStart;


Track file hash references

When creating uploads, a separate datastructure is also incrementally built; files/{id}/hashes/{id}/uploads/{id}. This allows going file->upload in the future.

Also, this closes #51 .

Wait -- this closes #50 .


Get latest stable release when adding a plugin without specifiying a version number

Need a fix here;
When didn't specify the version number, we download the version 1.0.0 now. The requirement is download the latest stable release when that;
Need to find a way to fix it.
Ref-

http://wpquestions.com/Find_url_to_current_version_of_a_plugin_from_outside_wordpress/4291

Seems like we can use; just https://downloads.wordpress.org/plugin/.zip for this. But need to do some research on this.


Cleanup set to true?

Should the cleanup be set to true by default or not [1]? Should it be set by the variable in the constructor?
[1]https://github.com/radical-cybertools/radical.ensemblemd/blob/master/src/radical/ensemblemd/single_cluster_environment.py#L129

It is fixed in devel


Cross-platform contribution scripts

Currently the scripts for the Fountain implementation, only seems feasible for Unix systems.
Please allow more cross-platform availability for other developers willingly to develop on Windows.

I will have to port the scripts to python I guess :)

MinGW has everything you need. I think adding Python scripts would complicate things.

@phase Python scripts won't complicate things, it'd make it much much simpler :)
Especially since I coded a python patch library

You can't beat the original. Just leave the shells ones in the folder, I (and maybe others) will use them.


[5.4] Add missing fire method to contract.

Add missing fire method.

I renamed it to dispatch on 5.4 to match the class name.


Fix: Set Karpenter Consolidation Timeouts to zero

Fixes #N/A
Description
Set Karpenter Consolidation Timeouts to zero so metrics are fired even when there are no timeouts
How was this change tested?
make presubmit
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Pull Request Test Coverage Report for Build<PHONE_NUMBER>1
Details

4 of 4 (100.0%)  changed or added relevant lines in 2 files are covered.
8 unchanged lines in 3 files lost coverage.
Overall coverage decreased (-0.004%) to 80.608%

Files with Coverage Reduction
New Missed Lines
%

pkg/controllers/node/termination/controller.go
2
71.65%

pkg/controllers/disruption/drift.go
2
89.66%

pkg/controllers/disruption/consolidation.go
4
88.55%

Totals

Change from base Build<PHONE_NUMBER>4:
-0.004%

Covered Lines:
8904

Relevant Lines:
11046

💛  - Coveralls


Done.

I think that's it.

:shipit:

I added a little bit of styling so that the order book looks more symmetric


Crash con project init with typescript

Bug Report
Crash on project init
To Reproduce

Run npx create-docz-app docz-ts --example typescript

~/ssg-comparison> npx create-docz-app docz-ts --example typescript
Need to install the following packages:
  create-docz-app
Ok to proceed? (y)
Creating a new Docz app in /Users/anon/ssg-comparison/docz-ts.

Downloading files for example typescript. This might take a moment.

Aborting installation.
Unexpected error. Please report it as a bug:
TypeError: e.destroy is not a function
    at /Users/anon/.npm/_npx/f6e6de91721365f0/node_modules/create-docz-app/dist/index.js:2:35630
    at Array.forEach (<anonymous>)
    at /Users/anon/.npm/_npx/f6e6de91721365f0/node_modules/create-docz-app/dist/index.js:2:35573
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async Promise.all (index 0)

closing thiis because we don't officially support create-docz-app, so we strongly recommend you to add docz directly as a dependency instead, or then, open this issue on https://github.com/rakannimer/create-docz-app. Anyways, try to follow the getting started steps from our site on https://docz.site, or on https://github.com/doczjs/docz#getting-started


Bump to 0.6.10

Still trying to get all pending PRs landed... Slow CI is making this tricky!

I landed a bunch of PRs, so the changelog needs updating (I can try to do it in a bit). Besides that, it should be ready to land.

updated


Escape all remaining reserved chars in direct_fog_url

This fixes using direct_fog_url with files that have these ?:[] in the filename.
From URI::Parser
URI regexp pattern for rel_segment
RESERVED = ";/?:@&=+$,\[\]"
rel_segment   = ( unreserved | escaped |
";" | "@" | "&" | "=" | "+" |
"$" | "," )
Hence, '?:[]' need to be escaped for the URI path to not throw exceptions on parsing.

This has been fixed on master by letting carrierwave generate the urls with #155


Karpenter kept scheduling pod on Node which has not enough resources

Version

Karpenter: v0.13.0

Kubernetes: v1.20.0
Expected Behavior
Karpenter should Provision nodes, the pods were in pending state for 13 hours and the logs repeatedly said
2022-08-17T15:29:03.786Z	DEBUG	controller.events	Normal	{"commit": "062a029", "object": {"kind":"Pod","namespace":"payment-orchestrator","name":"payment-orchestrator-test-us-east-1-master-template-766d7c6dxml","uid":"cfa1fce9-c4d5-4b9e-a75b-93d5408c4ab0","apiVersion":"v1","resourceVersion":"381957916"}, "reason": "NominatePod", "message": "Pod should schedule on ip-10-74-7-176.ec2.internal"}
Actual Behavior

Karpenter should provision new nodes and not keep retrying on the batched one, if there is space/memory constraint.
The cpu left on the node was 2249m and requested CPU by the pod was 2700m totalling all the sidecars that are injected through the Webhooks.
Still Karpenter kept on trying to schedule the pod on the node which didn't have much capacity.
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests      Limits
  --------                    --------      ------
  cpu                         13641m (85%)  50400m (317%)
  memory                      9992Mi (35%)  27360Mi (96%)

Steps to Reproduce the Problem
There should be atleast one node in the Cluster which has enough capacity to accomodate the main container of the pod but not the sidecars (This is only theory my team could come up with, not sure how exactly to reproduce )
Resource Specs and Logs

Karpenter Controller logs:
2022-08-17T15:29:03.786Z	DEBUG	controller.events	Normal	{"commit": "062a029", "object": {"kind":"Pod","namespace":"payment-orchestrator","name":"payment-orchestrator-test-us-east-1-master-template-766d7c6dxml","uid":"cfa1fce9-c4d5-4b9e-a75b-93d5408c4ab0","apiVersion":"v1","resourceVersion":"381957916"}, "reason": "NominatePod", "message": "Pod should schedule on ip-10-74-7-176.ec2.internal"}
Provisioner Spec:
spec:
  labels:
    karpenter-provisioner-type: standard
  provider:
    apiVersion: extensions.karpenter.sh/v1alpha1
    kind: AWS
    launchTemplate: karpenter-rcp
    subnetSelector:
      purpose_app: 'true'
    tags:
      karpenter-provisioner-type: standard
  requirements:
    - key: topology.kubernetes.io/zone
      operator: In
      values:
        - us-east-1a
        - us-east-1b
        - us-east-1c
    - key: kubernetes.io/arch
      operator: In
      values:
        - amd64
    - key: karpenter.sh/capacity-type
      operator: In
      values:
        - on-demand
        - spot
    - key: node.kubernetes.io/instance-type
      operator: NotIn
      values:
        - a1.2xlarge
        - a1.large
        - a1.medium
        - a1.xlarge
        - c1.medium
        - <BIG_LIST>
  ttlSecondsAfterEmpty: 30
  ttlSecondsUntilExpired: 2592000

Pod Containers:
kubectl -n payment-orchestrator get pod payment-orchestrator-test-us-east-1-master-template-766d7c6dxml -o yaml |grep req -A2
      requests:
        cpu: 100m
        memory: 128Mi
--
      requests:
        cpu: "2"
        memory: 6Gi
--
      requests:
        cpu: 250m
        memory: 64Mi
--
      requests:
        cpu: 250m
        memory: 64Mi
--
      requests:
        cpu: 100m
        memory: 128Mi

Pod events screenshot:
As you can see the event count is 721 and it kept on retrying.

Can you provide the full pod spec and the allocatable section of the resources from the node?

Pod Spec:
Few values are Redacted. Dont have the pod spec for that same pod, but for another which was also in the same state and was under same ReplicaSet so it has same spec.
apiVersion: v1
kind: Pod
metadata:
  name: payment-orchestrator-test-us-east-1-master-template-cb855cq7x2f
  generateName: payment-orchestrator-test-us-east-1-master-template-cb855cbc5-
  namespace: payment-orchestrator
  uid: 7b414f42-8ea1-467a-aaf4-e4f5ae86893e
  resourceVersion: '382064789'
  creationTimestamp: '2022-08-17T05:30:49Z'
  labels:
    admission.datadoghq.com/enabled: 'true'
    app: payment-orchestrator--test-us-east-1-master
    app.expediagroup.com/asset-protection-level: '99'
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/name: payment-orchestrator
    app.kubernetes.io/version: d2045fa78b728936ccabd1fc59c765fccb8359d5
    helm.sh/chart: paved-road-service-7.0.0
    island.expediagroup.com/name: orders
    k8s.expediagroup.com/installation-name.short: payment-orchestrator--branch-master
    k8s.expediagroup.com/installation-name.structured.application: payment-orchestrator
    k8s.expediagroup.com/installation-name.structured.classifier.branch: master
    k8s.expediagroup.com/instance: master
    k8s.expediagroup.com/reason: branch
    k8s.expediagroup.com/release: test-us-east-1
    pod-template-hash: cb855cbc5
    product.expediagroup.com/name: payment-orchestrator
    progressivedeployment.expediagroup.com/variant: template
    security.istio.io/tlsMode: istio
    service.istio.io/canonical-name: payment-orchestrator
    service.istio.io/canonical-revision: d2045fa78b728936ccabd1fc59c765fccb8359d5
    tags.datadoghq.com/service: payment-orchestrator
    tags.datadoghq.com/slug: us-east-1-template
    tags.datadoghq.com/version: d2045fa78b728936ccabd1fc59c765fccb8359d5
    team.expediagroup.com/cost-center: '95193'
    version: d2045fa78b728936ccabd1fc59c765fccb8359d5
  annotations:
    app.expediagroup.com/data-classification: '<REDACTED>'
    app.expediagroup.com/service-tier: '<REDACTED>'
    capability.expediagroup.com/name: '<REDACTED>'
    domain.expediagroup.com/name: '<REDACTED>'
    island.expediagroup.com/account: '<REDACTED>'
    k8s.expediagroup.com/inject-vars: payment-orchestrator
    k8s.expediagroup.com/inject-vars-type: '<REDACTED>'
    k8s.expediagroup.com/installation-name.full: payment-orchestrator--branch-master
    kubectl.kubernetes.io/default-container: payment-orchestrator
    kubectl.kubernetes.io/default-logs-container: payment-orchestrator
    kubernetes.io/psp: eks.privileged
    prometheus.io/path: /stats/prometheus
    prometheus.io/port: '15020'
    prometheus.io/scrape: 'true'
    sidecar.istio.io/status: >-
      {"initContainers":["istio-init"],"containers":["istio-proxy"],"volumes":["workload-socket","workload-certs","istio-envoy","istio-data","istio-podinfo","istio-token","istiod-ca-cert"],"imagePullSecrets":null,"revision":"default"}
    splunk.com/index: ecp-ord-oms
    team.expediagroup.com/name: '<REDACTED>'
    vault.hashicorp.com/agent-init-first: 'true'
    vault.hashicorp.com/agent-inject: 'true'
    vault.hashicorp.com/agent-inject-perms-secrets.json: '0664'
    vault.hashicorp.com/agent-inject-secret-secrets.json: orders/payment-orchestrator/kv-v2/data/payment-orchestrator/secrets
    vault.hashicorp.com/agent-inject-status: injected
    vault.hashicorp.com/agent-inject-template-secrets.json: >-
      {{- with secret
      "orders/payment-orchestrator/kv-v2/data/payment-orchestrator/secrets" }}
         {{- .Data.data | toUnescapedJSON }}
      {{- end }}
    vault.hashicorp.com/agent-inject-token: 'false'
    vault.hashicorp.com/agent-run-as-user: '100'
    vault.hashicorp.com/namespace: lab/islands
    vault.hashicorp.com/role: payment-orchestrator.payment-orchestrator-test-us-east-1-master-template
  ownerReferences:
    - apiVersion: apps/v1
      kind: ReplicaSet
      name: payment-orchestrator-test-us-east-1-master-template-cb855cbc5
      uid: dcde033c-3899-42d0-aa3e-a1842f05d61b
      controller: true
      blockOwnerDeletion: true
  selfLink: >-
    /api/v1/namespaces/payment-orchestrator/pods/payment-orchestrator-test-us-east-1-master-template-cb855cq7x2f
spec:
  volumes:
    - name: workload-socket
      emptyDir: {}
    - name: workload-certs
      emptyDir: {}
    - name: istio-envoy
      emptyDir:
        medium: Memory
    - name: istio-data
      emptyDir: {}
    - name: istio-podinfo
      downwardAPI:
        items:
          - path: labels
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.labels
          - path: annotations
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.annotations
        defaultMode: 420
    - name: istio-token
      projected:
        sources:
          - serviceAccountToken:
              audience: istio-ca
              expirationSeconds: 43200
              path: istio-token
        defaultMode: 420
    - name: istiod-ca-cert
      configMap:
        name: istio-ca-root-cert
        defaultMode: 420
    - name: kube-api-access-chcnd
      projected:
        sources:
          - serviceAccountToken:
              expirationSeconds: 3607
              path: token
          - configMap:
              name: kube-root-ca.crt
              items:
                - key: ca.crt
                  path: ca.crt
          - downwardAPI:
              items:
                - path: namespace
                  fieldRef:
                    apiVersion: v1
                    fieldPath: metadata.namespace
        defaultMode: 420
    - name: home-init
      emptyDir:
        medium: Memory
    - name: home-sidecar
      emptyDir:
        medium: Memory
    - name: vault-secrets
      emptyDir:
        medium: Memory
  initContainers:
    - name: vault-agent-init
      image:<PHONE_NUMBER>37.dkr.ecr.us-east-1.amazonaws.com/library/eg-vault:1.8.1
      command:
        - /bin/sh
        - '-ec'
      args:
        - >-
          echo ${VAULT_CONFIG?} | base64 -d > /home/vault/config.json && vault
          agent -config=/home/vault/config.json
      env:
        - name: VAULT_LOG_LEVEL
          value: info
        - name: VAULT_LOG_FORMAT
          value: standard
        - name: VAULT_CONFIG
          value: >-
            eyJhdXRvX2F1dGgiOnsibWV0aG9kIjp7InR5cGUiOiJrdWJlcm5ldGVzIiwibW91bnRfcGF0aCI6ImF1dGgva3ViZXJuZXRlcy9vcmRlcnMtZWdvcmRlcnMtdGVzdC11cy1lYXN0LTEtcmNwIiwibmFtZXNwYWNlIjoibGFiL2lzbGFuZHMiLCJjb25maWciOnsicm9sZSI6InBheW1lbnQtb3JjaGVzdHJhdG9yLnBheW1lbnQtb3JjaGVzdHJhdG9yLXRlc3QtdXMtZWFzdC0xLW1hc3Rlci10ZW1wbGF0ZSJ9fSwic2luayI6W3sidHlwZSI6ImZpbGUiLCJjb25maWciOnsicGF0aCI6Ii9ob21lL3ZhdWx0Ly52YXVsdC10b2tlbiJ9fV19LCJleGl0X2FmdGVyX2F1dGgiOnRydWUsInBpZF9maWxlIjoiL2hvbWUvdmF1bHQvLnBpZCIsInZhdWx0Ijp7ImFkZHJlc3MiOiJodHRwczovL3ZhdWx0LWVudGVycHJpc2Uuc2VjcmV0cy5ydW50aW1lLnRlc3QtY3RzLmV4cC1hd3MubmV0In0sInRlbXBsYXRlIjpbeyJkZXN0aW5hdGlvbiI6Ii92YXVsdC9zZWNyZXRzL3NlY3JldHMuanNvbiIsImNvbnRlbnRzIjoie3stIHdpdGggc2VjcmV0IFwib3JkZXJzL3BheW1lbnQtb3JjaGVzdHJhdG9yL2t2LXYyL2RhdGEvcGF5bWVudC1vcmNoZXN0cmF0b3Ivc2VjcmV0c1wiIH19XG4gICB7ey0gLkRhdGEuZGF0YSB8IHRvVW5lc2NhcGVkSlNPTiB9fVxue3stIGVuZCB9fSAgICAgICAgICIsImxlZnRfZGVsaW1pdGVyIjoie3siLCJyaWdodF9kZWxpbWl0ZXIiOiJ9fSIsInBlcm1zIjoiMDY2NCJ9XSwidGVtcGxhdGVfY29uZmlnIjp7ImV4aXRfb25fcmV0cnlfZmFpbHVyZSI6dHJ1ZX19
      resources:
        limits:
          cpu: 500m
          memory: 128Mi
        requests:
          cpu: 250m
          memory: 64Mi
      volumeMounts:
        - name: home-init
          mountPath: /home/vault
        - name: kube-api-access-chcnd
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        - name: vault-secrets
          mountPath: /vault/secrets
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: IfNotPresent
      securityContext:
        capabilities:
          drop:
            - ALL
        runAsUser: 100
        runAsGroup: 1000
        runAsNonRoot: true
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false
    - name: istio-init
      image: >-
<PHONE_NUMBER>37.dkr.ecr.us-east-1.amazonaws.com/thirdparty/docker.io/istio/proxyv2:1.14.1-distroless
      args:
        - istio-iptables
        - '-p'
        - '15001'
        - '-z'
        - '15006'
        - '-u'
        - '1337'
        - '-m'
        - REDIRECT
        - '-i'
        - '*'
        - '-x'
        - ''
        - '-b'
        - '*'
        - '-d'
        - 15090,15021,15020
      env:
        - name: BOOTSTRAP_XDS_AGENT
          value: 'true'
      resources:
        limits:
          cpu: '2'
          memory: 1Gi
        requests:
          cpu: 100m
          memory: 128Mi
      volumeMounts:
        - name: vault-secrets
          mountPath: /vault/secrets
        - name: kube-api-access-chcnd
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: IfNotPresent
      securityContext:
        capabilities:
          add:
            - NET_ADMIN
            - NET_RAW
          drop:
            - ALL
        privileged: false
        runAsUser: 0
        runAsGroup: 0
        runAsNonRoot: false
        readOnlyRootFilesystem: false
        allowPrivilegeEscalation: false
  containers:
    - name: istio-proxy
      image: >-
        <REDACTED>.dkr.ecr.us-east-1.amazonaws.com/thirdparty/docker.io/istio/proxyv2:1.14.1-distroless
      args:
        - proxy
        - sidecar
        - '--domain'
        - $(POD_NAMESPACE).svc.cluster.local
        - '--proxyLogLevel=warning'
        - '--proxyComponentLogLevel=misc:error'
        - '--log_output_level=default:info'
        - '--concurrency'
        - '4'
      ports:
        - name: http-envoy-prom
          containerPort: 15090
          protocol: TCP
      env:
        - name: JWT_POLICY
          value: third-party-jwt
        - name: PILOT_CERT_PROVIDER
          value: istiod
        - name: CA_ADDR
          value: istiod.istio-system.svc:15012
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: INSTANCE_IP
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.podIP
        - name: SERVICE_ACCOUNT
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.serviceAccountName
        - name: HOST_IP
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.hostIP
        - name: PROXY_CONFIG
          value: >
            {"concurrency":4,"tracing":{"datadog":{"address":"datadog-agent.datadog.svc.cluster.local:8126"},"maxPathTagLength":256,"sampling":1},"proxyMetadata":{"BOOTSTRAP_XDS_AGENT":"true"},"holdApplicationUntilProxyStarts":true}
        - name: ISTIO_META_POD_PORTS
          value: |-
            [
                {"name":"http","containerPort":8080,"protocol":"TCP"}
            ]
        - name: ISTIO_META_APP_CONTAINERS
          value: payment-orchestrator
        - name: ISTIO_META_CLUSTER_ID
          value: Kubernetes
        - name: ISTIO_META_INTERCEPTION_MODE
          value: REDIRECT
        - name: ISTIO_META_WORKLOAD_NAME
          value: payment-orchestrator-test-us-east-1-master-template
        - name: ISTIO_META_OWNER
          value: >-
            kubernetes://apis/apps/v1/namespaces/payment-orchestrator/deployments/payment-orchestrator-test-us-east-1-master-template
        - name: ISTIO_META_MESH_ID
          value: orders.test.exp-aws.net
        - name: TRUST_DOMAIN
          value: orders.test.exp-aws.net
        - name: BOOTSTRAP_XDS_AGENT
          value: 'true'
        - name: ISTIO_KUBE_APP_PROBERS
          value: >-
            {"/app-health/payment-orchestrator/livez":{"httpGet":{"path":"/healthcheck/status","port":8080,"scheme":"HTTP"},"timeoutSeconds":20},"/app-health/payment-orchestrator/readyz":{"httpGet":{"path":"/healthcheck/status","port":8080,"scheme":"HTTP"},"timeoutSeconds":20},"/app-health/payment-orchestrator/startupz":{"httpGet":{"path":"/healthcheck/status","port":8080,"scheme":"HTTP"},"timeoutSeconds":20}}
      resources:
        limits:
          cpu: '2'
          memory: 1Gi
        requests:
          cpu: 100m
          memory: 128Mi
      volumeMounts:
        - name: workload-socket
          mountPath: /var/run/secrets/workload-spiffe-uds
        - name: workload-certs
          mountPath: /var/run/secrets/workload-spiffe-credentials
        - name: istiod-ca-cert
          mountPath: /var/run/secrets/istio
        - name: istio-data
          mountPath: /var/lib/istio/data
        - name: istio-envoy
          mountPath: /etc/istio/proxy
        - name: istio-token
          mountPath: /var/run/secrets/tokens
        - name: istio-podinfo
          mountPath: /etc/istio/pod
        - name: vault-secrets
          mountPath: /vault/secrets
        - name: kube-api-access-chcnd
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      readinessProbe:
        httpGet:
          path: /healthz/ready
          port: 15021
          scheme: HTTP
        initialDelaySeconds: 1
        timeoutSeconds: 3
        periodSeconds: 2
        successThreshold: 1
        failureThreshold: 30
      lifecycle:
        postStart:
          exec:
            command:
              - pilot-agent
              - wait
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: IfNotPresent
      securityContext:
        capabilities:
          drop:
            - ALL
        privileged: false
        runAsUser: 1337
        runAsGroup: 1337
        runAsNonRoot: true
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false
    - name: payment-orchestrator
      image: >-
        <REDACTED>/library/payment-orchestrator:d2045fa78b728936ccabd1fc59c765fccb8359d5
      ports:
        - name: http
          containerPort: 8080
          protocol: TCP
      env:
        - name: AWS_REGION
          value: us-east-1
        - name: DD_LOGS_INJECTION
          value: 'true'
        - name: DD_TRACE_DB_CLIENT_SPLIT_BY_DOMAIN
          value: 'true'
        - name: DD_TRACE_DB_CLIENT_SPLIT_BY_INSTANCE
          value: 'true'
        - name: DD_TRACE_SPLIT_BY_TAGS
          value: >-
            aws.service,aws.bucket.name,aws.table.name,aws.queue.name,aws.stream.name
        - name: POD_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
        - name: FLAVOR
          value: test-us-east-1
        - name: DD_TAGS
          value: slug:us-east-1
        - name: DEP_TYPE
          value: rcp
        - name: DD_AGENT_HOST
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: status.hostIP
        - name: DD_ENTITY_ID
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: metadata.uid
        - name: DD_SERVICE
          value: payment-orchestrator
        - name: DD_VERSION
          value: d2045fa78b728936ccabd1fc59c765fccb8359d5
      resources:
        limits:
          cpu: '2'
          memory: 9Gi
        requests:
          cpu: '2'
          memory: 9Gi
      volumeMounts:
        - name: kube-api-access-chcnd
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        - name: vault-secrets
          mountPath: /vault/secrets
      livenessProbe:
        httpGet:
          path: /app-health/payment-orchestrator/livez
          port: 15020
          scheme: HTTP
        initialDelaySeconds: 120
        timeoutSeconds: 20
        periodSeconds: 60
        successThreshold: 1
        failureThreshold: 10
      readinessProbe:
        httpGet:
          path: /app-health/payment-orchestrator/readyz
          port: 15020
          scheme: HTTP
        initialDelaySeconds: 120
        timeoutSeconds: 20
        periodSeconds: 60
        successThreshold: 1
        failureThreshold: 7
      startupProbe:
        httpGet:
          path: /app-health/payment-orchestrator/startupz
          port: 15020
          scheme: HTTP
        initialDelaySeconds: 120
        timeoutSeconds: 20
        periodSeconds: 60
        successThreshold: 1
        failureThreshold: 3
      lifecycle:
        preStop:
          exec:
            command:
              - /bin/sleep
              - '10'
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: IfNotPresent
    - name: vault-agent
      image:<PHONE_NUMBER>37.dkr.ecr.us-east-1.amazonaws.com/library/eg-vault:1.8.1
      command:
        - /bin/sh
        - '-ec'
      args:
        - >-
          echo ${VAULT_CONFIG?} | base64 -d > /home/vault/config.json && vault
          agent -config=/home/vault/config.json
      env:
        - name: VAULT_LOG_LEVEL
          value: info
        - name: VAULT_LOG_FORMAT
          value: standard
        - name: VAULT_CONFIG
          value: >-
            eyJhdXRvX2F1dGgiOnsibWV0aG9kIjp7InR5cGUiOiJrdWJlcm5ldGVzIiwibW91bnRfcGF0aCI6ImF1dGgva3ViZXJuZXRlcy9vcmRlcnMtZWdvcmRlcnMtdGVzdC11cy1lYXN0LTEtcmNwIiwibmFtZXNwYWNlIjoibGFiL2lzbGFuZHMiLCJjb25maWciOnsicm9sZSI6InBheW1lbnQtb3JjaGVzdHJhdG9yLnBheW1lbnQtb3JjaGVzdHJhdG9yLXRlc3QtdXMtZWFzdC0xLW1hc3Rlci10ZW1wbGF0ZSJ9fSwic2luayI6W3sidHlwZSI6ImZpbGUiLCJjb25maWciOnsicGF0aCI6Ii9ob21lL3ZhdWx0Ly52YXVsdC10b2tlbiJ9fV19LCJleGl0X2FmdGVyX2F1dGgiOmZhbHNlLCJwaWRfZmlsZSI6Ii9ob21lL3ZhdWx0Ly5waWQiLCJ2YXVsdCI6eyJhZGRyZXNzIjoiaHR0cHM6Ly92YXVsdC1lbnRlcnByaXNlLnNlY3JldHMucnVudGltZS50ZXN0LWN0cy5leHAtYXdzLm5ldCJ9LCJ0ZW1wbGF0ZSI6W3siZGVzdGluYXRpb24iOiIvdmF1bHQvc2VjcmV0cy9zZWNyZXRzLmpzb24iLCJjb250ZW50cyI6Int7LSB3aXRoIHNlY3JldCBcIm9yZGVycy9wYXltZW50LW9yY2hlc3RyYXRvci9rdi12Mi9kYXRhL3BheW1lbnQtb3JjaGVzdHJhdG9yL3NlY3JldHNcIiB9fVxuICAge3stIC5EYXRhLmRhdGEgfCB0b1VuZXNjYXBlZEpTT04gfX1cbnt7LSBlbmQgfX0gICAgICAgICAiLCJsZWZ0X2RlbGltaXRlciI6Int7IiwicmlnaHRfZGVsaW1pdGVyIjoifX0iLCJwZXJtcyI6IjA2NjQifV0sInRlbXBsYXRlX2NvbmZpZyI6eyJleGl0X29uX3JldHJ5X2ZhaWx1cmUiOnRydWV9fQ==
      resources:
        limits:
          cpu: 500m
          memory: 128Mi
        requests:
          cpu: 250m
          memory: 64Mi
      volumeMounts:
        - name: kube-api-access-chcnd
          readOnly: true
          mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        - name: home-sidecar
          mountPath: /home/vault
        - name: vault-secrets
          mountPath: /vault/secrets
      lifecycle: {}
      terminationMessagePath: /dev/termination-log
      terminationMessagePolicy: File
      imagePullPolicy: IfNotPresent
      securityContext:
        capabilities:
          drop:
            - ALL
        runAsUser: 100
        runAsGroup: 1000
        runAsNonRoot: true
        readOnlyRootFilesystem: true
        allowPrivilegeEscalation: false
  restartPolicy: Always
  terminationGracePeriodSeconds: 30
  dnsPolicy: ClusterFirst
  nodeSelector:
    karpenter-provisioner-type: standard
  serviceAccountName: payment-orchestrator-test-us-east-1-master-template
  serviceAccount: payment-orchestrator-test-us-east-1-master-template
  securityContext:
    fsGroup: 1337
  imagePullSecrets:
    - name: <REDACTED>
  affinity:
    podAntiAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 100
          podAffinityTerm:
            labelSelector:
              matchLabels:
                app.kubernetes.io/name: payment-orchestrator
                k8s.expediagroup.com/instance: master
                k8s.expediagroup.com/release: test-us-east-1
                progressivedeployment.expediagroup.com/variant: template
            topologyKey: kubernetes.io/hostname
  schedulerName: default-scheduler
  tolerations:
    - key: node.kubernetes.io/not-ready
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 300
    - key: node.kubernetes.io/unreachable
      operator: Exists
      effect: NoExecute
      tolerationSeconds: 300
  priority: 0
  enableServiceLinks: true
  preemptionPolicy: PreemptLowerPriority
  topologySpreadConstraints:
    - maxSkew: 1
      topologyKey: topology.kubernetes.io/zone
      whenUnsatisfiable: ScheduleAnyway
      labelSelector:
        matchLabels:
          app.kubernetes.io/name: payment-orchestrator
          k8s.expediagroup.com/instance: master
          k8s.expediagroup.com/release: test-us-east-1
          progressivedeployment.expediagroup.com/variant: template

Allocatable sections of the node:
osting ready status
Addresses:
  InternalIP:   <IP_ADDRESS>
  Hostname:     ip-10-74-7-176.ec2.internal
  InternalDNS:  ip-10-74-7-176.ec2.internal
Capacity:
  attachable-volumes-aws-ebs:  25
  cpu:                         16
  ephemeral-storage:           104845292Ki
  hugepages-1Gi:               0
  hugepages-2Mi:               0
  memory:                      32062752Ki
  pods:                        234
Allocatable:
  attachable-volumes-aws-ebs:  25
  cpu:                         15890m
  ephemeral-storage:<PHONE_NUMBER>4
  hugepages-1Gi:               0
  hugepages-2Mi:               0
  memory:                      29063456Ki
  pods:                        234

We have Karpenter installed in 100s of EKS clusters and we were intermittently facing issues where the older version 0.10.1 was not responding to Pending pods at all.
We validated via Api server logs too, there were events that the pod is pending and Karpenter kicked in only after hours. This is just one example, we have our customers reporting several of those in Prod and becomes blocker for our customers.
We decided to upgrade it yesterday to 0.13.2 after we couldn't relate the Issue with the insight through the metrics, and now we landed into this issue.

Pods are scheduled based off of the effective requests, defined here.  In this pod's case, since the sum of the non-init container requests is larger than the init container requests, that's the resource request used which is 2350m CPU.  For some reason we apparently thought it would schedule on the node.  There are a few potential causes related to either not identifying that the node is fully initialized yet or an error in calculating the number of resources that are scheduled against the node.
Does that node have a karpenter.sh/initialized: "true" label applied?

relates to https://github.com/aws/karpenter/issues/2250

Heya,
Yes the node has the initialised label on it. More details regarding instance type:
    beta.kubernetes.io/arch: amd64
    beta.kubernetes.io/instance-type: c5.4xlarge
    beta.kubernetes.io/os: linux
    failure-domain.beta.kubernetes.io/region: us-east-1
    failure-domain.beta.kubernetes.io/zone: us-east-1a
    k8s.io/cloud-provider-aws: ad5a582408e1a88def9b3134c6b134d3
    karpenter-provisioner-type: standard
    karpenter.sh/capacity-type: spot
    karpenter.sh/initialized: "true"
    karpenter.sh/provisioner-name: general-provisioner
    kubernetes.io/arch: amd64
    kubernetes.io/hostname: ip-10-74-7-176.ec2.internal
    kubernetes.io/os: linux
    node.kubernetes.io/instance-type: c5.4xlarge
    topology.ebs.csi.aws.com/zone: us-east-1a
    topology.kubernetes.io/region: us-east-1
    topology.kubernetes.io/zone: us-east-1a
    ```

We noticed that we have some daemonsets with either no resources requests nor limits specified.
Could this interfere with Karpenter calculation of the available resources on a node?

Does this work or I can redact the names for you.

That's good, I just needed the numbers.  Thanks!

@ra-grover Is that the same node that shows CPU request total of 13641m?

I am aslo trying to reproduce the issue, to bring it to a state where the pending pods is there and I can connect the Karpenter controller locally then to debug the calculations.

@ra-grover Is that the same node that shows CPU request total of 13641m?

Yes its the same node.

No its a little less, some pod may have moved.

Do you use limit ranges on your namespaces?

No we dont.
Correct me if I am wrong @cebernardi .

I confirm we don't

If you see it happen again, can you provide the list of pod requests, the matching summary and the node capacity/allocatable while it's occurring?  I haven't been able to reproduce it here and looking at the code don't see anything yet related to how we could compute the resources incorrectly.

The CPU requests sum up for me

Any chance you are using pod overhead? https://kubernetes.io/docs/concepts/scheduling-eviction/pod-overhead/

Nopes. So I have been able to reproduce it just now on the same host.
  ~ k get pod REDACTED -n payment-orchestrator -o yaml  |grep req -A2
      requests:
        cpu: 100m
        memory: 128Mi
--
      requests:
        cpu: 3101m
        memory: 9Gi
--
      requests:
        cpu: 250m
        memory: 64Mi
--
      requests:
        cpu: 250m
        memory: 64Mi
--
      requests:
        cpu: 100m
        memory: 128Mi

k describe node ip-10-74-7-176.ec2.internal =>
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource                    Requests      Limits
  --------                    --------      ------
  cpu                         12441m (78%)  43900m (276%)
  memory                      8200Mi (28%)  23776Mi (83%)
  ephemeral-storage           0 (0%)        0 (0%)
  hugepages-1Gi               0 (0%)        0 (0%)
  hugepages-2Mi               0 (0%)        0 (0%)
  attachable-volumes-aws-ebs  0             0

Allocatable:
  attachable-volumes-aws-ebs:  25
  cpu:                         15890m
  ephemeral-storage:<PHONE_NUMBER>4
  hugepages-1Gi:               0
  hugepages-2Mi:               0
  memory:                      29063456Ki
  pods:                        234

3449 is left on the node, while the pod request for 3801.

And its again stuck on:

Can you show the pods cpu/memory requests that are scheduled to the node at the same time as the node resource request summary?

Let me know if anything else is needed.

I have a local debugger attached to the remote Cluster, this is a test cluster of a customer but I can afford not more than 30 mins to have this test app down.
Would you like to hop on to a call and debug any calculations with me if you want ?

Fixed with https://github.com/aws/karpenter/pull/2322


deluge plugin not setting label correctly from jinja2 token

Expected behaviour:
For the deluge plugin to set the label to the value of the jinja token
Actual behaviour:
The deluge plugin sets the label of the torrent in deluge to be the name of the jinja token with an underscore at both the beginning and end of the token name.
Steps to reproduce:

Step 1: Add torrent VIA deluge plugin, setting the label to be a value from a jinja token
Step 2: Check deluge for label name

Config:
output-deluge:
    deluge:
      host: '{{ secrets.deluge.host }}'
      port: 58846
      username: '{{ secrets.deluge.username }}'
      password: '{{ secrets.deluge.password }}'
      automanaged: yes
      label: '{{deluge_label}}'
      path: '/home/user/deluge/1_downloads/{{deluge_label}}'
      movedone: '/home/user/deluge/2_completed/{{deluge_label}}'

Please note:  I know the deluge_label token is set correctly because path and movedone are the correct values.
Log:
2016-11-21 14:28 VERBOSE  filesystem    add-manual      Starting to scan folders.
2016-11-21 14:28 VERBOSE  filesystem    add-manual      Scanning folder /home/user/deluge/0_torrents/. Recursion is set to 2.
2016-11-21 14:28 VERBOSE  details       add-manual      Produced 4 entries.
2016-11-21 14:28 VERBOSE  task          add-manual      ACCEPTED: `The.Flash.2014.S03E06.720p.HDTV.X264-DIMENSION[eztv].mkv` by accept_all plugin
2016-11-21 14:28 VERBOSE  task          add-manual      ACCEPTED: `Scrat.Spaced.Out.2016.720p.BluRay.x264-[YTS.AG]` by accept_all plugin
2016-11-21 14:28 VERBOSE  task          add-manual      ACCEPTED: `The.Flash.2014.S03E06.720p.HDTV.X264-DIMENSION[eztv].mkv` by accept_all plugin
2016-11-21 14:28 VERBOSE  task          add-manual      ACCEPTED: `Scrat.Spaced.Out.2016.720p.BluRay.x264-[YTS.AG]` by accept_all plugin
2016-11-21 14:28 VERBOSE  task          add-manual      REJECTED: `The.Flash.2014.S03E06.720p.HDTV.X264-DIMENSION[eztv].mkv` by if plugin because matched requirement: not deluge_label.startswith('flexget_')
2016-11-21 14:28 VERBOSE  task          add-manual      REJECTED: `Scrat.Spaced.Out.2016.720p.BluRay.x264-[YTS.AG]` by if plugin because matched requirement: not deluge_label.startswith('flexget_')
2016-11-21 14:28 INFO     download      add-manual      Downloading: Scrat.Spaced.Out.2016.720p.BluRay.x264-[YTS.AG]
2016-11-21 14:28 INFO     download      add-manual      Downloading: The.Flash.2014.S03E06.720p.HDTV.X264-DIMENSION[eztv].mkv
2016-11-21 14:28 VERBOSE  details       add-manual      Summary - Accepted: 2 (Rejected: 2 Undecided: 0 Failed: 0)
2016-11-21 14:28 INFO     deluge        add-manual      Connecting to daemon at <IP_ADDRESS>:58846..
2016-11-21 14:28 INFO     deluge        add-manual      Connected to daemon at <IP_ADDRESS>:58846..
2016-11-21 14:28 VERBOSE  deluge        add-manual      Adding Scrat.Spaced.Out.2016.720p.BluRay.x264-[YTS.AG] to deluge.
2016-11-21 14:28 VERBOSE  deluge        add-manual      Adding The.Flash.2014.S03E06.720p.HDTV.X264-DIMENSION[eztv].mkv to deluge.
2016-11-21 14:28 INFO     deluge        add-manual      Scrat.Spaced.Out.2016.720p.BluRay.x264-[YTS.AG] successfully added to deluge.
2016-11-21 14:28 INFO     deluge        add-manual      The.Flash.2014.S03E06.720p.HDTV.X264-DIMENSION[eztv].mkv successfully added to deluge.
2016-11-21 14:28 INFO     deluge        add-manual      Connection lost to daemon at <IP_ADDRESS>:58846 reason: Connection was closed cleanly.

Additional information:

Flexget Version: 2.6.1
Python Version: 2.7.12
Installation method: pip
OS and version: Ubuntu 16.04

Workaround until this bug is fixed:
Use set plugin to set the value of label for the deluge plugin:
output-deluge:
    deluge:
      host: '{{ secrets.deluge.host }}'
      port: 58846
      username: '{{ secrets.deluge.username }}'
      password: '{{ secrets.deluge.password }}'
      automanaged: yes
      path: '/home/user/deluge/1_downloads/{{deluge_label}}'
      movedone: '/home/user/deluge/2_completed/{{deluge_label}}'
    set:
      label: '{{deluge_label}}'

Doesn't look like a bug. Seems to be deliberate, but I suppose it could be changed.

Please reopen in feathub


Fix prop isColumn validation on Column grid component

(Please read the guidelines before creating PRs.)
Fixes #73.
Changes proposed in this pull request:

Add prop isColumn validation on Column grid component

@devrasec this fix is now included in release 0.9.5.

Nice! @crisu83

Aaand I totally forgot to publish it. Just a moment @devrasec.

Fixed @devrasec.


Missing indexPath entries in switch leads to crash

I was playing around with release 1.5.2, and followed the video to hook things up. I created three static cells, but in my segueIdentifierForIndexPathInLeftMenu I only had case 2 returning a string, the others just left the identifier nil.
This leads to a crash in my MainViewController with a message telling me I do not have a leftMenu segue.
*** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'Receiver (<MainViewController: 0x8c95e80>) has no segue with identifier 'rightMenu''
Took me a while to figure out that only if I implement all cases in segueIdentifierForIndexPathInLeftMenu does it work.
I realize this is a bit of an edge case, but it would be nice to handle this a bit more gracefully than a full-on crash of the app.

I've changed, - (NSIndexPath *)initialIndexPathForLeftMenu
{
return [NSIndexPath indexPathForRow:2 inSection:0];
}
but still won't do, why is this


Spinners no longer advance

It appears that commit 6697ac3472010e54589c14a485512da543b0c923 has broken spinners. After this commit spinners no longer spin.
Run cargo run --example yarnish before and at this commit to see the difference.

Good catch, thanks! I'm working on a fix now and will add a test so it doesn't happen again.

@djc any idea why we check for tick != 0?
https://github.com/console-rs/indicatif/blob/main/src/state.rs#L106

No, I don't quite understand why we check for tick != 0. I think this was introduced all the way back in a889b3ae0ea4c77ebe5b6df9e5af527cb703c9a9? My intuition was that it's maybe a sentinel for if there's even a spinner kind of thing that we need to tick, but I don't think that's it?


use tpu-client-next in send_transaction_service

Problem
This PR adds tpu-client-next to send_transaction_service as an optional client.
Summary of Changes

Curious: Is this to allow tests to run in parallel, or does it change the concurrency model of tokio itself for the duration of the test, or both?

 #[tokio::test(flavor = "multi_thread")] setups tokio runtime to have a pool of threads with more than 1 thread (default for tokio::test.  It is used primarily to avoid dead/life locks in concurrent code where several tasks depend on each other.

@steveluscher

Neat! What sort of outcomes do we expect to see with the QUIC version?
The expectations are limited to get rid of quic traffic fragmentation. So I try not to change anything else than adding an option to select a quic client implementation to be safe.

@alessandrod I've added a commit that introduces reusable Receiver to the tpu-client-next and uses this Receiver to implement NotifyKeyUpdate trait for STS. Why in this PR -- to avoid modifications in the follow up PR. Alternatively, I could remove from this PR implementation of the NotifyKeyUpdate and add it in the follow up if this PR seems to be too big. What do you think?

@alessandrod pushed updates, now it should address all the comments.


Service Endpoint Discovery

@swcurren   https://github.com/swcurran

I notice that there is not an example of an actual DIDDoc produced from a Key Event State with the definition of how it would be produced. Should that be documented? The purpose of a DID Method is to resolve a DID to a DIDDoc, so I think the process for producing the DIDDoc should be documented in the DID Method spec. beyond "It may include verification method and won't include service".
My assumption is that a KERI DID Resolver is that a piece of software would get a DID, (somehow) find the KEL for the DID, process the KEL to get to a Key State and then produce a DIDDoc based on the content of the Key State. AFAIK, all the steps up to that last one is documented elsewhere, and that step should be documented in the DID Method document.
A (mostly related question): Is there a way to insert an endpoint into the KEL, surface it in a Key State and then insert it into a DIDDoc derived from that Key State? That would seem to be a good use of a KERI identifier -- a stable ID, with provenance, a public key and way to contact the controller of the key.
Perhaps a separate issue. I would think the "version_id" and/or "version_time" DID resolution parameters should be supported in the DID Method. As I understand it, the KEL would be processed up the requested version Key State, and the DIDDoc produced from that state.

Good comment. The essential content of a KERI DID Doc is the service endpoint(s) from which to download the Key Event Log for the identifier.  So we should  add that to the method spec as you suggest.  From a KERI security perspective the DID DOC itself is an out-of-band discovery mechanism for service endpoints from which to download verifiable key state via the KEL.
On your related question: We have defined an OOBI protocol (Out-Of-Band-Introduction) for KERI that allows the controller of a KERI AID (the cryptographic prefix or method specific ID portion of a did:keri) to publish a URL for a service end point with the KERI AID in any number of ways. The recipeint of the OOBI then looks up the endpoint and queries it for verifiable proof of key-state via the resulting KEL. If the query result is not verified then the OOBI is discarded. Essentially a did doc for KERI is a delivery mechanism for KERI OOBIs.  But OOBI discovery is not limited to DID Docs but may use any other discovery method including web search, .well-known URLs, QR Codes, etc.
A draft of the OOBI spec may be found here:
OOBI
https://hackmd.io/MxTAIBQTRkWU4-w140tNuA
In the OOBI doc there is a reference to BADA (Best Available Data Acceptance) policy. We have since expanded that concept to what we are calling BADA-RUN  (there was an IIW session that covered this). Not explained in the OOBI document but in the BADA-RUN  is the idea of security level data types for data with regards to acceptance policy. The three primary types are:

Key State in a KEL (explicitly included in KERI establishment events i.e. keys and backing infrastructure such as witness identifiers)
Anchored Data (explicit digest of data anchored in a KEL)
Signed TimeStamped Data stored in database (not anchored but relative preeminence determined by key state and then timestamp)

The last two mechanisms may be used to associate verifiable service endpoints with a KEL that may be surfaced in a DID DOC.
Although still under development there is a discussion on BADA-RUN here
https://hackmd.io/Qsrfj7Y-TIGl5ESvrxWGxw

While those KERI-specific endpoints are useful if you are interested in the KERI identifier, if you are interested in the contents of the DIDDoc and other service endpoints, they are insufficient.  For example, if I am resolving DIDs to establish a DIDComm connection, the DIDs of my collaborators may be hosted in a number of places (KERI, Bitcoin, Ethereum, DID:Web, DID:GitHub etc.) based on the choices made by my connections -- other DID controllers.  At that level, I just want to resolve the DID and find the DIDComm Service endpoint -- regardless of the DID Method.  I count on my DID resolver to handle the DID methods that I'm willing to accept -- one of which may be the did:keri method. My resolver deals with the messy details, and I don't care about the KEL, Key State or anything else related to KERI, and likewise for any of the other DID methods that my resolver handles.
I think to make the DID Method consumable by others, the DID Method document should include a section on how a KERI DID behaves like any other DID method -- e.g. how I as a DID Controller can put arbitrary things (perhaps within reason) into my DIDDoc, so that consumers of that DID Doc can retrieve and use it.  As noted, a resolver MUST follow the rules for verifying the integrity of the KERI Identifier, but in this case, that's handled separately from the business purpose of resolving the DIDDoc contents.

@swcurran

While those KERI-specific endpoints are useful if you are interested in the KERI identifier, if you are interested in the contents of the DIDDoc and other service endpoints, they are insufficient.

Yes I agree. The BADA-RUN policy is not merely about service endpoints that may be used to download KELs but any data including service endpoints for other purposes. This puts the security policy of all data associated with a given AID on the same footing. So a did:keri user could very well put did:comm endpoints in the did doc and could choose to have those verifiable as signed type 3 data via the did doc. The did method resolver and or wallet would do the heavy lifting to verify those endpoints as valid data signed by the controller of the identifier. This is not explained in the did:keri method yet. So appreciate the feedback.

If you have an example of what you would like to see in a did doc for those other purposes as in JSON, that would be most welcome.

I think looking at the Universal Resolver examples are useful.  While some have only entries that are based on what comes from the DID Method (e.g., DID:BTCR...) others allow the adding of more data to the DIDDoc.  There are a lot of examples.  The "did:sov" example shows some extended data -- service endpoints.  In the new did:indy method, we are proposing to allow the controller to add arbitrary JSON (subject to some constraints, but not much) to the DID data that gets added to the DIDDoc. So there is a very direct connection -- e.g. "Add data here, in this format, and it will be added to the DIDDoc using these rules."

I think it is important to clarify the statement "My resolver deals with the messy details" and the implications to where you are placing your trust.  All data in KERI is end-verifiable which means that you should not place your trust in any other party to verify an identifier and data signed by an identifier, ie. the steps needed to resolve a did:keri DID into a DIDDoc.
When looked at through the lens of zero-trust, a did:keri did resolver becomes an extension of a KERI wallet and is responsible for "end verifying" the KEL and key state and then the anchors or signatures on associated data.  Architecturally this means that a software component that is performing these functions must be deployed as part of the system that is using it to resolve KERI DIDs.  Otherwise you allowing a component out of your control to perform the KERI verification steps thus placing trust in it.
In my mind, there is an important architectural distinction that needs to be made if we want to create a KERI did resolver that provides the resolution API of a did resolver.  Because DIDDocs are not signed by the did resolver, they suffer from potential attacks if we allow for a "remote binding" resolver (https://w3c-ccg.github.io/did-resolution/#dfn-remote-binding).  Only a "local binding" resolver (https://w3c-ccg.github.io/did-resolution/#dfn-local-binding) should be allowed knowing that the local resolver is performing the correct end verification of the KERI key state and signatures locally.  Otherwise, as Sam suggests, a remote binding resolver would only return KERI OOBIs as part of a DIDDoc and expect the consumer of that DIDDoc to be running a KERI capable wallet that would do all the messy parts after the DID resolution.

Absolutely @pfeairheller.  I did not mean that a remote DID KERI resolver should be used. Rather, from an architectural point, I'm not going to mix my ToIP Layer 1 code (DID resolvers) from ToIP Layer 2/3 code -- I'm going to keep them separate. So regardless of where my DID Resolver is (built in, internal service, etc.), I'm going to want it to do the Layer 1 work and return to me a DIDDoc.  Further, I'm going to want to put things into my DIDDoc that are resolved by others.  As such, I think the DID Method spec needs to outline how I can use KERI to put things I need into my DIDDoc, with the same functionality I can with other DID Methods.


Median and median-absolute-deviation results

Would it be possible to add these statistics? They are generally more stable than mean and stddev...

Median is accessible as the p50 histogram.percentile(50.0). Definitely possible to add an alias for that. MAD looks like it will be fairly easy to implement as well.


Notification events not working with service workers

Currently on browsers with service workers push.js is not able to handle any events on the notification.
https://github.com/Nickersoft/push.js/blob/93014bc9b52e146426aa9b7c453b03d45549151c/push.js#L189

Could you please elaborate?

Sure,
So when using a browser such as android chrome which does not have support for the Notification API, push.js uses a serviceworker instead.
Currently the logic push.js uses for serviceworker push notifications is to simply register the serviceworker and then call showNotification on it.
This means pretty much all the logic following this is unused
https://github.com/Nickersoft/push.js/blob/93014bc9b52e146426aa9b7c453b03d45549151c/push.js#L245-L284 // notification will be undefined
As a result the following push.js options do not work on android chrome
onClick: Callback to execute when the notification is clicked.
onError: Callback to execute when if the notification throws an error.

I've had a quick look at the service worker documentation and it doesn't look like it's trivial to wire up that logic to the serviceworker notification.

Oh shucks, you're right. The notification variable is never being assigned. I'll start working on a fix as soon as I can. Shouldn't be too hard.

Thanks for the explanation

I apologize that I've been sort of MIA for these past few months, but I am currently working on merging in a change that will fix this issue.

@Nickersoft Any luck? Mobile notifications are not working for me at all. I did notice the sw.js file is empty.

@Nickersoft Any update on when mobile notifications will start working again?

@nickmask Mobile notifications never stopped working (unless there is some issue I am not aware of). This issue had to do with notification events not firing and throwing console errors on mobile. While this issue has been fixed in bc8932df0f1d8b5a648b163e16fa4f4e3ad5b49a, it has not been published to NPM yet, as there were some additional changes I was hoping to make before the next release.

While this issue has been fixed in bc8932d
Was it? Did you check it? As far as i see, it wasn't (or even it can't be) fixed - there is no such event as "notificationclink" outside of service worker.

The ServiceWorkerGlobalScope.onnotificationclick property is an event handler called whenever the notificationclick event is dispatched on the ServiceWorkerGlobalScope object, that is when a user clicks on a displayed notification spawned by ServiceWorkerRegistration.showNotification().
Notifications created on the main thread or in workers which aren't service workers using the Notification() constructor will instead receive a click event on the Notification object itself.

Reference: https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/onnotificationclick
My current solution is to add notificationclick event listener inside the service worker and then pass  it to the parent window via postMessage.

Hello @Nickersoft ,
Same problem here, the notification is shown on mobile but methods (onClick, onShow, ...) don't trigger. Any news about this ?
Thanks !

@Nickersoft What is the status of this issue? How to get onClick to work on Android Chrome browser?

Hi guys. I'm currently looking into an issue where the link option doesn't seem to be operational on the Push homepage. onClick is in the same block of code so it's most likely a related issue. It's weird though... could have sworn link was working. Also, @Oupsla, onClick is the only event that can be triggered on mobile notifications (I thought it said that in the documentation... I might have accidentally removed it). This is just due to how the notifications framework operates. The Notifications API (which mobile notifications don't use) is the only API that supports onShow, onError, etc. Sorry for the snag in the release of v1.0. I'll see if I can get it resolved within a few days.

Hello @Nickersoft ,
Any news about the onClick issue on Android Chrome browser?
I recently test Push.js 1.0.5, works fine on desktop but unfortunately, it only display the notification without click action on mobile (Chrome 61).
Thanks

HI  @Nickersoft  please let us know  why the onclick is not working on Android chrome?
It is not fixed???

To be completely honest, I forget what the outcome of my investigation was :/ I can try to reproduce the issue again soon. Looping in @theLufenk to see if he may be able to assist as well.

@Nickersoft
I was off the grid for a while. Sorry about that !
AFAIK, @dmitry-korolev is correct. The only possible solution IMO would be adding an Event Listener inside the service worker.
I don't think we want to force the folks to use a compulsory piece of code in their ServiceWorkers.
However, since an EventListener for notificationclick  is anyhow required for onclick handler to work, we can reflect the same in the Documentation and also add it to the barebones ServiceWorker that has already been provided in the project.
There is another problem though. While Notification.onclick enables us to attach the click handler function to every Notification instance we create, the ServiceWorker logic for the same entails registering a common Event Handler for all notification generated.
But, we do have the 'tag' property to make out the different Notification instances from one another.
So in effect, we can have a message event listener inside Push.js that fires when the ServiceWorker send a message with postMessage. This event listener will need to figure out if it's a message relevant to Push.js (can be done by choosing a unique event string such as "PushJSNotificationClickEventMessage"). The "tag" property of the target notification would be a payload for the event. The "tag" can be used to find the notification instance from the notifications={} mapping we keep. This instance now has a onclick property which is the target function that needs to be invoked.
@Nickersoft @dmitry-korolev I would love to have your opinions on this approach and see if it is a possible solution ATM. And also, how we can refine the process in order not to cause a regression on the "Install and use with minimum hassles" aspect of the library.
Let me also try and send in a pull request. Doesn't seem like a lot of changes TBH.

Hey @theLufenk @dmitry-korolev, sorry for the delay here –  I think this approach sounds reasonable if you wanted to give it a shot.

Add this event listner into your service worker For android chrome
self.addEventListener('notificationclick', function(event) {     let url = "https://www.google.com";     event.notification.close(); // Android needs explicit close.     event.waitUntil(         clients.matchAll({type: 'window'}).then( windowClients => {             // Check if there is already a window/tab open with the target URL             for (var i = 0; i < windowClients.length; i++) {                 var client = windowClients[i];                 // If so, just focus it.                 if (client.url === url && 'focus' in client) {                     return client.focus();                 }             }             // If not, then open the target URL in a new window/tab.             if (clients.openWindow) {                 return clients.openWindow(url);             }         })     ); });


[BUG] Main website host (elegant.oncrashreboot.com) is NXDOMAIN

Description
Describe the bug
When attempting to visit the Pelican Elegant web page, the browser reports "Server Not Found".
To Reproduce
Steps to reproduce the behavior:

Navigate to https://elegant.oncrashreboot.com/
See error

Expected behavior
A clear and concise description of what you expected to happen.
The project's website is reachable.
Screenshots
If applicable, add screenshots to help explain your problem.

I recently changed the domain registrar from NameCheap to CloudFlare which has broken the subdomain elegant.onCrashReboot.com.
I am trying to figure how to make the subdomain work with Netlify like it used to.
To my surprise, the root domain onCrashReboot.com is working fine and did not require any changes from me during the migration.
Please hang on.

Thank you all for you patience.


feat: add navigation tabs

Add navigation tabs

#531  👈
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @davidlj95 and the rest of your teammates on  Graphite


[BB-9306] Change license to Apache 2.0

Description
This PR changes the license to Apache 2.0 from GPL 3.0
Supporting Information
OpenCraft Internal Jira Ticket: BB-9306

@pkulkark This codebase has an existing marker for its license in setup.py, 'UNKNOWN', which is not correct-- we know the license. Could you update it?


feat(trace): Configurable exporter and allow fetching the underlying provider

⚠ This is a breaking change, since it changes the signature of Context
Rationale: people should be able to set their own exporters.
As an example, when using Google Cloud, you would do something like this:
import (
        "context"
        "log"
        "os"

        texporter "github.com/GoogleCloudPlatform/opentelemetry-operations-go/exporter/trace"
        "goa.design/clue/trace"
)

func main() {
        // Create exporter.
        ctx := context.Background()
        projectID := os.Getenv("GOOGLE_CLOUD_PROJECT")
        exporter, err := texporter.New(texporter.WithProjectID(projectID))
        if err != nil {
                log.Fatalf("texporter.NewExporter: %v", err)
        }

        ctx = trace.Context(ctx, "service", trace.WithExporter(exporter))
        defer trace.TraceProvider(ctx).ForceFlush(ctx)

        // ...
}

I opted for trace.WithExporter rather than requiring an exporter param so we have more flexibility to make non-breaking changes. E.g: I added trace.WithGRPCExporter(conn) so it's easy to migrate existing users.

Codecov Report

Merging #59 (284423b) into main (ae25706) will decrease coverage by 0.81%.
The diff coverage is 51.72%.

@@            Coverage Diff             @@
##             main      #59      +/-   ##
==========================================
- Coverage   94.45%   93.64%   -0.82%
==========================================
  Files          26       26
  Lines        1244     1258      +14
==========================================
+ Hits         1175     1178       +3
- Misses         44       54      +10
- Partials       25       26       +1

Flag
Coverage Δ

micro
93.64% <51.72%> (-0.82%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

trace/http.go
89.74% <ø> (ø)

trace/context.go
75.00% <36.36%> (-7.36%)
:arrow_down:

trace/options.go
75.75% <61.11%> (-24.25%)
:arrow_down:

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 ae25706...284423b. Read the comment docs.

Looks great, thank you!


Change Language Error Tag

I want to change the error tag to my language

It depends how you translate ecto error messages now. You would normally use the MyAppWeb.ErrorHelpers module in your Phoenix app, and manually add the errors to errors.po.
More here:
https://elixirforum.com/t/translate-ecto-validation-messages/5469
https://elixirforum.com/t/schema-internationalization-localization/21096
Also see https://github.com/danschultzer/pow/issues/378.

how about
"The provided login details did not work. Please verify your credentials, and try again."
Where does it come from?

It's detailed here: https://hexdocs.pm/pow/1.0.19/README.html#i18n

I get an error like this after add messages_backend: PowdepsWeb.Pow.Messages to my configuration

what funtion for this error

I tried all of these functions but it didn't work

It's described in the linked docs that you need to add the extension name to the method:
  # Message methods for extensions has to be prepended with the snake cased
  # extension name. So the `email_has_been_sent/1` method from
  # `PowResetPassword` is written as `pow_reset_password_email_has_been_sent/1`
  # in your messages module.

So it should look like this:
  def pow_email_confirmation_email_confirmation_required(_conn), do: gettext("You'll need to confirm your e-mail before you can sign in. An e-mail confirmation link has been sent to you.")


RZBZ#1279631 - OS not skipped when template is present

I created a change that prevents from sending whole OS element when a template
is present. This patch was incorrect causing ignoring boot order set via API
when there is a template. 455c65736ce5dfbae84466fcde3c3e787c1cd795
Initially, this was created to prevent this error when creating a VM with
incorrect OS set:
Cannot add VM. Cannot set single display device via VNC display

I am removing this completely in this patch.

Ping?

Replaced by @iNecas patch.


Add instructions for verifying Cosign release

Description

The Cosign binary is signed both with keyless signing and an artifact key. You first need to verify Cosign with the artifact key, since you will need Cosign to verify the keyless signature.
https://github.com/sigstore/fulcio/pull/1079/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R78 includes instructions for Fulcio. This should be copied over for verifying Cosign binaries.

Hi, @haydentherapper. I'm interested in working on this and I need some guidance. Do you mean the instructions for Fulcio should be copied into the Cosign binaries?

Thank you! The cosign binary is signed the same way as the fulcio binary, with the artifact key mentioned in the linked documentation. The instructions I linked should be copied over to the page on installing cosign, updating any references to “fulcio” to instead be “cosign”.

okay, thank you very much. I would get right into it

Hi, @haydentherapper. I've been going through the docs repo and the website and I am kind of stuck on which .md file in the cosign folder I would be modifying to solve the issue or would I be creating a new one?

Hi, @haydentherapper. I've been going through the docs repo and the website and I am kind of stuck on which .md file in the cosign folder I would be modifying to solve the issue or would I be creating a new one?

https://github.com/sigstore/docs/blob/main/content/en/cosign/installation.md would work

alright. thank you.

Hi @haydentherapper. I made a pull request for this issue already. Please kindly review and let me know if i need to make any changes.

@haydentherapper I think we can close this issue as it was fixed in https://github.com/sigstore/docs/pull/100. Thanks!


Non-threadsafe database connections shared between threads

When running @javascript scenarios, the database connection adapter is shared between cucumber and the webserver.  This is completely unsafe, and leads to some very confusing and difficult-to-diagnose bugs when both threads attempt to run queries simultaneously.  With PostgreSQL, I have seen one thread get the response to the other thread's database query, which generally hoses everything up.
This bug was introduced by commit cbcfd88dc983340281db20915a80e3831c8f6950.

Any updates on this? We can't upgrade to Rails 3.1 because of it. Grrr.

@brokenladder quit whining and submit a bugfix.

Translation:
I have no information indicating that a fix from myself or the other major contributors is eminent.
If you would like to look into this and fix the bug, the community would appreciate it.

Hi - maybe I'm seeing a different bug, but as far as I can tell this bug has nothing to do with Rails 3.1 - I see its symptoms in 3.0.
@aslakhellesoy - I'll happily submit a bugfix, but it would more-or-less consist of "git revert cbcfd88dc983340281db20915a80e3831c8f6950" : I don't think the cross-thread connection is a workable solution.  Want me to do so?

Rails 3.1 depends on a higher version of cucumber-rails, which seems to have this bug. You could of course also get this bug in Rails 3.0 by installing that version of cucumber-rails.

I had what I thought was the same issue, and this was the offending commit. Reverting it got my tests green again.
https://github.com/cucumber/cucumber-rails/commit/30e5e36d1de6122c33efa09859a3e7d9cc088c5e

Had this same problem. Rewriting tests so that factories were all called before selenium seems to be a viable workaround for the moment.

The above fix was close but not quite. Here's closer:
begin
  DatabaseCleaner.strategy = :truncation
rescue NameError
  raise "You need to add database_cleaner to your Gemfile (in the :test group) if you wish to use it."
end
Before('@javascript') do
  ActiveRecord::Base.shared_connection = nil
  ActiveRecord::Base.descendants.each do |model|
    model.shared_connection = nil
  end
end

This now patches around the commit, which should obviously be reverted.

This descendants line does nothing, because shared_connection is a class_attribute. You're just setting the same thing over and over again for every descendant.

It definitely does something, including that line just got my suite working with postgres again.

Well I'll be. It seems I misunderstood what class_attribute does.

as long as Subclass does not assign a value to setting by performing Subclass.setting = something , Subclass.setting would read value assigned to parent class. Once Subclass assigns a value then the value assigned by Subclass would be returned.

I had read this post by Obie Fernandez and just assumed that because setting it for class also set it for subclass, that setting it for subclass would also set it for class. Wrong. Here's the post though, for reference.

After digesting the connection management post by @tenderlove it makes sense why this would be necessary.
Lets hope this gets reverted and connection management gets cleaned up shortly.

@sorentwo
Sounds plausable ;)

The solution proposed by mike-burns worked for me. Tks.

Phew. What a confusing mess! So, let me see if I've got this straight:

We can't use transactional database rollback unless everything happens through the same database connection
Using the same database connection is safe enough for rack-based scenarios because everything is synchronous and runs in a single thread (assuming you don't use threads in your actual application).
Using the same database connection is not safe for @javascript scenarios because Cucumber and the web server run in separate threads and thus could stomp on each other as they access the database connection.

I'm curious how this works with other testing tools? What do you do if you're using Capybara with RSpec integration tests to drive selenium, for example? How does Rails' bulit-in transactional_fixtures stuff work these days?

A little bit of background:
https://groups.google.com/forum/#!msg/ruby-capybara/JI6JrirL9gM/R6YiXj4gi_UJ
At the time @jnicklas wrote that post, cucumber-rails used to switch database strategies and go for truncation whenever there was a @javascript scenario. Are we saying we need to go back to that?

@mattwynne - yep, your summary is correct.  In my opinion, we ought to avoid transactional database strategies with javascript and revert the shared connection behaviour.

Can someone please try out this patch? If it works, you should be able to configure cucumber-rails to use truncation for js scenarios using:
Cucumber::Rails::Database.javascript_strategy = :truncation
Just pop that somewhere in your features/support folder after you've required cucumber-rails.
Using a strategy allows people who are prepared to take the risk of shared connections for the payoff of faster tests, the rest of you can have something thread-safe. I would have made truncation the default, but it seems the current tests are dependent on the shared connections stuff and I don't have the energy to change them right now. Patches to the tests are most welcome!

There's a feature for it now which explains how to use it (and caused me to actually make it work!).
I still think we should make truncation the default: the shared connection hack is useful if you know what you're doing but we don't want to give anyone else a sleepless night.
Feedback?

I think that wrapping the entire request in a Mutex should do the trick. Rails does this anyway by default, unless you switch on threadsafe! mode. I've personally used this on tons of projects and have never had any kinds of issues with it. To the people who have had problems, are you running Rails in threadsafe mode?
That being said, I agree that shared connections should probably not be the default. It's a fine enhancement if you know the pitfalls, but we should not be making that choice for others.

There are situations where you don't control the request though - for example, if you open a page that then repeatedly polls the server for a database change.  If you then combine that with cucumber touching the database while that polling page is open, you're fairly guaranteed to run into threading problems.
On 3 Nov 2011, at 12:01, Jonas<EMAIL_ADDRESS>wrote:

I think that wrapping the entire request in a Mutex should do the trick. Rails does this anyway by default, unless you switch on threadsafe! mode. I've personally used this on tons of projects and have never had any kinds of issues with it. To the people who have had problems, are you running Rails in threadsafe mode?
That being said, I agree that shared connections should probably not be the default. It's a fine enhancement if you know the pitfalls, but we should not be making that choice for others.
--
Reply to this email directly or view it on GitHub:
https://github.com/cucumber/cucumber-rails/issues/166#issuecomment-2616105

@jdelStrother hmm, I guess you would have to put all interaction with the DB in your specs in a Mutex as well then, not ideal obviously.

Merged to master. Awesome fix Matt!!!

Does this solution address @jdelStrother's point?

@brokenladder - I think @jdelStrother's point was that it's not always safe to use the same connection instance from two different threads.
The default for @javascript scenarios is now to have a different connection instance per thread (or process). Cucumber in the main thread has one connection - The app in the other thread has its own instance.
In other words - his point is addressed.

Yep, Matt's stuff fixes my concerns.  It would be good to see #182 fixed up, but everything else looks great.

FYI for older versions upgrading to versions which include this patch, since Cucumber::Rails::Database.javascript_strategy = :truncation is emitted in a generator, users will have to add that line by hand, else they get:
 undefined method `before_js' for nil:NilClass (NoMethodError)
 /Users/jason/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.0/lib/active_support/whiny_nil.rb:48:in `method_missing'
 /Users/jason/.rvm/gems/ruby-1.9.2-p290/bundler/gems/cucumber-rails-192768e5dc29/lib/cucumber/rails/database.rb:12:in `before_js'
 /Users/jason/.rvm/gems/ruby-1.9.2-p290/bundler/gems/cucumber-rails-192768e5dc29/lib/cucumber/rails/hooks/active_record.rb:11:in `Before'

Alternatively we could provide a default value for @strategy inside Cucumber::Rails::Database in cucumber-rails.

On 4 Nov 2011, at 15:13, Jason Morrison wrote:

FYI for older versions upgrading to versions which include this patch, since Cucumber::Rails::Database.javascript_strategy = :truncation is emitted in a generator, users will have to add that line by hand, else they get:
undefined method `before_js' for nil:NilClass (NoMethodError)
/Users/jason/.rvm/gems/ruby-1.9.2-p290/gems/activesupport-3.1.0/lib/active_support/whiny_nil.rb:48:in `method_missing'
/Users/jason/.rvm/gems/ruby-1.9.2-p290/bundler/gems/cucumber-rails-192768e5dc29/lib/cucumber/rails/database.rb:12:in `before_js'
/Users/jason/.rvm/gems/ruby-1.9.2-p290/bundler/gems/cucumber-rails-192768e5dc29/lib/cucumber/rails/hooks/active_record.rb:11:in `Before'

Alternatively we could provide a default value for @strategy inside Cucumber::Rails::Database in cucumber-rails.

Yes, this needs fleshing out with specs on Cucumber::Rails::Database under #182. I'd love some help as I'm super busy for the next couple of weeks.


Invisible walls feedback

When an invisible wall bonus is activated nobody cares who has triggered the bonus, but everybody can use the invisible walls to go on the other side of the playground.
However ONLY the player who has triggered the bonus is warned when the invisible walls will be deactivated (the bonus icon starts blinking). ONLY him can predict the moment when the walls will become normal again.
As it's a "bonus-for-all" it would be better to put some feedbacks or highlights on the wall itself to warn every play that it will come back to normal soon.

Shout be better now.


NTHMC college added

About college: www.nthmc.edu.np

@sandipsapkota1 I have to close this request without merging, because you requested to add a non-existent domain to this repository: ;; connection timed out; no servers could be reached Please ensure that you are familiar with this repository rules located at the bottom of this page and submit a new request with the correct information. Thank you for your understanding!


UI Changes for Exposure Windows - Text issues(EXPOSUREAPP-4037)

Fix Test issues in:
1- Overview screen
2- High risk detailed screen

Introduced a new string for default and DE translations

Introduced a new string for default and DE translations


Where can we change the waiting times for waypoints?

When launching a fleet adapter, the waypoints tend to have:

5-second waiting time between waypoints, where can we change that?
When no waypoints are assigned, there is a loop of a 30-second wait, where in the code can we change that or the parameter set in the python adapter?

Do they depend on the linear and angular speeds set for the robot in the config file as well?

5-second waiting time between waypoints, where can we change that?

I'm not sure what waiting time you're referring to. Can you elaborate on when and where you're seeing a 5-second wait?

When no waypoints are assigned, there is a loop of a 30-second wait

I think this is referring to the ResponsiveWait behavior which to be honest is a bit of a hack that wasn't meant to exist for as long as it has. Because it was meant to be a temporary hack there isn't an API for it, except to toggle it off entirely. If there's a particular reason for modifying the 30 seconds, it would be pretty easy to add an unstable API to do so, but I'm not sure what the value would be. I don't think you'll see qualitatively better traffic behavior outcomes by using a value that's more or less than 30s.

Do they depend on the linear and angular speeds set for the robot in the config file as well?

The linear and angular speeds only impact the trajectory predictions that the planner generates. They won't have any effect on any waiting behavior that might exist.

I'm not sure what waiting time you're referring to. Can you elaborate on when and where you're seeing a 5-second wait?
It happens between each waypoint sent. So when the robot moves to the waypoint and reaches it its stays there waiting some seconds until the next waypoint is sent. Is this related to the parameters of linear and angular speed and the planner calculating that that's the time it should take to reach there?
 think this is referring to the ResponsiveWait
Exactctly. Having issues with it because it sends the robot a goal every 30 seconds an this shouldn't be specially when the robot is docked ( because it gets our of the dock position). We are going around that by trying to ignore these goals when the robot is docked, but isn't there a better way to tell RMF that the robot is docked and that he doensthave to send goals every 30 seconds? Because otherwise we have to deal with it form the robot server side and even in the RobotHandler.

I’m encountering a similar problem. I’ve adapted rmf_demo RobotCommandHandle and written my own fleet_adapter. I’m currently using ROS2 Humble. The issue I’m facing is that the robot waits at every waypoint. When the distance between waypoints is large, the waiting time can sometimes extend to about 10 minutes. I’ve looked through the documentation but haven’t found any information on how to change this waiting time. I understand that a waiting time is assigned to every waypoint. This part of the code indicates that: waypoint_wait_time = self.target_waypoint.time. However, I couldn’t find where this waiting time is calculated. And I don't want to turning off completely.

Thank you for that information. Right now, I am unable to verify the newer version, but I’ll give it a try by the end of the week. Just to make sure, we’re talking about the updated implementation of OpenRMF for ROS2 Humble, right? If you could point me to a commit or a section of the code that I could look up and examine myself, I would really appreciate it.
The problem occurs while using our custom simulation created with Unity. This issue falls outside the RMF simulation concept. We can treat it like real robot but with ideal sensors.
Here is attachment of the screenshot which I took last time:

And here is part of road which produce that waiting time:

It is aligned and from the start to the end, it measures 410m.

Thank you for that information. Right now, I am unable to verify the newer version, but I’ll give it a try by the end of the week. Just to make sure, we’re talking about the updated implementation of OpenRMF for ROS2 Humble, right? If you could point me to a commit or a section of the code that I could look up and examine myself, I would really appreciate it.

Are you using the EasyFullControl API to implement your fleet adapter? If so, the point I mentioned about not making your robot wait should be handled by the underlying implementation of EasyFullControl. If you have your own RobotCommandHandle, make sure you're not explicitly waiting at a waypoint once oyur robot reaches the waypoint. This was done in the past, like in this example but is no longer required.

The problem occurs while using our custom simulation created with Unity. This issue falls outside the RMF simulation concept. We can treat it like real robot but with ideal sensors.

Ah we've never tested with Unity as the simulator. You will need to ensure that the clock behavior with Unity matches that with Gazebo. ROS nodes sync their time with the Gazebo clock by subscribing to the /clock topic that the ros_gz_bridge publishes. Unclear if clock sync is the problem in your case but it's worth ensuring your simulator works similar to Gazebo.

Okay, I’ve found a solution. Once you mentioned that the timepoint at the waypoint is calculated by the planner, I started wondering about the parameters that influence it. I then realized that my problem came from misunderstanding config file for the fleet adapter. In the config file there are lines telling about limits. At first, I treated it as if there were limits in some area. After investigating, I understood that limits were used to calculate the ‘arrival’ time at the waypoint too. My simulated robot was moving much faster than the limits, so it waited. If the distance between waypoints became longer, it waited longer.
Nonetheless, I will answer your question, so maybe it will help someone.

Are you using the EasyFullControl API to implement your fleet adapter?

I was using that template and modified only sections where it was mentioned by comments. And as you said I no longer require it. I am going to make adjustments to that particular section to ensure the entire loop functions properly.

You will need to ensure that the clock behavior with Unity matches that with Gazebo.

In Unity I am publishing my own clock which is properly scaled so that nodes can work properly.
Thank you for your help.


'no socket connections' with socket.io v1.3.2

When running the demo application I receive a no socket connections error in the browser. The package.json lists sockets.io as "^1.2.1 which when the packages are installed socket.io version is bumped to 1.3.2. If I explicity set the demo to use sockets.io v1.2.1 I do not receive this error.

@adam-beck which version of sc5-styleguide are you using? We released 0.3.2 today, which addresses the socket connection issue (port is ignored). The root cause is in<EMAIL_ADDRESS>https://github.com/Automattic/socket.io-client/issues/802

I was using a previous version.

The solution introduced in 0.3.2 is not perfect, as it assumes that users are connecting directly to the designated Express server port. Problems start when ports are forwarded.

+1
Also having issues with forwarded ports.

@andreipopovici we released 0.3.3 yesterday with a downgraded version of socket-io (1.2.1) which resolves socket endpoint port correctly. 0.3.4 is the latest sc5-styleguide version (minor cli argument bug fixed), please update.

Trying it as we speak :) Will update with progress.

0.3.4 works, we're running our demo site inside a Docker container, which forwards the internal port 3000 to something random like 49317 on the host machine, which again is mapped to 80 in nginx or apache.
http://demo.styleguide.sc5.io/

Socket.io seems to work fine after the update. Thanks!
Heads-up: a small typo in the Gulp instructions (the comma after this line):
var sass = require('gulp-sass'),

@andreipopovici no problem, and thanks, well spotted. Fixed it already, though.


Add new python versions - part 1

This PR adds new python versions on ubuntu builder.
I'll make a follow-up PR, which will drop old versions, after this PR is merged and dockerhub is updated.
On OS X we are installing python during travis run, so I made those updates in this PR.

Coverage remained the same at 96.233% when pulling 1381dbfd0b8a044a74b24588a65725b02ea52b3a on narekgharibyan:new_python_versions into fd24948e1a20bbaef2d9b35134a1a79d675a7eb0 on KeyviDev:master.

Sounds good, I am not sure what is wrong with osx, this might be due to the Travis Billing changes: https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing

So I think we can merge this and let dockerhub build new images. So I can create second PR.
Coverage is fine too.
I have already reverted OS X changes.
Wdyt ?

Disabled Mac builds.


maximum recursion depth exceeded issue when trying to retrieve entries

Hi we're using the python SDK and trying to retrieve list of entries of a specific type using this method
data = client.entries({"content_type": 'video'})
there are around 150 contents of this type and we're getting the following error
File "/Users/mesadat/Documents/content-recommender/venv/lib/python3.7/site-packages/contentful/resource.py", line 54, in _hydrate_sys
for k, v in item.get('sys', {}).items():
RecursionError: maximum recursion depth exceeded while calling a Python object
we are using the same method on other content types without an issue, they don't have as many entries so we're suspecting maybe the large number of content may be causing this error

We're facing the same issue. For us it's caused by cyclic references. So if have 2 pieces of content, A and B. A refers to B either via a reference field or an embed and then B refers to A either through a reference field or inline embed.

I believe limiting recursion depth should solve this issue:
max_include_resolution_depth=5
https://github.com/contentful/contentful.py#configuration

Unfortunately I got the same error. I also use the include filter in the query. I figure that would make a difference as well. The content we have setup does have a several references.

Hey @afraazali,
Which version of the SDK are you using? If using master, please update to the latest version of master, and reduce the client configuration parameter max_include_resolution_depth to a value equal or greater than your maximum include level. This will avoid resolving circular references for a long time and running into maximum recursion depth.
Please let me know if this helps,
Cheers

Hey @afraazali, @kasrazahir did the above comment help?

I'm having the same problem with 1.13.1.
client.entries({'limit': 1})

results in RecursionError: maximum recursion depth exceeded while calling a Python object
I tried using the max_include_resolution_depth parameter, as suggested above, but it's rejected by the server:
client.entries({'limit': 1, 'include': 1, 'max_include_resolution_depth': 1})

returns:
BadRequestError: HTTP status code: 400
Message: The query you sent was invalid. Probably a filter or ordering specification is not applicable to the type of a field.
Details: The path "max_include_resolution_depth" is not recognized

max_include_resolution_depth is an optional parameter on client initialization, not entry retrieval. example:  contetnful.Client(...,max_include_resolution_depth=XX)

I am also having this issue even with 1 include. I set reuse_entries to True in the client configuration and that seemed to help. I am on the latest version - 1.13.1

I took this approach as well.  Limiting depth didn't help.

Sure -  it's pretty much straight from the examples. I added the resue_entries param and that fixed the max recursion error.  Then I added timeout and retries params to solve some rate limit issues.
client = contentful.Client(
    space_id,
    api_key,
    reuse_entries=True,
    timeout_s=5,
    max_rate_limit_retries=3
)

entry = client.entry(entry_id)

So does it work then with resue_entries  param?

Yes, it works - I'll edit my comments to state the it works. Thanks!

For me the issue persists, even with
max_include_resolution_depth=0,
reuse_entries=True,
in Contentfull class initialization
and include=1 as query parameter :(