proposal: net/http: optimize http.Dir when files are not modified and add GODEBUG to preserve old behavior

Proposal: net/http: optimize http.Dir when files are not modified and add GODEBUG to preserve old behavior
Author(s): @qiualidongfeng
Last updated: 2023-11-19
Abstract
If there are no errors, http.Dir calls os.Open once every time Open is called. If the file has not changed, performance can be improved by reducing system calls by caching *os.File and []byte read from *os.File.
Background
Background as described above.
Proposals to optimize http.Dir.
Proposal
http.Dir.Open When the file modification time does not change, use the cached *os.FIle and []byte.
Add the GODEBUG environment variable httpdircache, go1.23 defaults to 1, enabling the behavior after the proposal implementation. Setting the value to 0 restores the previous behavior.
Rationale
1, directly change the behavior, when the file modification time is unchanged but the content changes, backward incompatible.
2, Third-party libraries, such as https://github.com/qiulaidongfeng/cachefs , This is a prototype written in a third-party library before sending CL to the standard library. The advantage is that it can be used less than go1.23, and the disadvantage is that the code needs to be manually modified to use.
Compatibility
100% backward compatibility with godebug=httpdircache=0.
Implementation
I  will send CL to implement the proposal, which is too close to go1.22 code freezing, so this proposal is for go1.23.

This significantly changes the memory propfile of a server using http.Dir, it becomes much easier to trigger an OOM DoS by requesting a large number of files that all get cached.

This significantly changes the memory propfile of a server using http.Dir, it becomes much easier to trigger an OOM DoS by requesting a large number of files that all get cached.

A path should cache only one copy of *os.File and []byte into sync.Map. If this uses too much memory, I can modify the proposal and CL to cache only small files.

As @seankhliao noted, caching can consume potentially unbounded memory. In addition, clients may want to be able to configure the cache policy, like how many files are cached, which files are cached, how long they are cached for, etc. It does not make sense for the standard library to impose one solution for the entire binary, nor does it make sense for the existing un-cached behavior to essentially be treated as deprecated, both of which are implied by the use of GODEBUG.
This should be a separate http.FileSystem implementation that clients can opt into. (And at that point it does not need to even be part of the standard library.)


"edge" if the ngrok edge should terminate TLS traffic, "upstream" if TLS
                      traffic should be passed through to the upstream ngrok agent /
                      application server for termination.
                    type: string
                type: object
              webhookVerification:
                description: WebhookVerification configuration for this module set
                properties:
                  provider:
                    description: |-
                      a string indicating which webhook provider will be sending webhooks to this
                      endpoint. Value must be one of the supported providers defined at
                      https://ngrok.com/docs/http/webhook-verification/#supported-providers
                    type: string
                  secret:
                    description: |-
                      SecretRef is a reference to a secret containing the secret used to validate
                      requests from the given provider. All providers except AWS SNS require a secret
                    properties:
                      key:
                        description: Key in the secret to use
                        type: string
                      name:
                        description: Name of the Kubernetes secret
                        type: string
                    type: object
                type: object
            type: object
        type: object
    served: true
    storage: true
    subresources:
      status: {}
---
# Source: kubernetes-ingress-controller/templates/crds/ingress.k8s.ngrok.com_tcpedges.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.14.0
  name: tcpedges.ingress.k8s.ngrok.com
spec:
  group: ingress.k8s.ngrok.com
  names:
    kind: TCPEdge
    listKind: TCPEdgeList
    plural: tcpedges
    singular: tcpedge
  scope: Namespaced
  versions:
  - additionalPrinterColumns:
    - description: Domain ID
      jsonPath: .status.id
      name: ID
      type: string
    - description: Hostports
      jsonPath: .status.hostports
      name: Hostports
      type: string
    - description: Tunnel Group Backend ID
      jsonPath: .status.backend.id
      name: Backend ID
      type: string
    - description: Age
      jsonPath: .metadata.creationTimestamp
      name: Age
      type: date
    name: v1alpha1
    schema:
      openAPIV3Schema:
        description: TCPEdge is the Schema for the tcpedges API
        properties:
          apiVersion:
            description: |-
              APIVersion defines the versioned schema of this representation of an object.
              Servers should convert recognized schemas to the latest internal value, and
              may reject unrecognized values.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
            type: string
          kind:
            description: |-
              Kind is a string value representing the REST resource this object represents.
              Servers may infer this from the endpoint the client submits requests to.
              Cannot be updated.
              In CamelCase.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
            type: string
          metadata:
            type: object
          spec:
            description: TCPEdgeSpec defines the desired state of TCPEdge
            properties:
              backend:
                description: |-
                  Backend is the definition for the tunnel group backend
                  that serves traffic for this edge
                properties:
                  description:
                    default: Created by kubernetes-ingress-controller
                    description: Description is a human-readable description of the
                      object in the ngrok API/Dashboard
                    type: string
                  labels:
                    additionalProperties:
                      type: string
                    description: Labels to watch for tunnels on this backend
                    type: object
                  metadata:
                    default: '{"owned-by":"kubernetes-ingress-controller"}'
                    description: Metadata is a string of arbitrary data associated
                      with the object in the ngrok API/Dashboard
                    type: string
                type: object
              description:
                default: Created by kubernetes-ingress-controller
                description: Description is a human-readable description of the object
                  in the ngrok API/Dashboard
                type: string
              ipRestriction:
                description: IPRestriction is an IPRestriction to apply to this edge
                properties:
                  policies:
                    items:
                      type: string
                    type: array
                type: object
              metadata:
                default: '{"owned-by":"kubernetes-ingress-controller"}'
                description: Metadata is a string of arbitrary data associated with
                  the object in the ngrok API/Dashboard
                type: string
              policy:
                description: raw json policy string that was applied to the ngrok
                  API
                type: object
                x-kubernetes-preserve-unknown-fields: true
            type: object
          status:
            description: TCPEdgeStatus defines the observed state of TCPEdge
            properties:
              backend:
                description: |-
                  Backend stores the status of the tunnel group backend,
                  mainly the ID of the backend
                properties:
                  id:
                    description: ID is the unique identifier for this backend
                    type: string
                type: object
              hostports:
                description: Hostports served by this edge
                items:
                  type: string
                type: array
              id:
                description: ID is the unique identifier for this edge
                type: string
              uri:
                description: URI is the URI of the edge
                type: string
            type: object
        type: object
    served: true
    storage: true
    subresources:
      status: {}
---
# Source: kubernetes-ingress-controller/templates/crds/ingress.k8s.ngrok.com_tlsedges.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.14.0
  name: tlsedges.ingress.k8s.ngrok.com
spec:
  group: ingress.k8s.ngrok.com
  names:
    kind: TLSEdge
    listKind: TLSEdgeList
    plural: tlsedges
    singular: tlsedge
  scope: Namespaced
  versions:
  - additionalPrinterColumns:
    - description: Domain ID
      jsonPath: .status.id
      name: ID
      type: string
    - description: Hostports
      jsonPath: .status.hostports
      name: Hostports
      type: string
    - description: Tunnel Group Backend ID
      jsonPath: .status.backend.id
      name: Backend ID
      type: string
    - description: Age
      jsonPath: .metadata.creationTimestamp
      name: Age
      type: date
    name: v1alpha1
    schema:
      openAPIV3Schema:
        description: TLSEdge is the Schema for the tlsedges API
        properties:
          apiVersion:
            description: |-
              APIVersion defines the versioned schema of this representation of an object.
              Servers should convert recognized schemas to the latest internal value, and
              may reject unrecognized values.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
            type: string
          kind:
            description: |-
              Kind is a string value representing the REST resource this object represents.
              Servers may infer this from the endpoint the client submits requests to.
              Cannot be updated.
              In CamelCase.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
            type: string
          metadata:
            type: object
          spec:
            description: TLSEdgeSpec defines the desired state of TLSEdge
            properties:
              backend:
                description: |-
                  Backend is the definition for the tunnel group backend
                  that serves traffic for this edge
                properties:
                  description:
                    default: Created by kubernetes-ingress-controller
                    description: Description is a human-readable description of the
                      object in the ngrok API/Dashboard
                    type: string
                  labels:
                    additionalProperties:
                      type: string
                    description: Labels to watch for tunnels on this backend
                    type: object
                  metadata:
                    default: '{"owned-by":"kubernetes-ingress-controller"}'
                    description: Metadata is a string of arbitrary data associated
                      with the object in the ngrok API/Dashboard
                    type: string
                type: object
              description:
                default: Created by kubernetes-ingress-controller
                description: Description is a human-readable description of the object
                  in the ngrok API/Dashboard
                type: string
              hostports:
                description: Hostports is a list of hostports served by this edge
                items:
                  type: string
                type: array
              ipRestriction:
                description: IPRestriction is an IPRestriction to apply to this edge
                properties:
                  policies:
                    items:
                      type: string
                    type: array
                type: object
              metadata:
                default: '{"owned-by":"kubernetes-ingress-controller"}'
                description: Metadata is a string of arbitrary data associated with
                  the object in the ngrok API/Dashboard
                type: string
              mutualTls:
                properties:
                  certificateAuthorities:
                    description: |-
                      List of CA IDs that will be used to validate incoming connections to the
                      edge.
                    items:
                      type: string
                    type: array
                type: object
              policy:
                description: raw json policy string that was applied to the ngrok
                  API
                type: object
                x-kubernetes-preserve-unknown-fields: true
              tlsTermination:
                properties:
                  minVersion:
                    description: MinVersion is the minimum TLS version to allow for
                      connections to the edge
                    type: string
                  terminateAt:
                    description: |-
                      TerminateAt determines where the TLS connection should be terminated.
                      "edge" if the ngrok edge should terminate TLS traffic, "upstream" if TLS
                      traffic should be passed through to the upstream ngrok agent /
                      application server for termination.
                    type: string
                type: object
            type: object
          status:
            description: TLSEdgeStatus defines the observed state of TLSEdge
            properties:
              backend:
                description: |-
                  Backend stores the status of the tunnel group backend,
                  mainly the ID of the backend
                properties:
                  id:
                    description: ID is the unique identifier for this backend
                    type: string
                type: object
              cnameTargets:
                additionalProperties:
                  type: string
                description: Map of hostports to the ngrok assigned CNAME targets
                type: object
              hostports:
                description: Hostports served by this edge
                items:
                  type: string
                type: array
              id:
                description: ID is the unique identifier for this edge
                type: string
              uri:
                description: URI is the URI of the edge
                type: string
            type: object
        type: object
    served: true
    storage: true
    subresources:
      status: {}
---
# Source: kubernetes-ingress-controller/templates/crds/ingress.k8s.ngrok.com_tunnels.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.14.0
  name: tunnels.ingress.k8s.ngrok.com
spec:
  group: ingress.k8s.ngrok.com
  names:
    kind: Tunnel
    listKind: TunnelList
    plural: tunnels
    singular: tunnel
  scope: Namespaced
  versions:
  - additionalPrinterColumns:
    - description: Service/port to forward to
      jsonPath: .spec.forwardsTo
      name: ForwardsTo
      type: string
    - description: Age
      jsonPath: .metadata.creationTimestamp
      name: Age
      type: date
    name: v1alpha1
    schema:
      openAPIV3Schema:
        description: Tunnel is the Schema for the tunnels API
        properties:
          apiVersion:
            description: |-
              APIVersion defines the versioned schema of this representation of an object.
              Servers should convert recognized schemas to the latest internal value, and
              may reject unrecognized values.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
            type: string
          kind:
            description: |-
              Kind is a string value representing the REST resource this object represents.
              Servers may infer this from the endpoint the client submits requests to.
              Cannot be updated.
              In CamelCase.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
            type: string
          metadata:
            type: object
          spec:
            description: TunnelSpec defines the desired state of Tunnel
            properties:
              appProtocol:
                description: The appProtocol for the backend. Currently only supports
                  `http2`
                type: string
              backend:
                description: The configuration for backend connections to services
                properties:
                  protocol:
                    type: string
                type: object
              forwardsTo:
                description: ForwardsTo is the name and port of the service to forward
                  traffic to
                type: string
              labels:
                additionalProperties:
                  type: string
                description: Labels are key/value pairs that are attached to the tunnel
                type: object
            type: object
          status:
            description: TunnelStatus defines the observed state of Tunnel
            type: object
        type: object
    served: true
    storage: true
    subresources:
      status: {}
---
# Source: kubernetes-ingress-controller/templates/crds/ngrok.k8s.ngrok.com_ngroktrafficpolicies.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  annotations:
    controller-gen.kubebuilder.io/version: v0.14.0
  name: ngroktrafficpolicies.ngrok.k8s.ngrok.com
spec:
  group: ngrok.k8s.ngrok.com
  names:
    kind: NgrokTrafficPolicy
    listKind: NgrokTrafficPolicyList
    plural: ngroktrafficpolicies
    singular: ngroktrafficpolicy
  scope: Namespaced
  versions:
  - name: v1alpha1
    schema:
      openAPIV3Schema:
        description: NgrokTrafficPolicy is the Schema for the ngroktrafficpolicies
          API
        properties:
          apiVersion:
            description: |-
              APIVersion defines the versioned schema of this representation of an object.
              Servers should convert recognized schemas to the latest internal value, and
              may reject unrecognized values.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
            type: string
          kind:
            description: |-
              Kind is a string value representing the REST resource this object represents.
              Servers may infer this from the endpoint the client submits requests to.
              Cannot be updated.
              In CamelCase.
              More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
            type: string
          metadata:
            type: object
          spec:
            description: NgrokTrafficPolicySpec defines the desired state of NgrokTrafficPolicy
            properties:
              policy:
                description: The raw json encoded policy that was applied to the ngrok
                  API
                type: object
                x-kubernetes-preserve-unknown-fields: true
            type: object
          status:
            description: NgrokTrafficPolicyStatus defines the observed state of NgrokTrafficPolicy
            properties:
              policy:
                description: The raw json encoded policy that was applied to the ngrok
                  API
                type: object
                x-kubernetes-preserve-unknown-fields: true
            type: object
        type: object
    served: true
    storage: true
    subresources:
      status: {}
---
# Source: kubernetes-ingress-controller/templates/controller-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ngrok-ingress-controller-proxy-role
rules:
- apiGroups:
  - authentication.k8s.io
  resources:
  - tokenreviews
  verbs:
  - create
- apiGroups:
  - authorization.k8s.io
  resources:
  - subjectaccessreviews
  verbs:
  - create
---
# Source: kubernetes-ingress-controller/templates/rbac/domain_editor_role.yaml
# permissions for end users to edit domains.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    helm.sh/chart: kubernetes-ingress-controller-0.14.1
    app.kubernetes.io/name: kubernetes-ingress-controller
    app.kubernetes.io/instance: ngrok-ingress-controller
    app.kubernetes.io/version: "0.12.1"
    app.kubernetes.io/part-of: kubernetes-ingress-controller
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: rbac
  name: ngrok-ingress-controller-kubernetes-ingress-controller-domain-editor-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - domains
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - domains/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/domain_viewer_role.yaml
# permissions for end users to view domains.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    helm.sh/chart: kubernetes-ingress-controller-0.14.1
    app.kubernetes.io/name: kubernetes-ingress-controller
    app.kubernetes.io/instance: ngrok-ingress-controller
    app.kubernetes.io/version: "0.12.1"
    app.kubernetes.io/part-of: kubernetes-ingress-controller
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: rbac
  name: ngrok-ingress-controller-kubernetes-ingress-controller-domain-viewer-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - domains
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - domains/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/httpsedge_editor_role.yaml
# permissions for end users to edit httpsedges.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: httpsedge-editor-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: ngrok-ingress-controller
    app.kubernetes.io/part-of: ngrok-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: httpsedge-editor-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - httpsedges
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - httpsedges/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/httpsedge_viewer_role.yaml
# permissions for end users to view httpsedges.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: httpsedge-viewer-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: ngrok-ingress-controller
    app.kubernetes.io/part-of: ngrok-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: httpsedge-viewer-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - httpsedges
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - httpsedges/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/ippolicy_editor_role.yaml
# permissions for end users to edit ippolicies.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: ippolicy-editor-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: ngrok-ingress-controller
    app.kubernetes.io/part-of: ngrok-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: ippolicy-editor-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ippolicies
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ippolicies/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/ippolicy_viewer_role.yaml
# permissions for end users to view ippolicies.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: ippolicy-viewer-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: ngrok-ingress-controller
    app.kubernetes.io/part-of: ngrok-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: ippolicy-viewer-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ippolicies
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ippolicies/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/ngrokmoduleset_editor_role.yaml
# permissions for end users to edit ngrokmodulesets.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: ngrokmoduleset-editor-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: kubernetes-ingress-controller
    app.kubernetes.io/part-of: kubernetes-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: ngrokmoduleset-editor-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ngrokmodulesets
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ngrokmodulesets/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/ngrokmoduleset_viewer_role.yaml
# permissions for end users to view ngrokmodulesets.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: ngrokmoduleset-viewer-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: kubernetes-ingress-controller
    app.kubernetes.io/part-of: kubernetes-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: ngrokmoduleset-viewer-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ngrokmodulesets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ngrokmodulesets/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: ngrok-ingress-controller-manager-role
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - create
  - delete
  - get
  - list
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
- apiGroups:
  - ""
  resources:
  - namespaces
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - secrets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - services
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ""
  resources:
  - services/status
  verbs:
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - gateway.networking.k8s.io
  resources:
  - gatewayclasses
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - gateway.networking.k8s.io
  resources:
  - gatewayclasses/status
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - gateway.networking.k8s.io
  resources:
  - gateways
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - gateway.networking.k8s.io
  resources:
  - gateways/status
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - gateway.networking.k8s.io
  resources:
  - httproutes
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - gateway.networking.k8s.io
  resources:
  - httproutes/status
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - domains
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - domains/finalizers
  verbs:
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - domains/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - httpsedges
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - httpsedges/finalizers
  verbs:
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - httpsedges/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ippolicies
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ippolicies/finalizers
  verbs:
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ippolicies/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - ngrokmodulesets
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tcpedges
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tcpedges/finalizers
  verbs:
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tcpedges/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tlsedges
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tlsedges/finalizers
  verbs:
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tlsedges/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tunnels
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tunnels/finalizers
  verbs:
  - update
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tunnels/status
  verbs:
  - get
  - patch
  - update
- apiGroups:
  - networking.k8s.io
  resources:
  - ingressclasses
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - ingresses
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - networking.k8s.io
  resources:
  - ingresses/status
  verbs:
  - get
  - list
  - update
  - watch
- apiGroups:
  - ngrok.k8s.ngrok.com
  resources:
  - ngroktrafficpolicies
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ngrok.k8s.ngrok.com
  resources:
  - ngroktrafficpolicies/finalizers
  verbs:
  - update
- apiGroups:
  - ngrok.k8s.ngrok.com
  resources:
  - ngroktrafficpolicies/status
  verbs:
  - get
  - patch
  - update
---
# Source: kubernetes-ingress-controller/templates/rbac/tcpedge_editor_role.yaml
# permissions for end users to edit tcpedges.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: tcpedge-editor-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: ngrok-ingress-controller
    app.kubernetes.io/part-of: ngrok-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: tcpedge-editor-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tcpedges
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tcpedges/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/tcpedge_viewer_role.yaml
# permissions for end users to view tcpedges.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: tcpedge-viewer-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: ngrok-ingress-controller
    app.kubernetes.io/part-of: ngrok-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: tcpedge-viewer-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tcpedges
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tcpedges/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/tlsedge_editor_role.yaml
# permissions for end users to edit tlsedges.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: tlsedge-editor-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: ngrok-ingress-controller
    app.kubernetes.io/part-of: ngrok-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: tlsedge-editor-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tlsedges
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tlsedges/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/tlsedge_viewer_role.yaml
# permissions for end users to view tlsedges.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    app.kubernetes.io/name: clusterrole
    app.kubernetes.io/instance: tlsedge-viewer-role
    app.kubernetes.io/component: rbac
    app.kubernetes.io/created-by: ngrok-ingress-controller
    app.kubernetes.io/part-of: ngrok-ingress-controller
    app.kubernetes.io/managed-by: kustomize
  name: tlsedge-viewer-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tlsedges
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tlsedges/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/tunnel_editor_role.yaml
# permissions for end users to edit tunnels.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    helm.sh/chart: kubernetes-ingress-controller-0.14.1
    app.kubernetes.io/name: kubernetes-ingress-controller
    app.kubernetes.io/instance: ngrok-ingress-controller
    app.kubernetes.io/version: "0.12.1"
    app.kubernetes.io/part-of: kubernetes-ingress-controller
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: rbac
  name: ngrok-ingress-controller-kubernetes-ingress-controller-tunnel-editor-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tunnels
  verbs:
  - create
  - delete
  - get
  - list
  - patch
  - update
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tunnels/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/rbac/tunnel_viewer_role.yaml
# permissions for end users to view tunnels.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    helm.sh/chart: kubernetes-ingress-controller-0.14.1
    app.kubernetes.io/name: kubernetes-ingress-controller
    app.kubernetes.io/instance: ngrok-ingress-controller
    app.kubernetes.io/version: "0.12.1"
    app.kubernetes.io/part-of: kubernetes-ingress-controller
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: rbac
  name: ngrok-ingress-controller-kubernetes-ingress-controller-tunnel-viewer-role
rules:
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tunnels
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - ingress.k8s.ngrok.com
  resources:
  - tunnels/status
  verbs:
  - get
---
# Source: kubernetes-ingress-controller/templates/controller-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ngrok-ingress-controller-manager-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ngrok-ingress-controller-manager-role
subjects:
- kind: ServiceAccount
  name: ngrok-ingress-controller-kubernetes-ingress-controller
  namespace: ngrok-ingress-controller
---
# Source: kubernetes-ingress-controller/templates/controller-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: ngrok-ingress-controller-proxy-rolebinding
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: ngrok-ingress-controller-proxy-role
subjects:
- kind: ServiceAccount
  name: ngrok-ingress-controller-kubernetes-ingress-controller
  namespace: ngrok-ingress-controller
---
# Source: kubernetes-ingress-controller/templates/controller-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ngrok-ingress-controller-leader-election-role
  namespace: ngrok-ingress-controller
rules:
- apiGroups:
  - ""
  resources:
  - configmaps
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - coordination.k8s.io
  resources:
  - leases
  verbs:
  - get
  - list
  - watch
  - create
  - update
  - patch
  - delete
- apiGroups:
  - ""
  resources:
  - events
  verbs:
  - create
  - patch
---
# Source: kubernetes-ingress-controller/templates/controller-rbac.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ngrok-ingress-controller-leader-election-rolebinding
  namespace: ngrok-ingress-controller
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ngrok-ingress-controller-leader-election-role
subjects:
- kind: ServiceAccount
  name: ngrok-ingress-controller-kubernetes-ingress-controller
  namespace: ngrok-ingress-controller
---
# Source: kubernetes-ingress-controller/templates/controller-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    helm.sh/chart: kubernetes-ingress-controller-0.14.1
    app.kubernetes.io/name: kubernetes-ingress-controller
    app.kubernetes.io/instance: ngrok-ingress-controller
    app.kubernetes.io/version: "0.12.1"
    app.kubernetes.io/part-of: kubernetes-ingress-controller
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: controller
  name: ngrok-ingress-controller-kubernetes-ingress-controller-manager
  namespace: ngrok-ingress-controller
  annotations:
    checksum/controller-role: 7a410be28b1592797fe68e262cc5a7c24a8c3c6aaff67b396203315b701818e7
    checksum/rbac: f91fd21c0e331efb3c41a4551b81ba429616fbf9bb3079c64e0284a7612ca47b
spec:
  replicas: 1
  selector:
    matchLabels:
      app.kubernetes.io/name: kubernetes-ingress-controller
      app.kubernetes.io/instance: ngrok-ingress-controller
      app.kubernetes.io/component: controller
  template:
    metadata:
      annotations:
        prometheus.io/path: /metrics
        prometheus.io/port: '8080'
        prometheus.io/scrape: 'true'
        checksum/controller-role: 7a410be28b1592797fe68e262cc5a7c24a8c3c6aaff67b396203315b701818e7
        checksum/rbac: f91fd21c0e331efb3c41a4551b81ba429616fbf9bb3079c64e0284a7612ca47b
        checksum/secret: 283e53865ad5f9d238d51716535c045f767c31a318c95c28af579c045680959e
      labels:
        app.kubernetes.io/name: kubernetes-ingress-controller
        app.kubernetes.io/instance: ngrok-ingress-controller
        app.kubernetes.io/component: controller
    spec:
      affinity:
        podAffinity:

        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
            - podAffinityTerm:
                labelSelector:
                  matchLabels:
                    app.kubernetes.io/instance: ngrok-ingress-controller
                    app.kubernetes.io/name: kubernetes-ingress-controller
                    app.kubernetes.io/component: controller
                topologyKey: kubernetes.io/hostname
              weight: 1
        nodeAffinity:

      serviceAccountName: ngrok-ingress-controller-kubernetes-ingress-controller
      containers:
      - name: ngrok-ingress-controller
        image: docker.io/ngrok/kubernetes-ingress-controller:0.12.1
        imagePullPolicy: IfNotPresent
        command:
        - /manager
        args:
        - --controller-name=k8s.ngrok.com/ingress-controller
        - --zap-log-level=info
        - --zap-stacktrace-level=error
        - --zap-encoder=json
        - --health-probe-bind-address=:8081
        - --metrics-bind-address=:8080
        - --election-id=ngrok-ingress-controller-kubernetes-ingress-controller-leader
        - --manager-name=ngrok-ingress-controller-kubernetes-ingress-controller-manager
        securityContext:
          allowPrivilegeEscalation: false
        env:
        - name: NGROK_API_KEY
          valueFrom:
            secretKeyRef:
              key: API_KEY
              name: ngrok-ingress-controller-kubernetes-ingress-controller-credentials
        - name: NGROK_AUTHTOKEN
          valueFrom:
            secretKeyRef:
              key: AUTHTOKEN
              name: ngrok-ingress-controller-kubernetes-ingress-controller-credentials
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        livenessProbe:
          httpGet:
            path: /healthz
            port: 8081
          initialDelaySeconds: 15
          periodSeconds: 20
        readinessProbe:
          httpGet:
            path: /readyz
            port: 8081
          initialDelaySeconds: 5
          periodSeconds: 10
        resources:
          limits: {}
          requests: {}
---
# Source: kubernetes-ingress-controller/templates/ingress-class.yaml
apiVersion: networking.k8s.io/v1
kind: IngressClass
metadata:
  labels:
    helm.sh/chart: kubernetes-ingress-controller-0.14.1
    app.kubernetes.io/name: kubernetes-ingress-controller
    app.kubernetes.io/instance: ngrok-ingress-controller
    app.kubernetes.io/version: "0.12.1"
    app.kubernetes.io/part-of: kubernetes-ingress-controller
    app.kubernetes.io/managed-by: Helm
    app.kubernetes.io/component: controller
  name: ngrok
spec:
  controller: k8s.ngrok.com/ingress-controller

NOTES:
================================================================================
The ngrok Ingress controller has been deployed as a Deployment type to your
cluster.

If you haven't yet, create some Ingress resources in your cluster and they will
be automatically configured on the internet using ngrok.

One example, taken from your cluster, is the Service:
   "game-2048"

You can make this accessible via ngrok with the following manifest:
--------------------------------------------------------------------------------
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: game-2048
  namespace: ngrok-ingress-controller
spec:
  ingressClassName: ngrok
  rules:
  - host: game-2048-fu3zm54o.ngrok.app
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: game-2048
            port:
              number: 80
--------------------------------------------------------------------------------
Applying this manifest will make the service "game-2048"
available on the public internet at "https://game-2048-fu3zm54o.ngrok.app/".

Once done, view your edges in the Dashboard https://dashboard.ngrok.com/cloud-edge/edges
Find the tunnels running in your cluster here https://dashboard.ngrok.com/tunnels/agents

If you have any questions or feedback, please join us in https://ngrok.com/slack and let us know!

The logs look quite normal to me. I tried re-creating as close as possible but I haven't had any luck with it yet.

kind create cluster --image=kindest/node:v1.30.3
Similar output to what you have above when running helm install:

helm-3.15.4 upgrade --install ngrok-ingress-controller ngrok/kubernetes-ingress-controller \
  --debug --namespace ngrok-ingress-controller \
  --create-namespace \
  --set credentials.apiKey=$NGROK_API_KEY \
  --set credentials.authtoken=$NGROK_AUTHTOKEN

Trying to get the tunnels just says no resources

kubectl get tunnels
No resources found in default namespace

The only other thing I would try is to confirm that the CRDs did get installed like so:
kubectl get customresourcedefinitions.apiextensions.k8s.io | grep "ngrok"

You should see something like this:
domains.ingress.k8s.ngrok.com              2024-08-27T04:52:14Z
httpsedges.ingress.k8s.ngrok.com           2024-08-27T04:52:14Z
ippolicies.ingress.k8s.ngrok.com           2024-08-27T04:52:14Z
ngrokmodulesets.ingress.k8s.ngrok.com      2024-08-27T04:52:14Z
ngroktrafficpolicies.ngrok.k8s.ngrok.com   2024-08-27T04:52:14Z
tcpedges.ingress.k8s.ngrok.com             2024-08-27T04:52:14Z
tlsedges.ingress.k8s.ngrok.com             2024-08-27T04:52:14Z
tunnels.ingress.k8s.ngrok.com              2024-08-27T04:52:14Z

@ricardosilva86, I added a github actions pipeline to test this with different k8s & helm versions using kind, but still haven't been able to recreate.
If you can find a way to repro the issue though, let us know and we'll keep looking into it.


Add "Find the Shortest Path in a Weighted Graph" question

SkillShow! 🎊🎈
Welcome! 🎉
Thank you for visiting our repository! We're excited to have you here. If you find this project useful, please consider giving it a star! ⭐
🎉 Have you reviewed the Contributing Guidelines? 🤔 (Required)

[x] YES
[ ] NO

📝 Description

Implemented Dijkstra's algorithm using a priority queue
Added example usage and output
Improved code readability and formatting
Defined graph and nodes explicitly

🔧 Fixes #issue_no (Required)
#21
🏷 Initiative Participation (Required)
This pull request is associated with the following initiative. Please choose the one you are contributing to:

[ ] 🌸 GSSoC (Girl Script Summer of Code)
[ ] 🌼 GSSoC 2024 Extd.
[x] 🍂 Hacktoberfest 2024
[ ] ❄ Script Winter of Code (SWoC)
[ ] ⛄ Winter of Blockchain (WoB)
[ ] 🙋♂ Personal
[ ] 📌 Other (please specify): _______________

I have solved the conflict, please review @Kushal997-das


Applying state-dependent ArcCost

Please consider the specific ambition:  Penalize any vehicle that travels empty (no load) between any 2 Nodes per each mile/minute traveled.  Any way to achieve this w/o using DependentDimension (#339) ?
Naturally, I do not know in advance which vehicle will travel between which nodes ...

If you have AddDimensionDependentDimensionWithVehicleCapacity binded in your language does it fix your problem ?

This feature should allow many interesting things!
But can that DependentDimension affect the ArcCost (which the solver minimizes) or should be used to apply additional contraints?
If the latter, we could probably apply Max on the cumulative value of this dimension, or maybe try to minimize that value? Not sure ...

You're right AddDimensionDependentDimensionWithVehicleCapacity() will affect the local search when trying to optimize the route not the "ArcCost" used during the first strategy step.
also unfortunately this "cost dimension" has no name so you can't use Dimension* GetDimensionOrDie("name") on it :disappointed:

(hoping it will be added ...) So using AddDimensionDependentDimensionWithVehicleCapacity() can still allow directing the solver to minimize travel with zero-load during the local search?
Is there any better explanation/example of using DependantDimension, on top of a few lines found in Routing.h
(  // Creates a dimension with transits depending on the cumuls of another
// dimension. 'pure_transits' are the per-vehicle fixed transits as above.
// 'dependent_transits' is a vector containing for each vehicle a function
// taking two nodes and returning a function taking a dimension cumul value
// and returning a transit value. 'base_dimension' indicates the dimension
// from which the cumul variable is taken. If 'base_dimension' is nullptr,
// then the newly created dimension is self-based.)

Unfortunately I didn't have time to work on #574 currently

Any partial modules/steps that I could help with and make this happen?

I would say yes since the ArcCost are part of the objective cost computation and the solver will try to minimize it...

This feature is still experimental.
I recommend not using it for the time being.


Validating text/plain files

Laravel Version: 6.18.3
PHP Version: 7.3.2
Database Driver & Version: MySQL 5.7

Description:
Validating of plain text files is failed
Steps To Reproduce:
In validating rules add:
'somefile' => 'mimes:txt'
or
'somefile' => 'mimetypes:text/plain'
and try to upload .txt file
You will get error that validating is failed
Now I have to use custom rule:
<?php

namespace App\Rules;

use Illuminate\Contracts\Validation\Rule;
use function GuzzleHttp\Psr7\mimetype_from_extension;

class FileExtRule implements Rule
{
    /**
     * @var array
     */
    private $ext;

    /**
     * @var array
     */
    private $mime = [];

    /**
     * Create a new rule instance.
     *
     * @param  array|string  $ext
     *
     * @return void
     */
    public function __construct($ext)
    {
        $this->ext = $ext;
        if (is_string($ext)) {
            $this->ext = explode(',', $ext);
        }
        foreach ($this->ext as $e) {
            $m = mimetype_from_extension($e);
            if (! $m) {
                continue;
            }
            $this->mime[] = $m;
        }
    }

    /**
     * Determine if the validation rule passes.
     *
     * @param  string  $attribute
     * @param  mixed  $value
     *
     * @return bool
     */
    public function passes($attribute, $value)
    {
        $mime = $value->getClientMimeType();

        return in_array($mime, $this->mime);
    }

    /**
     * Get the validation error message.
     *
     * @return string
     */
    public function message()
    {
        return sprintf("Field :attribute must be of any of these types: %s", implode(', ', $this->ext));
    }
}

and use if smth like this:
'file' => new FileExtRule('txt')

The validation rules work for me.

im having same problem

Same here, some txt files don't pass the laravel validations

open up, it doesn't work, for exp if u will create txt, u can't load it bc of mimetype application/x-empty
in laravel txt is text/plan
same if u change ext to csv, mimetype didn't change but it can be csv data in there


⚠ Fetchers has degraded performance

In 5972c6e, Fetchers ($STATUS_URL) experienced degraded performance:

HTTP code: 200
Response time: 619 ms

Resolved: Fetchers performance has improved in 1a4b4a8.


Create brief description of time strings and link to from all mentions of "time string" in docstrings

There doesn't seem to be a concise explanation of time string formatting. Understanding how to specify time shouldn't require reading through the whole doc page for core.time—and I don't think it's actually stated there (though maybe I'm looking in the wrong place). I think we should probably have a table/brief description enumerating the units and how to specify them. This explanation should then be linked to at any mention of time strings in the docs/docstrings.

This is comprehended in #531  -- see the Time page, and give some feedback (or make the PR directly!)


WIP: [Tech Design] Replace fs cache with redis

Feature technical design
Summary
Summary
The web app uses a Node.js cache-manager to cache all GitHub responses to prevent the web app from getting GitHub API rate limited. These GitHub requests vary from fetching repository information, traversing GitHub trees, to primarily fetching GitHub file content to read carbon.yml files and MDX files for web page content.
We're currently using a file system store engine (https://www.npmjs.com/package/cache-manager-fs-hash), which was chosen during v1 preview prototyping as a quick and easy way to prevent GitHub API rate limits.
As we index more content (asset documentation pages), each GitHub request per MDX file adds to the amount of cached responses. Our current build pipeline does not persist cached files written to disk between builds.
As the amount of indexed content grows, so does the risk of our production GitHub access tokens getting rate limited which could leave us with a production environment void of all content.
Potential solution
To mitigate that risk, until we can create proper back-end services for this, what if we added Redis stores for staging and production? It looks like we could use a Redis store listed here: https://github.com/BryanDonovan/node-cache-manager#store-engines
Those Redis store engines should share the same API as cache-manager-fs-hash, so that should require minimal web app changes.
We could keep the 1 hour TTL for cached responses, so for Next.js ISR pages, content from GitHub would be at most 1 hour stale.
With a Redis cache, our production builds should be faster because there's a greater chance of a cache hit.
We could use a Redis cache for local development too, or for simplicity, keep that with the current file system cache.
TL;DR:
In the event that our production environment gets rate limited by GitHub, because the Redis cache would be persisted, we wouldn't lose web app content between deploys. Also, it would be neat to see how many keys would get cached in Redis, to give us a better idea of to-be infrastructure needs to manage GitHub content.
TODO: vv Everything below this vv
Research

[ ] Approved?

Unanswered questions

List any unknowns and unanswered questions that need answers prior to beginning development

New technologies

List new technologies that need to be explored in detail before beginning development

Proofs of concept

List proofs of concept that need to be completed before beginning development

UI/UX design
Does this feature have any associated UI/UX? If so, describe any design that needs to be
completed/red-lined prior to development.
APIs

[ ] Approved?

Programmatic APIs

List any APIs that will be developed and made available in the @carbon-platform/api package,
including function/class/method names, parameters, and return values.

Messages

List any new/changed RabbitMQ messages introduced by this feature, the message payload structure
associated with them, whether they are queries or emits, and their expected return values (for
queries).

Test strategy

[ ] Approved?

How will the new feature be tested? (e.g. unit tests, manual verification, automated e2e testing,
etc.)
What interesting edge cases should be considered and tested?
Security

[ ] Approved?

What new data is created/stored/collected/transmitted by this feature? How is that data secured? Who
is allowed to access it? How is that access controlled?
Think like a hacker. How might someone attempt to break or abuse this feature?
Error handling
Ignore the happy path. What can go wrong with this feature? How will the error conditions manifest
through the APIs? How will users be informed about these errors?
Logging

[ ] Approved?

Detail any FFDC data (info, warning, error, debug logs) to be captured by this feature.
File and code layout

[ ] Approved?

Describe how the files and code for this feature will fit into the rest of the mono repo. Will there
be a new package/service? Are there existing files/directories in which the new logic should live?
Issue and work breakdown

[ ] Approved?

List any issues that should be created prior to starting work on this feature

Epics

...

Issues

...

Closing as not planned per @jdharvey-ibm's recommendation. We don't expect our current content needs will get GitHub API rate limited. We can re-evaluate our caching needs when we have a service in place that provides its GitHub data to the data graph. Assuming we have that, it's unlikely that we'll need a centralized data cache.


Update eslint to version 4

Remove the ignore for greenkeeper from within package.json too.

Fixed in #24

Done in #24


Separate WSL updates from Windows updates

Re: https://www.neowin.net/news/microsoft-will-unbundle-its-edge-browser-from-the-windows-10-os-with-redstone-3
4265 people worldwide have starred this repository. Assuming half of them use WSL, it would be 2132.
53* people worldwide use Edge. WSL is used by 40 times more people than Edge.
Given that. I think @bitcrazed should launch an internal lobbying effort to separate WSL updates from Windows. You guys lost quite a few people who were initially enthused and downloaded the Anniversary update only to find that there are some very minor issues which were dealbreakers. Should such a situation arise again, I wouldn't want the community to get smaller because a larger community means more help for everyone.
* Sorry for the exaggeration it's probably in single digits...

I guess the main question is, if it is technically feasible to separate the two as some new features probably depend on changes in the windows kernel.
If on the other hand most of the work is done in the driver and the console nowadays, I'd also very much like to see a decupling of the two.
Btw.: I'm not sure if an even faster release cycle (with probably more bugs) would improve the image of the WSL. AFAIK MS us taking a lot of heat for releasing VS2017 early and a buggy state and now iterating very quickly on it. While I look with envy on the new Features that are available for insiders, I guess stability and consistency across multiple computers are much more important for most serious users.

@SRGOM dumping on someone's product then asking for a feature in the same sentence is generally in poor taste.
That aside, updating WSL and updating Edge are very different. WSL is implemented in the kernel, Edge is not.

@MikeGitb I agree with you re the update system. I remember even 8 months back, the majority of work was in drive and console. And I'd (and others) would love to have those working without using the insider builds.
I have hope for WSL. It's a ridiculously amazing piece of magic. At the same time, people are very impatient with MS for some of the earlier software they churned out so when you don't see any fixes for 6 months, you're not likely to trust them again. I think regular updates would send a message that, yes, we're listening. I don't think it's fair to expect devs to run alpha/beta quality Windows builds just for this feature.

@SRGOM: I'm also someone who will certainly not switch to an unstable OS-version just to get the latest updates for a developer tool, so I'm "hurt" by this policy too.
To be fair however, MS is already shipping updates for the WSL once or twice per year, which isn't too bad if you compare it to other developer tools. I'm mostly familiar with c++ tools and e.g. gcc is shipping a major update once per year, clang roughly twice, VS needs one or two years to release a new version (although they have started to ship more feature updates recently). So one update every 6-12 month is imho not really slow. What they are missing however are the intermediate bugfix/improvement releases you get from most other tools (issue https://github.com/Microsoft/BashOnWindows/issues/1911 tangles that topic).
Again, I don't know what their internal dev process looks like and what dependencies they have, but having those intermediate releases usually doesn't come for free and for now I'm content with them focusing on shipping new features with the next Win10 release instead of spending time on back porting features/fixes to the current release.
Regarding changes to the console, you should also not forget that the consol is used by a lot more people than the WSL, so shipping beta quality console updates to a production environment would probably not be appreciated by most users.
Finally, regarding your initial statement: I know this was meant as a joke, but you can bet that Edge is used by many more people (I'd guess orders of magnitude more) than the WSL so I'm pretty sure it is not easy for the team to argue that they should get the same treatment as Edge just based on this.

@MikeGitb I guess I was wrong about Console, yeah. Powershell users use it.
Although I still stand by non-Console improvements to be shipped continuously, given that its a:

Beta product, as claimed by MS
Work will never "finish" on such a thing. There will always be something that will be missing and investing in WSL when you know that you'll have to wait at least 6 months for it to show up would be a non-starter for most. I setup Windows after 4 years in Aug 2016 only to be bitten by SBT issue. I decided to come back (have most things I need now) but I know people in similar situation didn't. That's just distrust of MS...

I know Edge is used a lot (apparently 5% of entire internet browsing) and is actually a decent browser although Microsoft talked it up before it was ready. It was mean of me, sorry. But I hate it when if you disable msn on your computer then Ctrl-t requires an additional alt-d to start typing address. Hard for me to take such a browser seriously... :)
iwr cin.st | iex   ; choco install firefox (Don't use cin.st, use https://chocolatey.org/install.ps1)

LOL :) Love the idea but WSL is not an app or a bolt-on feature:
WSL is built into the Windows kernel and is highly dependent upon, and coupled to, many other kernel features (e.g. networking, filesystem, PicoProcess). Many of these kernel features are also evolving to provide additional features to support new requirements from WSL.
If we shipped WSL separately to the rest of the kernel, we'd have to also ship an accompanying network infrastructure, filesystem, process management infrastructure, etc. WSL would end up being WSL + a boatload of the kernel anyhow, defeating the entire point.
The Console, on the other hand operates in a client-server manner with any command-line application you attach it to. Thus, there's a far higher likelihood that we'll be able to ship some version of the Console on a separate schedule & via a separate vehicle than the OS. No firm plans in place for this yet - but we are keen to explore some of these possibilities in the future.
Note that the fast-ring Insiders builds are essentially weekly snapshots of the next version of Windows as its being built. If you don't like that rate of change, slow ring is an ~monthly snapshot. Still to fast for you? Wait for the new releases every 6 months or so!

To put this in perspective - we've gone from delivering major Windows releases once every 3+ years to once a week if you can tolerate the pace of change and potential issues that escape our testing!

So, appreciate the thought, but I think, as you can see above, this ain't gonna happen any time soon! ;) Closing.

Rich, thank you for answering.  I get your point. +1 to the separate  console..


[SPARK-24654][BUILD] Update, fix LICENSE and NOTICE, and specialize for source vs binary

Whew, lots of work to track down again all the license requirements, but this ought to be a pretty good pass. Below, find a writeup on how I approached it for future reference.

LICENSE and NOTICE and licenses/ now reflect the source release
LICENSE-binary and NOTICE-binary and licenses-binary now reflect the binary release
Recreated all the license info from scratch
Added notes about how this was constructed for next time
License-oriented info was moved from NOTICE to LICENSE, esp. for Cat B deps
Some seemingly superfluous or stale license info was removed, especially for test-scope deps
Updated release script to put binary-oriented versions in binary releases

Principles
ASF projects distribute source and binary code under the Apache License 2.0. However these project distributions frequently include copies of source or binary code from third parties, under possibly other license terms. This triggers conditions of those licenses, which essentially amount to including license information in a LICENSE and/or NOTICE file, and including copies of license texts (here, in a directory called license/).
See http://www.apache.org/dev/licensing-howto.html and https://www.apache.org/legal/resolved.html#required-third-party-notices
In Spark
Spark produces source releases, and also binary releases of that code. Spark source code may contain source from third parties, possibly modified. This is true in Scala, Java, Python and R, and in the UI's JavaScript and CSS files. These must be handled appropriately per above in a LICENSE and NOTICE file created for the source release.
Separately, the binary releases may contain binary code from third parties. This is very much true for Scala and Java, as Spark produces an 'assembly' binary release which includes all transitive binary dependencies of this part of Spark. With perhaps the exception of py4j, this doesn't occur in the same way for Python or R because of the way these ecosystems work. (Note that the JS and CSS for the UI will be in both 'source' and 'binary' releases.) These must also be handled in a separate LICENSE and NOTICE file for the binary release.
Binary Release License
Transitive Maven Dependencies
We'll first tackle the binary release, and that almost entirely means assessing the transitive dependencies of the Scala/Java backbone of Spark.
Run project-info-reports:dependencies with essentially all profiles: a set that would bring in all different possible transitive dependencies. However, don't activate any of the '-lgpl' profiles as these would bring in LGPL-licensed dependencies that are explicitly excluded from Spark binary releases.
mvn -Phadoop-2.7 -Pyarn -Phive -Pmesos -Pkubernetes -Pflume -Pkinesis-asl -Pdocker-integration-tests -Phive-thriftserver -Pkafka-0-8 -Ddependency.locations.enabled=false project-info-reports:dependencies

Open assembly/target/site/dependencies.html. Find "Project Transitive Dependencies", and find "compile" and "runtime" (if exists). This is a list of all the dependencies that Spark is going to ship in its binary "assembly" distro and therefore whose licenses need to be appropriately considered in LICENSE and NOTICE. Copy this table into a spreadsheet for easy management.
Next job is to fill in some blanks, as a few projects will not have clearly declared their licenses in a POM. Sort by license.
This is a good time to verify all the dependencies are at least Cat A/B licenses, and not Cat X! http://www.apache.org/legal/resolved.html
Apache License 2
The Apache License 2 variants are typically easiest to deal with as they will not require you to modify LICENSE, nor add to license/. It's still good form to list the ALv2 dependencies in LICENSE for completeness, but optional.
They may require you to propagate bits from NOTICE. It's tedious to track down all the NOTICE files and evaluate what if anything needs to be copied to NOTICE.
Fortunately, this can be made easier as the assembly module can be temporarily modified to produce a NOTICE file that concatenates all NOTICE files bundled with transitive dependencies.
First change the packaging of assembly/spark-assembly_2.11/pom.xml to <packaging>jar</packaging>. Next add this stanza somewhere in the body of the same POM file:
<plugin>
  <groupId>org.apache.maven.plugins</groupId>
  <artifactId>maven-shade-plugin</artifactId>
  <configuration>
    <shadedArtifactAttached>false</shadedArtifactAttached>
    <artifactSet>
      <includes>
        <include>*:*</include>
      </includes>
    </artifactSet>
  </configuration>
  <executions>
    <execution>
      <phase>package</phase>
      <goals>
        <goal>shade</goal>
      </goals>
      <configuration>
        <transformers>
          <transformer implementation="org.apache.maven.plugins.shade.resource.ApacheNoticeResourceTransformer"/>
        </transformers>
      </configuration>
    </execution>
  </executions>
</plugin>

Finally execute mvn ... package with all of the same -P profile flags as above. In the JAR file at assembly/target/spark-assembly_2.11....jar you'll find a file META-INF/NOTICE that concatenates all NOTICE files bundled with transitive dependencies. This should be the starting point for the binary release's NOTICE file.
Some elements in the file are from Spark itself, like:
Spark Project Assembly
Copyright 2018 The Apache Software Foundation

Spark Project Core
Copyright 2018 The Apache Software Foundation

These can be removed.
Remove elements of the combined NOTICE file that aren't relevant to Spark. It's actually rare that we are sure that some element is completely irrelevant to Spark, because each transitive dependency includes all its transitive dependencies. So there may be nothing that can be done here.
Of course, some projects may not publish NOTICE in their Maven artifacts. Ideally, search for the NOTICE file of projects that don't seem to have produced any text in NOTICE, but, there is some argument that projects that don't produce a NOTICE in their Maven artifacts don't entail an obligation on projects that depend solely on their Maven artifacts.
Other Licenses
Next are "Cat A" permissively licensed (BSD 2-Clause, BSD 3-Clause, MIT) components. List the components grouped by their license type in LICENSE. Then add the text of the license to licenses/. For example if you list "foo bar" as a BSD-licensed dependency, add its license text as licenses/LICENSE-foo-bar.txt.
Public domain and similar works are treated like permissively licensed dependencies.
And the same goes for all Cat B licenses too, like CDDL. However these additional require at least a URL pointer to the project's page. Use the artifact hyperlink in your spreadsheet if possible; if non-existent or doesn't resolve, do your best to determine a URL for the project's source.
Shaded third-party dependencies
Some third party dependencies actually copy in other dependencies rather than depend on them as Maven artifacts. This means they don't show up in the process above. These can be quite hard to track down, but are rare. A key example is reflectasm, embedded in kryo.
Examples module
The above almost considers everything bundled in a Spark binary release. The main assembly won't include examples. The same must be done for dependencies marked as 'compile' for the examples module. See examples/target/site/dependencies.html. At the time of this writing however this just adds one dependency: scopt.
provided scope
Above we considered just compile and runtime scope dependencies, which makes sense as they are the ones that are packaged. However, for complicated reasons (shading), a few components that Spark does bundle are not marked as compile dependencies in the assembly. Therefore it's also necessary to consider 'provided' dependencies from assembly/target/site/dependencies.html actually! Right now that's just Jetty and JPMML artifacts.
Python, R
Don't forget that Py4J is also distributed in the binary release, actually. There should be no other R, Python code in the binary release. That's it.
Sense checking
Compare the contents of jars/, examples/jars/ and python/lib from a recent binary release to see if anything appears there that doesn't seem to have been covered above. These additional components will have to be handled manually, but should be few or none of this type.
Source Release License
While there are relatively fewer third-party source artifacts included as source code, there is no automated way to detect it, really. It requires some degree of manual auditing. Most third party source comes from included JS and CSS files.
At the time of this writing, some places to look or consider: build/sbt-launch-lib.bash, python/lib, third party source in python/pyspark like heapq3.py, docs/js/vendor, and core/src/main/resources/org/apache/spark/ui/static.
The principles are the same as above.
Remember some JS files copy in other JS files! Look out for Modernizr.
One More Thing: JS and CSS in Binary Release
Now that you've got a handle on source licenses, recall that all the JS and CSS source code will also be part of the binary release. Copy that info from source to binary license files accordingly.

Merged build finished. Test PASSed.

Test build #92313 has started for PR 21640 at commit 6aafdc5.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/466/
Test PASSed.

Test build #92313 has finished for PR 21640 at commit 6aafdc5.

This patch fails RAT tests.
This patch merges cleanly.
This patch adds the following public classes (experimental):
QuadraticMinimizer class in package breeze.optimize.proximal is distributed with Copyright (c)
NonlinearMinimizer class in package breeze.optimize.proximal is distributed with Copyright (c)

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92313/
Test FAILed.

Test build #92316 has started for PR 21640 at commit 1928112.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/472/
Test PASSed.

Test build #92316 has finished for PR 21640 at commit 1928112.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92316/
Test FAILed.

Test build #92321 has finished for PR 21640 at commit e07f387.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92321/
Test PASSed.

Test build #92499 has started for PR 21640 at commit 198b208.

Test build #92499 has finished for PR 21640 at commit 198b208.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/92499/
Test PASSed.


update aliases, depends on sopel-irc/sopel#1966

See also: #19.

sopel-irc/sopel#1966 is merged now. Still no planned release date (we haven't even started adding new stuff yet), but progress is being made. 😝


Docs: add rules context dynamically

In this PR we generate the rules context dynamically for the documentation using a Sphinx hook. Then it's embedded like this:

To merge after #484.

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 70.90%. Comparing base (f8620f3) to head (3ea3f9d).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #485      +/-   ##
==========================================
+ Coverage   70.86%   70.90%   +0.04%
==========================================
  Files          47       47
  Lines        2904     2908       +4
  Branches      630      630
==========================================
+ Hits         2058     2062       +4
  Misses        666      666
  Partials      180      180

Flag
Coverage Δ

unittests
70.39% <100.00%> (+0.04%)
:arrow_up:

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

Files
Coverage Δ

...loyment_toolbelt/jobs/job_profiles_synchronizer.py
50.79% <100.00%> (ø)

..._deployment_toolbelt/utils/computer_environment.py
100.00% <100.00%> (ø)


[GH-904] Add Spring 6-related exclusions to Shiro BOM

Fix #904

Should we add a test for SpringBoot?

Should we add a test for SpringBoot?

I'm trying to add a sample module but I need to go deeper to exclude spring5 vs spring6 and springboot2 vs springboot3.
May be it can be another PR?


Routing to a wrong endpoint with multiple virtualservices for the same host, when the virtualservices have header rules.

Describe the bug
I see a new feature：https://istio.io/help/ops/traffic-management/deploy-guidelines/#multiple-virtual-services-and-destination-rules-for-the-same-host
but when I match the header rules,the root path"/" will override the other rules.
Expected behavior
the virtualservices like these:
kind: VirtualService
metadata:
  name: trident-web
  namespace: iop
spec:
  gateways:
  - default.istio-system.svc.cluster.local
  hosts:
  - multi-example.iop.com
  http:
  - match:
    - headers:
        cookie:
          regex: ^(.*\s*)?(canary)(.*)?$
      uri:
        prefix: /
    route:
    - destination:
        host: trident-web.iop.svc.cluster.local
        subset: canary
    timeout: 60s
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: trident-web.iop.svc.cluster.local
        subset: stable
    timeout: 60s
--------------------------
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: cicd-api
  namespace: iop
spec:
  gateways:
  - default.istio-system.svc.cluster.local
  hosts:
  - multi-example.iop.com
  http:
  - match:
    - headers:
        cookie:
          regex: ^(.*\s*)?(canary)(.*)?$
      uri:
        prefix: /cicd
    route:
    - destination:
        host: cicd-api.iop.svc.cluster.local
        subset: canary
    timeout: 60s
  - match:
    - uri:
        prefix: /cicd
    route:
    - destination:
        host: cicd-api.iop.svc.cluster.local
        subset: stable
    timeout: 60s

and the svc:
apiVersion: v1
kind: Service
metadata:
  name: cicd-api
  namespace: iop
spec:
  ports:
  - name: http-cicd-apis
    port: 9090
    protocol: TCP
    targetPort: 9090
  selector:
    k8s-app: cicd-api
  type: ClusterIP
-----------------
apiVersion: v1
kind: Service
metadata:
  name: trident-web
  namespace: iop
spec:
  ports:
  - name: http-trident-web-pro
    port: 8080
    protocol: TCP
    targetPort: 80
  selector:
    appinstance: trident-web
    application: trident-web
    user: cks
  type: ClusterIP

Steps to reproduce the bug
When I call the  url "http://multi-example.iop.com/cicd/core/v1/jenkins-env" from chrom with cookie witch has "roles=cannary", it should routing to the cicd-api service,
but I get 404 because the request was routed to the trident-web service,I find this at ingressgateway logs:
[2018-12-14T07:43:51.933Z] "GET /cicd/core/v1/jenkins-envHTTP/2" 404 - 0 571 8 0 "<IP_ADDRESS>" "Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36" "a0c33090-489c-9b1f-a2ac-730cd68895e2" "multi-example.iop.com" "<IP_ADDRESS>:80" outbound|8080|canary|trident-web.iop.svc.cluster.local - <IP_ADDRESS>:443 <IP_ADDRESS>:55836

Version
istio version: v1.0.4
k8s version: v1.11.1+icp-ee
Installation
install istio with helm
Environment
ICP from IBM

@frankbu can you help check this out?

This is working as designed. In the documentation it says Although the order of evaluation for rules in any given source VirtualService will be retained, the cross-resource order is UNDEFINED. In other words, there is no guaranteed order of evaluation for rules across the fragment configurations, so it will only have predictable behavior if there are no conflicting rules or order dependency between rules across fragments..
The rules in this example do have order dependency. This rule:
  - match:
    - headers:
        cookie:
          regex: ^(.*\s*)?(canary)(.*)?$
      uri:
        prefix: /
    route:
    - destination:
        host: trident-web.iop.svc.cluster.local
        subset: canary

needs to be ordered after (i.e., lower priority) than these ones:
  http:
  - match:
    - headers:
        cookie:
          regex: ^(.*\s*)?(canary)(.*)?$
      uri:
        prefix: /cicd
    route:
    - destination:
        host: cicd-api.iop.svc.cluster.local
        subset: canary
    timeout: 60s
  - match:
    - uri:
        prefix: /cicd
    route:
    - destination:
        host: cicd-api.iop.svc.cluster.local
        subset: stable
    timeout: 60s

because any request to a uri starting with /cicd will also match rules for prefix: /.
To use this feature, there must be no overlapping conditions in the rules, or you will get UNDEFINED behavior, so even if you were lucky and it did work, there is no guarantee it will work in the future.
Btw, your second / rule:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: trident-web.iop.svc.cluster.local
        subset: stable
    timeout: 60s

should work fine, because it is a "catch-all" rule which will automatically get moved to the end of the list in the merged configuration.

Tks for u reply.
I thought the rules with uri prefix: / is "catch-all" rules whether it has overlapping conditions or not. and as the document says the All such “catch-all” rules will be moved to the end of the list in the merged configuration.
We have 50+ microservices, all the rules in one virtualservice will be over 1000+ lines. So this feature is very useful.
I think there is a solution that might solve the order problem.
First, sorted by the uri type: exact, prefix, regex
Secondly, sorted according to the length of the rule's  uri
The "catch-all" rules will be at the end of the list.
The order will be mutch better than no order.

Yes, the rule with ONLY prefix: / as match is a "catch-all", so it will go to the end. The problem is that one of your rules has two conditions in the match, prefix: / AND header: ..., so that one is NOT a catch-all. Catch-all means that it applies to ALL requests, which the header condition obviously prevents.
More intelligent merge ordering is a possible future enhancement that has been discussed, but the right way to order rules that include multiple match conditions, like your example above, is challenging. This is where user intent is hard to determine.

I find a pr "VirtualService simple merging of http routes at Gateway"#8113 which commit by @rshriram  can satisfy my needs very well.
The code from https://github.com/rshriram/istio/blob/06a85dea6bab82afb0053b7b2819a597b5d44211/pilot/pkg/networking/core/v1alpha3/route/route.go#L749
func CombineVHostRoutes(first []route.Route, second []route.Route) []route.Route {
	combined := append(first, second...)
	sort.SliceStable(combined, func(i, j int) bool {
		var iType, jType envoyRouteType
		var iVal, jVal string

		switch iR := combined[i].Match.PathSpecifier.(type) {
		case *route.RouteMatch_Path:
			iType = envoyPath
			iVal = iR.Path
		case *route.RouteMatch_Prefix:
			if iR.Prefix == "/" {
				iType = envoyCatchAll
			} else {
				iType = envoyPrefix
			}
			iVal = iR.Prefix
		case *route.RouteMatch_Regex:
			if iR.Regex == "*" {
				iType = envoyCatchAll
			} else {
				iType = envoyRegex
			}
			iVal = iR.Regex
		}

		switch jR := combined[j].Match.PathSpecifier.(type) {
		case *route.RouteMatch_Path:
			jType = envoyPath
			jVal = jR.Path
		case *route.RouteMatch_Prefix:
			if jR.Prefix == "/" {
				jType = envoyCatchAll
			} else {
				jType = envoyPrefix
			}
			jVal = jR.Prefix
		case *route.RouteMatch_Regex:
			if jR.Regex == "*" {
				jType = envoyCatchAll
			} else {
				jType = envoyRegex
			}
			jVal = jR.Regex
		}

		// path before prefix
		// prefix before regex
		// regex before catchall prefix / or catch all regex *
		// longest path before shorter path
		// longest prefix before shorter prefix
		// longest regex before shorter regex. it doesn't make any difference, but
		// we do it anyway to get a stable ordering
		if iType == jType {
			return len(iVal) < len(jVal)
		}

		return iType < jType
	})

	return combined
}

but, I am very confused , is it had been merged to master? @rshriram

That implementation had side effects that were not backward compatible, so the implementation was changed in #8114, before it was released.
It currently works exactly as documented, as I explained above.
https://github.com/istio/istio/blob/ab79844e47ff881a0aadcb1c9e361d7ab8ea62a4/pilot/pkg/networking/core/v1alpha3/route/route.go#L841


Submit the project in Moodle

Zip all the files into one submission folder named Gxx-Sprintx.zip). The submission should contain:
– Link to the pull request, the project information (SonarCloud link, …)
– Gxx-diary.xls
– Gxx-Quality-issue.xls

Priority: High

Hours spent: 1


Fix edge case where hotkeys would be empty after a crash, causing Chatterino to be unusable unless the user reset their hotkeys

Pull request checklist:

[ ] CHANGELOG.md was updated, if applicable I don't think this should get a changelog entry because custom hotkeys have not been into a stable yet. pajaDent

Description

This forces a save of settings after hotkeys have been saved into memory. I can't really reproduce the bug so this is the best fix I can do rn.

I don't think this should get a changelog entry because custom hotkeys have not been into a stable yet. pajaDent

I know I'm late, but just appending PR number to the already existing changelog entry would be something you can do. e.g. - Major: Added customizable shortcuts. (#2340, #3473). Keep that in mind if there's any future PR fixing hotkeys-related functionality - could sneak in number of this PR as well then.


Order Meta

We have created a custom order_meta value to tag specific orders and are trying to query only those specific orders without returning every order and then looping through them.  I can not determine the correct parameters to retrieve order_meta value.  I have tried adding url parameters:
&meta_key=meta_value.  We also set the filter[meta]=true.
With the new API V1, I see there is a filter option, although unsure how to set the query args?
filter - Use WP Query arguments to modify the response; private query vars require appropriate authorization.
How can I retrieve only the orders with a set order_meta value?  Thanks for your help.

Not an issue with this wrapper.
And you should read the WooCommerce REST API docs or user the proper support channel.

@gumwp had any luck with it yet? Looking for something similar.


Add French translations

Summary of changes
Add fr (French) translations.

Coverage remained the same at 66.901% when pulling 1140dd8a84e4a2cd4ab36c83564c1e82d37f1d0e on ejpcmac:translations/french into f4ac36f44f0d5fa2c8191fde3aa792548e9673a8 on bitwalker:master.

Thanks so much!

@bitwalker You’re welcome :)


Feature: Allow VPC Endpoints to be Created via vpc-endpoints Submodule

what

Add vpc-endpoints submodule to this repo, which allows users to provision Interface and/or Gateway VPC Endpoints to the VPC they have created with the terraform-aws-vpc module.
Add Terratest tests for testing the vpc-endpoints submodule
Update automated testing via Terratest in this repo to use us-east-2 region instead of us-west-1, as going forward CloudPosse repositories will be using us-east-2

why

Currently, there is no option within the VPC module to enable any VPC Endpoints. A simple switch for each type of endpoint is not possible, because there are dozens of possible endpoints —particularly Interface Endpoints— that can be created. Furthermore, VPC Endpoints may depend on resources that are themselves dependant on the terraform-aws-vpc module (i.e. subnet IDs), so an external module is required, but a standalone module is not necessarily justified.

references

It's useful to read the AWS Documentation to make a distinction between Interface VPC Endpoints and Gateway VPC Endpoints

/test all

/test all

/test all

/test all

/rebuild README

/rebuild-readme

/test all

/test all

/rebuild-readme

Added a do-not-merge label because the private_dns_enabled attribute needs to be added.

/test all

/test all


Fix CI

Signed-off-by: joshvanl<EMAIL_ADDRESS>
Set kubebuilder-tools dependency version to 1.21.2 by default

/test pull-cert-manager-trust-smoke

Error: looks like "https://charts.jetstack.io" is not a valid chart repository or cannot be reached: Get "https://charts.jetstack.io/index.yaml": dial tcp: lookup charts.jetstack.io on <IP_ADDRESS>:53: read udp <IP_ADDRESS>:42716-><IP_ADDRESS>:53: i/o timeout

:disappointed:

/retest

/retest

/retest


does this work with the rc2 blades and fans?

I have a RC2 blade (more then 1) and would like to install this for further monitoring of the fan speed over prometheus.
Does it work with the fan units we got with the RC2 blades (non smart unit)?

Bump

Hey @dstewen
Sorry missed the notifications.
Yes, I've been testing this on the RC2s as well with both smart & standard fan units.
The only caveat for the standard fan units is a slightly higher CPU utilisation when measuring the fan speed (linked to inefficiencies & polling in the gpio driver)

I'm running Debian 12 (bookworm) on my blades. I've taken a quick look at the installer and if I am understanding it correctly it just appears to install the package file (.deb).
You mentioned a gpio driver? Does any specific functionality need to be activated via config.txt in the kernel for the package to work?

It should work out of the box, you only need a change in the config.txt when using the smart fan unit.
Do you get an error log (it's setting up a systemd service)


[QA] Nametag spreads outside the chat bubble

Explorer Alpha build version:
0.3.250-main-08f208c
Issue Description:

When the nametag is long and it has attached the last digits of the user's wallet, the text spreads outside the chat bubble inside the chat window.
In order to see this happen, the text input that the user sends must be shorter than the nametag.
Evidence:

Additional Notes:

I tried to repro this with the exact same name but it doesn't happen for me 😱  @anicalbano

@davidejensen could it be related to the screen resolution? Just thinking out loud 🤔


Cryptiiiic Closed so many open issues and a pull request

I mean, seriously.
I worked on UI part with pwn in PR and you can’t just close it; also I looked into issues tab and so many of them got closed; wtf is going on Cryptiiiic?

chillout it was conflicting.

chillout it was conflicting.

Hey dude.
Pwn and I were aware of the conflicts and pwn was going to take care of it. Can you please bring it back?

We will not be changing the unc0ver UI. Sorry about that.


Mouse scroll stops working

Expected Behavior
You can scroll large request and response bodies.
Actual Behavior
If request or response has more than ~150 lines (guess dependent on resolution and font size) and you do fast mouse scroll, scroll stops and not respond until cursor is moved or after some time.
Reproduction Steps

Create new HTTP Request
Set type to JSON
Paste JSON text longer than 150 lines
Start scrolling down

Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
No response
Insomnia Version
2022.6.0
What operating system are you using?
Windows
Operating System Version
windows 10, windows 11 22H2
Installation method
download from insomnia.rest
Last Known Working Insomnia version
2021.3.0

The issue does not reproduce in version 2022.7.0-beta.4. I think that due to the update of electron.


Please re-consider policy on "duplicate content"

Hi @MightyPen @ShevaDas @yunyunyunyun @cillroy
I propose that Microsoft clean up its usage of doc includes and how inline inclusion of content can be used to improve document comprehension. Currently, files in  https://github.com/MicrosoftDocs/sql-docs/tree/live/docs/includes have a cryptic naming convention not explained to the open source community.
I propose three sweeping changes:

Rename cryptic file names into human readable file names that are instantly understood by everyone
Replace applies-to-*.md files with a single markdown extension that generates a badge

The current approach makes it hard to peer review content without remembering the conventions.

Consider ways to avoid hyperlinking IMPORTANT usage notes such that IMPORTANT notes common to several features are not buried in the "fescue" of a hyperlink.

Does Microsoft use any click-through analytics to see how often people actually click hyperlinks inside documentation?  While it might be offensive to career documentation experts like @MightyPen who are undoubtedly great at their job, ultimately I'm suggesting Microsoft should use some machine learning and/or at least A/B tests to predict the right way to structure the documentation.  If you want to open source the click-through data, I'd be interested in analyzing user behavior (from google/bing search through to entry and exit page).

For point 3, my previous pull request https://github.com/MicrosoftDocs/sql-docs/pull/1279 was closed. You mentioned there was an internal discussion about this, but I believe, in this day and age, the internal discussion should also happen with the community and the community should weigh in.

@jzabroski thank you for the feedback.  It would be good to revisit how we manage includes but I do not think now is the time for a variety of reasons.
When we implemented the includes, they were not fully supported in our publishing system so the vision for how to use them was very different then now.  Also, the applies to type includes where intended to be short lived as a work around for a lack of any other way to indicate support.  Well, many things have changed including the versioning feature in our publishing system has not happened and our landscape got more complex, with the introduction of more "flavors" of SQL such as Linux and managed instance.
We would benefit from a reorganization of the includes folder with a few sub folders such as having all of the applies to includes in one folder, product names/versions in another.  We likely should also put together guidelines for the community before we encourage includes.
Again, I appreciate your feedback.

no the publishing system is not Open Source.


Adding Chef Provisioning to the maintainers file.

We're opening Chef Provisioning and its drivers up to open source maintenance, in line with other components of Chef.
I've left the Lieutenant and Maintainers as TBD because we need to go through the election process.
I'm going to have this discussed at the next developer's meeting.  I will also start advertising this potential change so any interested maintainers can come to the developer's meeting.

Added to the next community developer's meeting for discussion: https://github.com/chef/chef-community-irc-meetings/pull/34

I've updated the TOML with myself and @jkeiser but am having issues updating the markdown...
[chef]$ bundle exec rake maintainers:synchronize
[DEPRECATION] `last_comment` is deprecated.  Please use `last_description` instead.
[DEPRECATION] `last_comment` is deprecated.  Please use `last_description` instead.
Error loading credentials from netrc file for https://api.github.com/
rake aborted!
Octokit::Unauthorized: GET https://api.github.com/orgs/chef/teams?per_page=100: 401 - Requires authentication // See: https://developer.github.com/v3
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/octokit-4.3.0/lib/octokit/response/raise_error.rb:16:in `on_complete'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/faraday-0.9.2/lib/faraday/response.rb:9:in `block in call'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/faraday-0.9.2/lib/faraday/response.rb:57:in `on_complete'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/faraday-0.9.2/lib/faraday/response.rb:8:in `call'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/octokit-4.3.0/lib/octokit/middleware/follow_redirects.rb:73:in `perform_with_redirection'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/octokit-4.3.0/lib/octokit/middleware/follow_redirects.rb:61:in `call'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/faraday-0.9.2/lib/faraday/rack_builder.rb:139:in `build_response'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/faraday-0.9.2/lib/faraday/connection.rb:377:in `run_request'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/faraday-0.9.2/lib/faraday/connection.rb:140:in `get'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/sawyer-0.7.0/lib/sawyer/agent.rb:94:in `call'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/octokit-4.3.0/lib/octokit/connection.rb:154:in `request'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/octokit-4.3.0/lib/octokit/connection.rb:84:in `paginate'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/gems/octokit-4.3.0/lib/octokit/client/organizations.rb:222:in `organization_teams'
/Users/tball/github/chef/tasks/maintainers.rb:96:in `get_github_teams'
/Users/tball/github/chef/tasks/maintainers.rb:58:in `block (2 levels) in <top (required)>'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/bin/ruby_executable_hooks:15:in `eval'
/Users/tball/.rvm/gems/ruby-2.1.6@chef/bin/ruby_executable_hooks:15:in `<main>'
Tasks: TOP => maintainers:synchronize
(See full trace by running task with --trace)

@tyler-ball you don't want maintainers:synchronise, you want maintainers:generate

:doh: Right you are @thom - updated

pinging @sethvargo @jonlives @ranjib @btm @lamont-granquist @jtimberman @martinisoft @joemiller @edolnx for votes, please

:+1:

:+1:

:+1:

This is a good pair of initial people, we'll look to add more :+1:

:+1:

:+1:


Added GEOSClipByRect / shapely.ops.clip_by_rect

TODO - write docstring.
@drnextgis - is there a good reference for this?

This function from GEOS 3.5.0. Clips a geometry by a 2D box in a fast but possibly dirty way.

Closes #370.

Coverage decreased (-0.2%) to 80.012% when pulling 22db3185290404590105a87def5aa1067c48cda5 on snorfalorpagus:clip_by_rect into bed28170140429d58e4079c57cc2480c5e5ff6ab on Toblerity:master.

@snorfalorpagus thanks! I've found this description here: https://postgis.net/docs/ST_ClipByBox2D.html

Docstring added. Ready for merge.


raftstore: skip handle remaining messages if peer is destroyed

What is changed and how it works?

Issue Number: Close #17840

What's Changed:
Skip handling remain raft messages after peer fsm is stopped. This can avoid potential panic if the raft message need to read raft log from raft engine.

Related changes

[ ] PR to update pingcap/docs/pingcap/docs-cn:
[ ] Need to cherry-pick to the release branch

Check List
Tests

[x] Unit test
[ ] Integration test
[ ] Manual test (add detailed scripts or steps below)
[ ] No code

Side effects

[ ] Performance regression: Consumes more CPU
[ ] Performance regression: Consumes more Memory
[ ] Breaking backward compatibility

Release note

None

@Connor1996 @overvenus PTAL