Update README.md

missing character (Traefik)

@hartigoon It does not matter, the original command line argument is also correct.
$ k3s server --no-deploy traefik
INFO[0000] Preparing data dir /var/lib/rancher/k3s/data/39ef0f16e348d54b8c2f02b2be768d6c64f6e5f7e13ac130aff860138ca8e9d3
INFO[2019-07-17T04:19:35.016879384Z] Starting k3s v0.6.0 (09b06343)
INFO[2019-07-17T04:19:36.125569602Z] Running kube-apiserver --advertise-address=<IP_ADDRESS> --tls-private-key-file=/var/lib/rancher/k3s/server/tls/localhost.key --basic-auth-file=/var/lib/rancher/k3s/server/cred/passwd --kubelet-client-key=/var/lib/rancher/k3s/server/tls/token-node.key --requestheader-allowed-names=kubernetes-proxy --proxy-client-key-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.key --allow-privileged=true --authorization-mode=Node,RBAC --service-cluster-ip-range=<IP_ADDRESS>/16 --advertise-port=6445 --bind-address=<IP_ADDRESS> --service-account-key-file=/var/lib/rancher/k3s/server/tls/service.key --requestheader-username-headers=X-Remote-User --watch-cache=false --tls-cert-file=/var/lib/rancher/k3s/server/tls/localhost.crt --api-audiences=unknown --kubelet-client-certificate=/var/lib/rancher/k3s/server/tls/token-node-1.crt --proxy-client-cert-file=/var/lib/rancher/k3s/server/tls/client-auth-proxy.crt --cert-dir=/var/lib/rancher/k3s/server/tls/temporary-certs --service-account-signing-key-file=/var/lib/rancher/k3s/server/tls/service.key --insecure-port=0 --secure-port=6444 --service-account-issuer=k3s --requestheader-client-ca-file=/var/lib/rancher/k3s/server/tls/request-header-ca.crt --requestheader-extra-headers-prefix=X-Remote-Extra- --requestheader-group-headers=X-Remote-Group
E0717 04:19:36.544068    6276 prometheus.go:138] failed to register depth metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.544268    6276 prometheus.go:150] failed to register adds metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.544314    6276 prometheus.go:162] failed to register latency metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.544345    6276 prometheus.go:174] failed to register work_duration metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.544369    6276 prometheus.go:189] failed to register unfinished_work_seconds metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.544389    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric admission_quota_controller: duplicate metrics collector registration attempted
W0717 04:19:36.643173    6276 genericapiserver.go:315] Skipping API batch/v2alpha1 because it has no resources.
W0717 04:19:36.649656    6276 genericapiserver.go:315] Skipping API node.k8s.io/v1alpha1 because it has no resources.
E0717 04:19:36.671565    6276 prometheus.go:138] failed to register depth metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.671612    6276 prometheus.go:150] failed to register adds metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.671647    6276 prometheus.go:162] failed to register latency metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.671682    6276 prometheus.go:174] failed to register work_duration metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.671706    6276 prometheus.go:189] failed to register unfinished_work_seconds metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.671733    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric admission_quota_controller: duplicate metrics collector registration attempted
E0717 04:19:36.676199    6276 controller.go:148] Unable to remove old endpoints from kubernetes service: StorageError: key not found, Code: 1, Key: /registry/masterleases/<IP_ADDRESS>, ResourceVersion: 0, AdditionalErrorMsg:
INFO[2019-07-17T04:19:36.677098264Z] Running kube-scheduler --port=10251 --bind-address=<IP_ADDRESS> --secure-port=0 --kubeconfig=/var/lib/rancher/k3s/server/cred/kubeconfig-system.yaml --leader-elect=false
INFO[2019-07-17T04:19:36.681692051Z] Running kube-controller-manager --bind-address=<IP_ADDRESS> --secure-port=0 --service-account-private-key-file=/var/lib/rancher/k3s/server/tls/service.key --cluster-cidr=<IP_ADDRESS>/16 --allocate-node-cidrs=true --port=10252 --kubeconfig=/var/lib/rancher/k3s/server/cred/kubeconfig-system.yaml --root-ca-file=/var/lib/rancher/k3s/server/tls/token-ca.crt --leader-elect=false
W0717 04:19:36.684075    6276 authorization.go:47] Authorization is disabled
W0717 04:19:36.684088    6276 authentication.go:55] Authentication is disabled
INFO[2019-07-17T04:19:36.762930608Z] Creating CRD listenerconfigs.k3s.cattle.io
INFO[2019-07-17T04:19:36.806354481Z] Creating CRD addons.k3s.cattle.io
INFO[2019-07-17T04:19:36.816047080Z] Creating CRD helmcharts.helm.cattle.io
INFO[2019-07-17T04:19:36.821566160Z] Waiting for CRD helmcharts.helm.cattle.io to become available
INFO[2019-07-17T04:19:37.323080630Z] Done waiting for CRD helmcharts.helm.cattle.io to become available
INFO[2019-07-17T04:19:37.323199411Z] Waiting for CRD listenerconfigs.k3s.cattle.io to become available
INFO[2019-07-17T04:19:37.824212991Z] Done waiting for CRD listenerconfigs.k3s.cattle.io to become available
INFO[2019-07-17T04:19:37.824232927Z] Waiting for CRD addons.k3s.cattle.io to become available
INFO[2019-07-17T04:19:38.325748811Z] Done waiting for CRD addons.k3s.cattle.io to become available
INFO[2019-07-17T04:19:38.326935561Z] Writing static file: /var/lib/rancher/k3s/server/static/charts/traefik-1.64.0.tgz
INFO[2019-07-17T04:19:38.327292665Z] Writing manifest: /var/lib/rancher/k3s/server/manifests/coredns.yaml
E0717 04:19:38.327547    6276 prometheus.go:138] failed to register depth metric k3s.cattle.io/v1, Kind=Addon: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=Addon_depth", help: "(Deprecated) Current depth of workqueue: k3s.cattle.io/v1, Kind=Addon", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=Addon_depth" is not a valid metric name
E0717 04:19:38.327651    6276 prometheus.go:150] failed to register adds metric k3s.cattle.io/v1, Kind=Addon: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=Addon_adds", help: "(Deprecated) Total number of adds handled by workqueue: k3s.cattle.io/v1, Kind=Addon", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=Addon_adds" is not a valid metric name
E0717 04:19:38.327803    6276 prometheus.go:162] failed to register latency metric k3s.cattle.io/v1, Kind=Addon: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=Addon_queue_latency", help: "(Deprecated) How long an item stays in workqueuek3s.cattle.io/v1, Kind=Addon before being requested.", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=Addon_queue_latency" is not a valid metric name
E0717 04:19:38.327924    6276 prometheus.go:174] failed to register work_duration metric k3s.cattle.io/v1, Kind=Addon: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=Addon_work_duration", help: "(Deprecated) How long processing an item from workqueuek3s.cattle.io/v1, Kind=Addon takes.", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=Addon_work_duration" is not a valid metric name
E0717 04:19:38.328031    6276 prometheus.go:189] failed to register unfinished_work_seconds metric k3s.cattle.io/v1, Kind=Addon: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=Addon_unfinished_work_seconds", help: "(Deprecated) How many seconds of work k3s.cattle.io/v1, Kind=Addon has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=Addon_unfinished_work_seconds" is not a valid metric name
E0717 04:19:38.328153    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric k3s.cattle.io/v1, Kind=Addon: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=Addon_longest_running_processor_microseconds", help: "(Deprecated) How many microseconds has the longest running processor for k3s.cattle.io/v1, Kind=Addon been running.", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=Addon_longest_running_processor_microseconds" is not a valid metric name
E0717 04:19:38.328307    6276 prometheus.go:214] failed to register retries metric k3s.cattle.io/v1, Kind=Addon: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=Addon_retries", help: "(Deprecated) Total number of retries handled by workqueue: k3s.cattle.io/v1, Kind=Addon", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=Addon_retries" is not a valid metric name
INFO[2019-07-17T04:19:38.328395306Z] Setting up event handlers
INFO[2019-07-17T04:19:38.330316452Z] Listening on :6443
E0717 04:19:38.780743    6276 prometheus.go:138] failed to register depth metric k3s.cattle.io/v1, Kind=ListenerConfig: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=ListenerConfig_depth", help: "(Deprecated) Current depth of workqueue: k3s.cattle.io/v1, Kind=ListenerConfig", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=ListenerConfig_depth" is not a valid metric name
E0717 04:19:38.780784    6276 prometheus.go:150] failed to register adds metric k3s.cattle.io/v1, Kind=ListenerConfig: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=ListenerConfig_adds", help: "(Deprecated) Total number of adds handled by workqueue: k3s.cattle.io/v1, Kind=ListenerConfig", constLabels: {},variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=ListenerConfig_adds" is not a valid metric name
E0717 04:19:38.780829    6276 prometheus.go:162] failed to register latency metric k3s.cattle.io/v1, Kind=ListenerConfig: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=ListenerConfig_queue_latency", help: "(Deprecated) How long an item stays in workqueuek3s.cattle.io/v1, Kind=ListenerConfig before being requested.", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=ListenerConfig_queue_latency" is not a valid metric name
E0717 04:19:38.780866    6276 prometheus.go:174] failed to register work_duration metric k3s.cattle.io/v1, Kind=ListenerConfig: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=ListenerConfig_work_duration", help: "(Deprecated) How long processing an item from workqueuek3s.cattle.io/v1, Kind=ListenerConfig takes.", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=ListenerConfig_work_duration" is not a valid metric name
E0717 04:19:38.780888    6276 prometheus.go:189] failed to register unfinished_work_seconds metric k3s.cattle.io/v1, Kind=ListenerConfig: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=ListenerConfig_unfinished_work_seconds", help: "(Deprecated) How many seconds of work k3s.cattle.io/v1, Kind=ListenerConfig has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=ListenerConfig_unfinished_work_seconds" is not a valid metric name
E0717 04:19:38.780908    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric k3s.cattle.io/v1, Kind=ListenerConfig: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=ListenerConfig_longest_running_processor_microseconds", help: "(Deprecated) How many microseconds has the longest running processor for k3s.cattle.io/v1, Kind=ListenerConfig been running.", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=ListenerConfig_longest_running_processor_microseconds" is not a valid metric name
E0717 04:19:38.780940    6276 prometheus.go:214] failed to register retries metric k3s.cattle.io/v1, Kind=ListenerConfig: descriptor Desc{fqName: "k3s.cattle.io/v1, Kind=ListenerConfig_retries", help: "(Deprecated) Total number of retries handled by workqueue: k3s.cattle.io/v1, Kind=ListenerConfig", constLabels: {}, variableLabels: []} is invalid: "k3s.cattle.io/v1, Kind=ListenerConfig_retries" is not a valid metric name
INFO[2019-07-17T04:19:38.780952849Z] Setting up event handlers
INFO[2019-07-17T04:19:39.282068147Z] Starting k3s.cattle.io/v1, Kind=Addon controller
INFO[2019-07-17T04:19:39.382279172Z] Starting k3s.cattle.io/v1, Kind=ListenerConfig controller
INFO[2019-07-17T04:19:39.382589369Z] Node token is available at /var/lib/rancher/k3s/server/node-token
INFO[2019-07-17T04:19:39.382606350Z] To join node to cluster: k3s agent -s https://<IP_ADDRESS>:6443 -t${NODE_TOKEN}
E0717 04:19:39.385586    6276 prometheus.go:138] failed to register depth metric /v1, Kind=Node: descriptor Desc{fqName: "/v1, Kind=Node_depth", help: "(Deprecated) Current depth of workqueue: /v1, Kind=Node", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Node_depth" is not a valid metric name
E0717 04:19:39.385699    6276 prometheus.go:150] failed to register adds metric /v1, Kind=Node: descriptor Desc{fqName: "/v1, Kind=Node_adds", help: "(Deprecated) Total number of adds handled by workqueue:/v1, Kind=Node", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Node_adds" is not a validmetric name
E0717 04:19:39.385792    6276 prometheus.go:162] failed to register latency metric /v1, Kind=Node: descriptor Desc{fqName: "/v1, Kind=Node_queue_latency", help: "(Deprecated) How long an item stays in workqueue/v1, Kind=Node before being requested.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Node_queue_latency" is not a valid metric name
E0717 04:19:39.385907    6276 prometheus.go:174] failed to register work_duration metric /v1, Kind=Node: descriptor Desc{fqName: "/v1, Kind=Node_work_duration", help: "(Deprecated) How long processing an item from workqueue/v1, Kind=Node takes.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Node_work_duration" is not a valid metric name
E0717 04:19:39.385988    6276 prometheus.go:189] failed to register unfinished_work_seconds metric /v1, Kind=Node: descriptor Desc{fqName: "/v1, Kind=Node_unfinished_work_seconds", help: "(Deprecated) How many seconds of work /v1, Kind=Node has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Node_unfinished_work_seconds" is not a valid metric name
E0717 04:19:39.386087    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric /v1, Kind=Node: descriptor Desc{fqName: "/v1, Kind=Node_longest_running_processor_microseconds", help: "(Deprecated) How many microseconds has the longest running processor for /v1, Kind=Node been running.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Node_longest_running_processor_microseconds" is not a valid metric name
E0717 04:19:39.386175    6276 prometheus.go:214] failed to register retries metric /v1, Kind=Node: descriptor Desc{fqName: "/v1, Kind=Node_retries", help: "(Deprecated) Total number of retries handled by workqueue: /v1, Kind=Node", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Node_retries" isnot a valid metric name
INFO[2019-07-17T04:19:39.386247471Z] Setting up event handlers
E0717 04:19:39.386402    6276 prometheus.go:138] failed to register depth metric batch/v1, Kind=Job: descriptor Desc{fqName: "batch/v1, Kind=Job_depth", help: "(Deprecated) Current depth of workqueue: batch/v1, Kind=Job", constLabels: {}, variableLabels: []} is invalid: "batch/v1, Kind=Job_depth" is not a valid metric name
E0717 04:19:39.386481    6276 prometheus.go:150] failed to register adds metric batch/v1, Kind=Job: descriptor Desc{fqName: "batch/v1, Kind=Job_adds", help: "(Deprecated) Total number of adds handled by workqueue: batch/v1, Kind=Job", constLabels: {}, variableLabels: []} is invalid: "batch/v1, Kind=Job_adds" is not a valid metric name
E0717 04:19:39.386572    6276 prometheus.go:162] failed to register latency metric batch/v1, Kind=Job:descriptor Desc{fqName: "batch/v1, Kind=Job_queue_latency", help: "(Deprecated) How long an item staysin workqueuebatch/v1, Kind=Job before being requested.", constLabels: {}, variableLabels: []} is invalid: "batch/v1, Kind=Job_queue_latency" is not a valid metric name
E0717 04:19:39.386663    6276 prometheus.go:174] failed to register work_duration metric batch/v1, Kind=Job: descriptor Desc{fqName: "batch/v1, Kind=Job_work_duration", help: "(Deprecated) How long processing an item from workqueuebatch/v1, Kind=Job takes.", constLabels: {}, variableLabels: []} is invalid: "batch/v1, Kind=Job_work_duration" is not a valid metric name
E0717 04:19:39.386751    6276 prometheus.go:189] failed to register unfinished_work_seconds metric batch/v1, Kind=Job: descriptor Desc{fqName: "batch/v1, Kind=Job_unfinished_work_seconds", help: "(Deprecated) How many seconds of work batch/v1, Kind=Job has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.", constLabels: {}, variableLabels: []} is invalid: "batch/v1, Kind=Job_unfinished_work_seconds" is not a valid metric name
E0717 04:19:39.386832    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric batch/v1, Kind=Job: descriptor Desc{fqName: "batch/v1, Kind=Job_longest_running_processor_microseconds", help: "(Deprecated) How many microseconds has the longest running processor for batch/v1,Kind=Job been running.", constLabels: {}, variableLabels: []} is invalid: "batch/v1, Kind=Job_longest_running_processor_microseconds" is not a valid metric name
E0717 04:19:39.386923    6276 prometheus.go:214] failed to register retries metric batch/v1, Kind=Job:descriptor Desc{fqName: "batch/v1, Kind=Job_retries", help: "(Deprecated) Total number of retries handled by workqueue: batch/v1, Kind=Job", constLabels: {}, variableLabels: []} is invalid: "batch/v1, Kind=Job_retries" is not a valid metric name
INFO[2019-07-17T04:19:39.386986342Z] Setting up event handlers
E0717 04:19:39.387091    6276 prometheus.go:138] failed to register depth metric helm.cattle.io/v1, Kind=HelmChart: descriptor Desc{fqName: "helm.cattle.io/v1, Kind=HelmChart_depth", help: "(Deprecated) Current depth of workqueue: helm.cattle.io/v1, Kind=HelmChart", constLabels: {}, variableLabels: []} is invalid: "helm.cattle.io/v1, Kind=HelmChart_depth" is not a valid metric name
E0717 04:19:39.387166    6276 prometheus.go:150] failed to register adds metric helm.cattle.io/v1, Kind=HelmChart: descriptor Desc{fqName: "helm.cattle.io/v1, Kind=HelmChart_adds", help: "(Deprecated) Total number of adds handled by workqueue: helm.cattle.io/v1, Kind=HelmChart", constLabels: {}, variableLabels: []} is invalid: "helm.cattle.io/v1, Kind=HelmChart_adds" is not a valid metric name
E0717 04:19:39.387250    6276 prometheus.go:162] failed to register latency metric helm.cattle.io/v1, Kind=HelmChart: descriptor Desc{fqName: "helm.cattle.io/v1, Kind=HelmChart_queue_latency", help: "(Deprecated) How long an item stays in workqueuehelm.cattle.io/v1, Kind=HelmChart before being requested.", constLabels: {}, variableLabels: []} is invalid: "helm.cattle.io/v1, Kind=HelmChart_queue_latency" is not a valid metric name
E0717 04:19:39.387337    6276 prometheus.go:174] failed to register work_duration metric helm.cattle.io/v1, Kind=HelmChart: descriptor Desc{fqName: "helm.cattle.io/v1, Kind=HelmChart_work_duration", help: "(Deprecated) How long processing an item from workqueuehelm.cattle.io/v1, Kind=HelmChart takes.", constLabels: {}, variableLabels: []} is invalid: "helm.cattle.io/v1, Kind=HelmChart_work_duration" is not avalid metric name
E0717 04:19:39.387416    6276 prometheus.go:189] failed to register unfinished_work_seconds metric helm.cattle.io/v1, Kind=HelmChart: descriptor Desc{fqName: "helm.cattle.io/v1, Kind=HelmChart_unfinished_work_seconds", help: "(Deprecated) How many seconds of work helm.cattle.io/v1, Kind=HelmChart has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.", constLabels: {}, variableLabels: []} is invalid: "helm.cattle.io/v1, Kind=HelmChart_unfinished_work_seconds" is not a valid metric name
E0717 04:19:39.387524    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric helm.cattle.io/v1, Kind=HelmChart: descriptor Desc{fqName: "helm.cattle.io/v1, Kind=HelmChart_longest_running_processor_microseconds", help: "(Deprecated) How many microseconds has the longest running processor for helm.cattle.io/v1, Kind=HelmChart been running.", constLabels: {}, variableLabels:[]} is invalid: "helm.cattle.io/v1, Kind=HelmChart_longest_running_processor_microseconds" is not a valid metric name
E0717 04:19:39.387616    6276 prometheus.go:214] failed to register retries metric helm.cattle.io/v1, Kind=HelmChart: descriptor Desc{fqName: "helm.cattle.io/v1, Kind=HelmChart_retries", help: "(Deprecated) Total number of retries handled by workqueue: helm.cattle.io/v1, Kind=HelmChart", constLabels: {}, variableLabels: []} is invalid: "helm.cattle.io/v1, Kind=HelmChart_retries" is not a valid metric name
INFO[2019-07-17T04:19:39.387681310Z] Setting up event handlers
E0717 04:19:39.387850    6276 prometheus.go:138] failed to register depth metric /v1, Kind=Service: descriptor Desc{fqName: "/v1, Kind=Service_depth", help: "(Deprecated) Current depth of workqueue: /v1, Kind=Service", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Service_depth" is not a validmetric name
E0717 04:19:39.387928    6276 prometheus.go:150] failed to register adds metric /v1, Kind=Service: descriptor Desc{fqName: "/v1, Kind=Service_adds", help: "(Deprecated) Total number of adds handled by workqueue: /v1, Kind=Service", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Service_adds" isnot a valid metric name
E0717 04:19:39.388013    6276 prometheus.go:162] failed to register latency metric /v1, Kind=Service: descriptor Desc{fqName: "/v1, Kind=Service_queue_latency", help: "(Deprecated) How long an item stays in workqueue/v1, Kind=Service before being requested.", constLabels: {}, variableLabels: []} is invalid:"/v1, Kind=Service_queue_latency" is not a valid metric name
E0717 04:19:39.388098    6276 prometheus.go:174] failed to register work_duration metric /v1, Kind=Service: descriptor Desc{fqName: "/v1, Kind=Service_work_duration", help: "(Deprecated) How long processing an item from workqueue/v1, Kind=Service takes.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Service_work_duration" is not a valid metric name
E0717 04:19:39.388180    6276 prometheus.go:189] failed to register unfinished_work_seconds metric /v1, Kind=Service: descriptor Desc{fqName: "/v1, Kind=Service_unfinished_work_seconds", help: "(Deprecated) How many seconds of work /v1, Kind=Service has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Service_unfinished_work_seconds" is not a valid metric name
E0717 04:19:39.388256    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric /v1, Kind=Service: descriptor Desc{fqName: "/v1, Kind=Service_longest_running_processor_microseconds", help: "(Deprecated) How many microseconds has the longest running processor for /v1, Kind=Service been running.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Service_longest_running_processor_microseconds" is not a valid metric name
E0717 04:19:39.388343    6276 prometheus.go:214] failed to register retries metric /v1, Kind=Service: descriptor Desc{fqName: "/v1, Kind=Service_retries", help: "(Deprecated) Total number of retries handled by workqueue: /v1, Kind=Service", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Service_retries" is not a valid metric name
INFO[2019-07-17T04:19:39.388435539Z] Setting up event handlers
E0717 04:19:39.388549    6276 prometheus.go:138] failed to register depth metric /v1, Kind=Pod: descriptor Desc{fqName: "/v1, Kind=Pod_depth", help: "(Deprecated) Current depth of workqueue: /v1, Kind=Pod", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Pod_depth" is not a valid metric name
E0717 04:19:39.388623    6276 prometheus.go:150] failed to register adds metric /v1, Kind=Pod: descriptor Desc{fqName: "/v1, Kind=Pod_adds", help: "(Deprecated) Total number of adds handled by workqueue: /v1, Kind=Pod", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Pod_adds" is not a valid metric name
E0717 04:19:39.388707    6276 prometheus.go:162] failed to register latency metric /v1, Kind=Pod: descriptor Desc{fqName: "/v1, Kind=Pod_queue_latency", help: "(Deprecated) How long an item stays in workqueue/v1, Kind=Pod before being requested.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Pod_queue_latency" is not a valid metric name
E0717 04:19:39.388813    6276 prometheus.go:174] failed to register work_duration metric /v1, Kind=Pod: descriptor Desc{fqName: "/v1, Kind=Pod_work_duration", help: "(Deprecated) How long processing an item from workqueue/v1, Kind=Pod takes.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Pod_work_duration" is not a valid metric name
E0717 04:19:39.388890    6276 prometheus.go:189] failed to register unfinished_work_seconds metric /v1, Kind=Pod: descriptor Desc{fqName: "/v1, Kind=Pod_unfinished_work_seconds", help: "(Deprecated) How many seconds of work /v1, Kind=Pod has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rateat which this increases.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Pod_unfinished_work_seconds" is not a valid metric name
E0717 04:19:39.388964    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric /v1, Kind=Pod: descriptor Desc{fqName: "/v1, Kind=Pod_longest_running_processor_microseconds", help: "(Deprecated) How many microseconds has the longest running processor for /v1, Kind=Pod been running.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Pod_longest_running_processor_microseconds" is not a valid metric name
E0717 04:19:39.389054    6276 prometheus.go:214] failed to register retries metric /v1, Kind=Pod: descriptor Desc{fqName: "/v1, Kind=Pod_retries", help: "(Deprecated) Total number of retries handled by workqueue: /v1, Kind=Pod", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Pod_retries" is nota valid metric name
INFO[2019-07-17T04:19:39.389118519Z] Setting up event handlers
E0717 04:19:39.389223    6276 prometheus.go:138] failed to register depth metric /v1, Kind=Endpoints: descriptor Desc{fqName: "/v1, Kind=Endpoints_depth", help: "(Deprecated) Current depth of workqueue: /v1, Kind=Endpoints", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Endpoints_depth" is nota valid metric name
E0717 04:19:39.389298    6276 prometheus.go:150] failed to register adds metric /v1, Kind=Endpoints: descriptor Desc{fqName: "/v1, Kind=Endpoints_adds", help: "(Deprecated) Total number of adds handled by workqueue: /v1, Kind=Endpoints", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Endpoints_adds" is not a valid metric name
E0717 04:19:39.389392    6276 prometheus.go:162] failed to register latency metric /v1, Kind=Endpoints: descriptor Desc{fqName: "/v1, Kind=Endpoints_queue_latency", help: "(Deprecated) How long an item stays in workqueue/v1, Kind=Endpoints before being requested.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Endpoints_queue_latency" is not a valid metric name
E0717 04:19:39.389478    6276 prometheus.go:174] failed to register work_duration metric /v1, Kind=Endpoints: descriptor Desc{fqName: "/v1, Kind=Endpoints_work_duration", help: "(Deprecated) How long processing an item from workqueue/v1, Kind=Endpoints takes.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Endpoints_work_duration" is not a valid metric name
E0717 04:19:39.389558    6276 prometheus.go:189] failed to register unfinished_work_seconds metric /v1, Kind=Endpoints: descriptor Desc{fqName: "/v1, Kind=Endpoints_unfinished_work_seconds", help: "(Deprecated) How many seconds of work /v1, Kind=Endpoints has done that is in progress and hasn't been observed by work_duration. Large values indicate stuck threads. One can deduce the number of stuck threads by observing the rate at which this increases.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Endpoints_unfinished_work_seconds" is not a valid metric name
E0717 04:19:39.389636    6276 prometheus.go:202] failed to register longest_running_processor_microseconds metric /v1, Kind=Endpoints: descriptor Desc{fqName: "/v1, Kind=Endpoints_longest_running_processor_microseconds", help: "(Deprecated) How many microseconds has the longest running processor for /v1, Kind=Endpoints been running.", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Endpoints_longest_running_processor_microseconds" is not a valid metric name
E0717 04:19:39.389724    6276 prometheus.go:214] failed to register retries metric /v1, Kind=Endpoints: descriptor Desc{fqName: "/v1, Kind=Endpoints_retries", help: "(Deprecated) Total number of retries handled by workqueue: /v1, Kind=Endpoints", constLabels: {}, variableLabels: []} is invalid: "/v1, Kind=Endpoints_retries" is not a valid metric name
INFO[2019-07-17T04:19:39.389792703Z] Setting up event handlers
INFO[2019-07-17T04:19:39.450072036Z] Wrote kubeconfig /etc/rancher/k3s/k3s.yaml
INFO[2019-07-17T04:19:39.450093885Z] Run: k3s kubectl
INFO[2019-07-17T04:19:39.450102243Z] k3s is up and running
INFO[2019-07-17T04:19:39.490433523Z] Logging containerd to /var/lib/rancher/k3s/agent/containerd/containerd.log
INFO[2019-07-17T04:19:39.490706319Z] Waiting for containerd startup: rpc error: code = Unavailable desc = all SubConns are in TransientFailure, latest connection error: connection error: desc = "transport:Error while dialing dial unix /run/k3s/containerd/containerd.sock: connect: no such file or directory"
INFO[2019-07-17T04:19:39.490764737Z] Running containerd -c /var/lib/rancher/k3s/agent/etc/containerd/config.toml -a /run/k3s/containerd/containerd.sock --state /run/k3s/containerd --root /var/lib/rancher/k3s/agent/containerd
W0717 04:19:40.113122    6276 lease.go:222] Resetting endpoints for master service "kubernetes" to [<IP_ADDRESS>]
INFO[2019-07-17T04:19:40.394552688Z] Starting helm.cattle.io/v1, Kind=HelmChart controller
INFO[2019-07-17T04:19:40.503066025Z] module overlay was already loaded
INFO[2019-07-17T04:19:40.510440895Z] Connecting to wss://localhost:6443/v1-k3s/connect
INFO[2019-07-17T04:19:40.510566945Z] Connecting to proxy                           url="wss://localhost:6443/v1-k3s/connect"
INFO[2019-07-17T04:19:40.529329404Z] Handling backend connection request [minikube]
INFO[2019-07-17T04:19:40.530774904Z] Running kubelet --container-runtime-endpoint=unix:///run/k3s/containerd/containerd.sock --read-only-port=0 --fail-swap-on=false --cni-bin-dir=/var/lib/rancher/k3s/data/39ef0f16e348d54b8c2f02b2be768d6c64f6e5f7e13ac130aff860138ca8e9d3/bin --client-ca-file=/var/lib/rancher/k3s/agent/client-ca.pem --eviction-hard=imagefs.available<5%,nodefs.available<5% --cert-dir=/var/lib/rancher/k3s/agent/kubelet/pki --container-runtime=remote --seccomp-profile-root=/var/lib/rancher/k3s/agent/kubelet/seccomp --address=<IP_ADDRESS> --tls-cert-file=/var/lib/rancher/k3s/agent/token-node.crt --tls-private-key-file=/var/lib/rancher/k3s/agent/token-node.key --authentication-token-webhook=true --root-dir=/var/lib/rancher/k3s/agent/kubelet --resolv-conf=/run/systemd/resolve/resolv.conf --node-labels=node-role.kubernetes.io/master=true --cni-conf-dir=/var/lib/rancher/k3s/agent/etc/cni/net.d --cluster-dns=<IP_ADDRESS> --cgroup-driver=cgroupfs --kubelet-cgroups=/systemd/user.slice/user-0.slice --allow-privileged=true --eviction-minimum-reclaim=imagefs.available=10%,nodefs.available=10% --anonymous-auth=false --cluster-domain=cluster.local --serialize-image-pulls=false --kubeconfig=/var/lib/rancher/k3s/agent/kubeconfig.yaml --hostname-override=minikube --runtime-cgroups=/systemd/user.slice/user-0.slice --healthz-bind-address=<IP_ADDRESS> --authorization-mode=Webhook
Flag --allow-privileged has been deprecated, will be removed in a future version
W0717 04:19:40.531138    6276 options.go:265] unknown 'kubernetes.io' or 'k8s.io' labels specified with --node-labels: [node-role.kubernetes.io/master]
W0717 04:19:40.544110    6276 options.go:266] in 1.16, --node-labels in the 'kubernetes.io' namespace must begin with an allowed prefix (kubelet.kubernetes.io, node.kubernetes.io) or be in the specificallyallowed set (beta.kubernetes.io/arch, beta.kubernetes.io/instance-type, beta.kubernetes.io/os, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, failure-domain.kubernetes.io/region, failure-domain.kubernetes.io/zone, kubernetes.io/arch, kubernetes.io/hostname, kubernetes.io/instance-type, kubernetes.io/os)
W0717 04:19:40.545252    6276 server.go:216] WARNING: all flags other than --config, --write-config-to, and --cleanup are deprecated. Please begin using a config file ASAP.
W0717 04:19:40.551017    6276 options.go:265] unknown 'kubernetes.io' or 'k8s.io' labels specified with --node-labels: [node-role.kubernetes.io/master]
W0717 04:19:40.551053    6276 options.go:266] in 1.16, --node-labels in the 'kubernetes.io' namespace must begin with an allowed prefix (kubelet.kubernetes.io, node.kubernetes.io) or be in the specificallyallowed set (beta.kubernetes.io/arch, beta.kubernetes.io/instance-type, beta.kubernetes.io/os, failure-domain.beta.kubernetes.io/region, failure-domain.beta.kubernetes.io/zone, failure-domain.kubernetes.io/region, failure-domain.kubernetes.io/zone, kubernetes.io/arch, kubernetes.io/hostname, kubernetes.io/instance-type, kubernetes.io/os)
INFO[2019-07-17T04:19:40.564879602Z] waiting for node minikube: nodes "minikube" not found
W0717 04:19:40.750788    6276 node.go:113] Failed to retrieve node info: nodes "minikube" not found
W0717 04:19:40.750952    6276 proxier.go:314] invalid nodeIP, initializing kube-proxy with <IP_ADDRESS> as nodeIP
INFO[2019-07-17T04:19:40.895121674Z] Starting batch/v1, Kind=Job controller
W0717 04:19:41.023240    6276 controllermanager.go:445] Skipping "root-ca-cert-publisher"
E0717 04:19:41.394662    6276 info.go:139] Failed to get system UUID: open /etc/machine-id: no such file or directory
W0717 04:19:41.394687    6276 info.go:52] Couldn't collect info from any of the files in "/etc/machine-id,/var/lib/dbus/machine-id"
E0717 04:19:41.434159    6276 cri_stats_provider.go:375] Failed to get the info of the filesystem withmountpoint "/var/lib/rancher/k3s/agent/containerd/io.containerd.snapshotter.v1.overlayfs": unable to find data in memory cache.
 Stats initialization may not have completed yet: invalid capacity 0 on image filesystem
W0717 04:19:41.474198    6276 util_unix.go:77] Using "/run/containerd/containerd.sock" as endpoint is deprecated, please consider using full url format "unix:///run/containerd/containerd.sock".
E0717 04:19:41.537956    6276 kubelet.go:2207] node "minikube" not found
E0717 04:19:41.539094    6276 controller.go:194] failed to get node "minikube" when trying to set owner ref to the node lease: nodes "minikube" not found
W0717 04:19:41.558508    6276 manager.go:537] Failed to retrieve checkpoint for "kubelet_internal_checkpoint": checkpoint is not found
E0717 04:19:41.596998    6276 eviction_manager.go:247] eviction manager: failed to get summary stats: failed to get node info: node "minikube" not found
INFO[2019-07-17T04:19:41.623503480Z] Starting /v1, Kind=Node controller
INFO[2019-07-17T04:19:41.625984493Z] Updated coredns node hosts entry [<IP_ADDRESS> minikube]
E0717 04:19:41.638348    6276 kubelet.go:2207] node "minikube" not found
INFO[2019-07-17T04:19:41.723636860Z] Starting /v1, Kind=Service controller
E0717 04:19:41.738637    6276 kubelet.go:2207] node "minikube" not found
INFO[2019-07-17T04:19:41.823837498Z] Starting /v1, Kind=Pod controller
INFO[2019-07-17T04:19:41.923956332Z] Starting /v1, Kind=Endpoints controller
INFO[2019-07-17T04:19:42.566550830Z] waiting for node minikube CIDR not assigned yet
INFO[2019-07-17T04:19:44.568310657Z] waiting for node minikube CIDR not assigned yet
INFO[2019-07-17T04:19:46.570289359Z] waiting for node minikube CIDR not assigned yet
INFO[2019-07-17T04:19:48.571957179Z] waiting for node minikube CIDR not assigned yet
INFO[2019-07-17T04:19:50.573601353Z] waiting for node minikube CIDR not assigned yet
W0717 04:19:51.633639    6276 shared_informer.go:312] resyncPeriod<PHONE_NUMBER>3346 is smaller than resyncCheckPeriod<PHONE_NUMBER>8082 and the informer has already started. Changing it to<PHONE_NUMBER>8082
W0717 04:19:51.634307    6276 shared_informer.go:312] resyncPeriod<PHONE_NUMBER>3109 is smaller than resyncCheckPeriod<PHONE_NUMBER>8082 and the informer has already started. Changing it to<PHONE_NUMBER>8082
E0717 04:19:51.634609    6276 resource_quota_controller.go:171] initial monitor sync has error: [couldn't start monitor for resource "k3s.cattle.io/v1, Resource=addons": unable to monitor quota for resource "k3s.cattle.io/v1, Resource=addons", couldn't start monitor for resource "helm.cattle.io/v1, Resource=helmcharts": unable to monitor quota for resource "helm.cattle.io/v1, Resource=helmcharts", couldn't start monitor for resource "k3s.cattle.io/v1, Resource=listenerconfigs": unable to monitor quota for resource "k3s.cattle.io/v1, Resource=listenerconfigs", couldn't start monitor for resource "extensions/v1beta1, Resource=networkpolicies": unable to monitor quota for resource "extensions/v1beta1, Resource=networkpolicies"]
W0717 04:19:51.634954    6276 controllermanager.go:445] Skipping "csrsigning"
W0717 04:19:51.712938    6276 actual_state_of_world.go:503] Failed to update statusUpdateNeeded field in actual state of world: Failed to set statusUpdateNeeded to needed true, because nodeName="minikube" does not exist
W0717 04:19:51.717015    6276 node_lifecycle_controller.go:833] Missing timestamp for Node minikube. Assuming now as a timestamp.
E0717 04:19:53.333946    6276 resource_quota_controller.go:437] failed to sync resource monitors: [couldn't start monitor for resource "extensions/v1beta1, Resource=networkpolicies": unable to monitor quota for resource "extensions/v1beta1, Resource=networkpolicies", couldn't start monitor for resource "k3s.cattle.io/v1, Resource=addons": unable to monitor quota for resource "k3s.cattle.io/v1, Resource=addons", couldn't start monitor for resource "helm.cattle.io/v1, Resource=helmcharts": unable to monitor quota for resource "helm.cattle.io/v1, Resource=helmcharts", couldn't start monitor for resource "k3s.cattle.io/v1, Resource=listenerconfigs": unable to monitor quota for resource "k3s.cattle.io/v1, Resource=listenerconfigs"]

Check:
$ k3s kubectl get all --all-namespaces
NAMESPACE     NAME                          READY   STATUS    RESTARTS   AGE
kube-system   pod/coredns-695688789-h62sd   1/1     Running   0          18s

NAMESPACE     NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)                  AGE
default       service/kubernetes   ClusterIP   <IP_ADDRESS>    <none>        443/TCP                  30s
kube-system   service/kube-dns     ClusterIP   <IP_ADDRESS>   <none>        53/UDP,53/TCP,9153/TCP   31s

NAMESPACE     NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/coredns   1/1     1            1           31s

NAMESPACE     NAME                                DESIRED   CURRENT   READY   AGE
kube-system   replicaset.apps/coredns-695688789   1         1         1       19s
$

Closing as docs site has moved to https://rancher.com/docs/k3s/latest/en/, please review and submit any changes there.


htlcswitch: add inbound routing fees receive support

This PR implements "receive" support for inbound fees. In short this means that a routing node operator gets to set distinct fee schedules for the movement of funds on their incoming channels. This enables more fine-grained flow control, potentially leading to an increase in capital efficiency.
More discussion on this change can be found in the corresponding bolts issue https://github.com/lightning/bolts/issues/835 and blip https://github.com/lightning/blips/pull/18
Mailing list post that elaborates a bit on the upgrade scenario and how this can be a non-breaking change: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-July/003643.html
Note that no network-wide upgrade is required for the inbound fee schedule to propagate.
Changes:

Ability to set an inbound base and proportional fee as part of the channel policy.
Broadcasting of the inbound fee schedule to the wider network.
Update the forwarding logic to take into account inbound fees. This does not break older senders as long as the inbound fee is negative.
Update the exit hop logic to apply an inbound fee. This does not break older senders as long as the inbound fee is negative.

For send support, see #6934.
Implementation details

The channel_update extra opaque data is stored in the database without any validation. This means that readers of this data must handle the case where a tlv error is encountered during parsing of the stream.
An alternative would be to do strict validation in ExtraOpaqueData.Decode when a message is received, but is more involved. It for example breaks the exisitng fuzz tests. Also, there may already be malformed tlv data in the database.

When a fee_insufficient failure happens on an intermediate node, still only the outgoing channel update is returned. The 256-byte failure message isn't able to accommodate both the incoming and outgoing channel policies until https://github.com/lightningnetwork/lnd/pull/6913 is widely deployed.  For now, this means that senders can only receive updates to the inbound policy via gossip.
For code that shows a future extended fee_insufficient, see https://github.com/lightningnetwork/lnd/pull/6967.

Inbound fee setting on private channels is denied in this PR because it would require a change to bolt11.

Fixes https://github.com/lightningnetwork/lnd/issues/4225

Added a scenario that underlines the advantage of inbound fees on the spec pr: https://github.com/lightning/bolts/issues/835#issuecomment-1222376127
Lightning Labs, what is your view on this feature?

@roasbeef: review reminder

Created BLIP for the gossip change: https://github.com/lightning/blips/pull/18

For the fee_insufficient failure message, I think we'd want to return not just the outgoing channel update, but also the incoming channel update. That way the sender has up to date fees for the pair of channels and the next attempt should work.
The problem though is the size limit of 256 bytes on the failure message. A fee_insufficient message with two channel updates attached is 274+ bytes.

@JssDWt I've tried out your suggestion lightning/blips#18 (comment) in a tacked-on commit.

Ah I see, that's great. I actually didn't realize you could still split up the fee computation in the pathfinding when using my suggestion there. I thought you couldn't reliably compute the fee to a node anymore, because you'd need information about the previous edge to calculate the fee for the current edge. But clearly the way you've implemented shows that it is possible.

Ah I see, that's great. I actually didn't realize you could still split up the fee computation in the pathfinding when using my suggestion there. I thought you couldn't reliably compute the fee to a node anymore, because you'd need information about the previous edge to calculate the fee for the current edge. But clearly the way you've implemented shows that it is possible.

Actually there was an error in the previous revision. For your suggestion, it is indeed required to carry over the amount for the next edge. Made that change.

Isolated receiver-side support in a separate commit.
The sender-side support is a bit complicated by BuildRoute with its three passes. I've been experimenting with reducing the number of passes (#6920) and going one step further by re-routing buildroute to pathfinding (#6921).

Removed send support commits and moved into separate pr #6934

Added commit to convert to fees based on the outgoing htlc amount plus outbound fee. See https://github.com/lightning/blips/pull/18#issuecomment-1261410529

@jssdwt: review reminder

I feel a change like this would benefit from an integration test case though, to bring confidence in the calculations end up at what we expect in a multi hop scenario.

I've modified the existing multi-hop payment test to include a routing node that charges a negative inbound fee. Pathfinding isn't aware of inbound fees yet and builds the route as before, but this does cover backwards compatibility of the change.

Added commit to record inbound fee collected by exit hops in the forwarding log.

@jssdwt: review reminder

Dropped exit hop inbound fees. I am not convinced that it is only good, see https://github.com/lightning/blips/pull/18#issuecomment-1284437820.
This also makes for a smaller delta, and requires no changes to store exit fees earned in the forwarding log.
Stored the exit fee code here: https://github.com/lightningnetwork/lnd/compare/master...bottlepay:lnd:inbound-fees-exit-hop

@jssdwt: review reminder

@jssdwt: review reminder

@jssdwt: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@bitromortac: review reminder

@saubyk Given that this is a pre-requisite for the send support, should we tag it for v0.17?

Hi @halseth tagged it for 0.17, but unsure if we'll have enough review bandwidth to get to it. If not, it may go in a point release after 17

Rebased PR on top of latest master

Thanks for the thorough review @ziggie1984.

It seems to me that with this change we potentially allow a node to earn negative fees on a forward or did I not see the preemptive check where we avoid exactly this case?

Reply in https://github.com/lightningnetwork/lnd/pull/6703/commits/feac8f0fce812c3bf9248daad7f59a17f8a47ff3#r1286726939

When sending through a private channel (not receiving) will the peer be ever able to communicate his inbound fee schedule to us? Imo that is not possible with this design or?

Reply in https://github.com/lightningnetwork/lnd/pull/6703/commits/feac8f0fce812c3bf9248daad7f59a17f8a47ff3#r1286737092

Did we come to conclusion how we wanna propagate the channel_upate msg when a payment fails (talking about the insufficient fee error here)? Are we gonna send back the outgoing and incoming feeupdate as well, seems like we do have the support for bigger failure msgs added in lnd.16? But what will the other implementations do if they are part of the route?

It is indeed the plan to send back both in and out fee policy with the insufficient fee error. But we need to know if the sender supports the longer failure message. In #6967, senders signal this in the forward onion tlv, but it is up for discussion how to do this exactly. LND 0.16 supports it (#6913 - it will just ignore the tlv extension), but there may be older senders. Perhaps the older senders' share of the user base is small enough to accept that they will no longer be able to interpret the failure message (specifically the out policy). This would avoid the signaling all together.

Will we enforce inbound fees also when we send funds to a direct peer or will we exclude this case ? Refering to this comment in your introduction description: "Update the exit hop logic to apply an inbound fee. This does not break older senders as long as the inbound fee is negative." I did not really see any change in the exit hop logic?

This is indeed outdated, removed from PR description.

Policy updates with a positive InboundFee should not be enabled by default, but only by explicitly setting an command line flag. As long as sender support in lnd is not available and other implementations have not caught up, this change is breaking for the network.
Furthermore, I believe that positive InboundFees for routing nodes are not necessary at all, since one could always adjust inbound and outbound fees in such a way that all inbound fees are non-positive, outbound fees are positive, and the routing costs for each channel combination remain the same. One would simply need to reduce all InboundFees by the largest amount and increase all outbound fees accordingly. This would not have a negative impact on the network but would even encourage other LN implementations to adopt the feature.
Whether positive InboundFees are necessary for pure receivers for liquidity management, I cannot judge.
Therefore, I believe that only negative InboundFees should be enabled by default in the standard. Positive fees should only be activated explicitly, with a prominent warning in the sample-lnd.conf to inform node operators of the consequences.

Created temp PR #8124 because I now longer have access to this branch.

Scenario 1:
A charges 3000 PPM because the channel is depleted and B is malicious, sets -3000 PPM to generate failures for A->B. A would be blamed in current pathfinding (assume B has opened many channels to strong sinks). B can do this because payments can't settle via the channel and B is not at risk of losing on inbound fees. We would need to account for this scenario in pathfinding, so that's more a penalization issue.

I am assuming that B is advertising a discount and then when the htlc arrives, B returns fee insufficient to the sender? In this case, lnd penalizes the A-B link. Can't B already return this error in the current situation too, without a negative inbound fee, when B's balance is zero?

Interesting, never thought about how insufficient fee errors are penalized, this seems to be similar. I was rather thinking of B attracting traffic to the A-B channel with a discount but A fails back with a temporary channel failure because they can't forward.

Interesting, never thought about how insufficient fee errors are penalized, this seems to be similar. I was rather thinking of B attracting traffic to the A-B channel with a discount but A fails back with a temporary channel failure because they can't forward.

Ah got it, that's a different one. The temp chan fail is still going to hit B too, because it penalizes the A-B link. But yes, it seems the ability for B to set a negative fee allows them to attract more traffic. It is floored at zero though. B can set a enormous negative fee, but it won't make the link A-B more attractive compared to a zero total fee. Implemented here: https://github.com/lightningnetwork/lnd/pull/6934/commits/e142c8d60aa867c5795f8b29f376f6e797282ce7#r1028989648

Rebased after move to models package in master.

Rebased

Rebased


t function for types information

It would be a dream to have also a t function to see a type properties. For record types for example something like this:
Silly code to explain the request
let t<'x> () = typeof<'x>.GetProperties()
                |> Seq.map (fun p -> p.Name, p.PropertyType.Name)
                |> Seq.map (fun (n, t) -> $"    {n}: {t}")
                |> String.concat "\n" |> fun s -> $"{{\n{s} }}";;

> t<System.Index>();;
val it: string =
  "{
    Start: Index
    End: Index
    Value: Int32
    IsFromEnd: Boolean }"

> t<Nostra.Event>();;
val it: string =
  "{
    Id: EventId
    PubKey: Author
    CreatedAt: DateTime
    Kind: Kind
    Tags: FSharpList`1
    Content: String
    Signature: SchnorrSignature }"

Hey @lontivero ,
thanks for raising this issue. I'll look into it 👀

This is sort-of similar to emitting the signature for a given type, right? At least once you get beyond records?

@baronfel it certainly feels like this, yeah.


get_ticker bid and ask not corrected for precision and not correct

Playing around with the new API calls I noticed the highest_bid and lowest_ask have two bugs:

They're not correctly corrected for precision, unlike the latest price field.
They're not up to date. You can see in the screenshot that the current lowest ask and highest bid are quite different from what get_ticker returns.

Everything else seems to be ok.

Another example:

In this one most things are wrong, actual volume was 14 EUR and 3960 BTS. There's definitely some issues with precision, and probably something to do with inversion of markets as well.

Some more observations:
Volumes don't get switched when the market is inverted, but the precisions get do get inverted.
Latest price does not get inverted at all, only the precision changes.

We're almost there, everything seems to be correct now except for the 24 hr change which is inversed. The below screens were taken at 18.45 on the 24th. The latest price was 35.9361, the last closing price at 18.45 on the 23rd was 39.5. get_ticker is returning a 24hr change of +9.92%.
The correct change should be (35.9361 - 39.5) / 39.5 = -9.02%

The 24 hr change displayed on the web is not using the get_ticker call. From the same market, get_ticker returned the correct 24hr change.

Patch has already been merged into Bitshares,

@theoreticalbts This branch is ready for review to be merged.

Just a note, the branch https://github.com/cryptonomex/graphene/compare/592-get_ticker contains new commits which will fix a witness crash issue, and need to be reviewed and merged (if haven't done already).

@abitmore @mvandeberg was that fix from 592-get_ticker ever merged into master?

It's merged into develop branch: https://github.com/cryptonomex/graphene/commit/2fb3cb107840efe75235d69c07b942970b048b28, but not yet merged into bitshares branch, see https://github.com/bitshares/bitshares-2/compare/bitshares...cryptonomex:develop

This issue was moved to bitshares/bitshares-core#178


English? or other idiom

Have a way to use english ?

Have a way to use english ?

not yet available


CSS

CSS
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
Given a Prework Study Guide Website
WHEN I view the study guide
THEN I see a dark blue header and footer, and four boxes with a shadow

JavaScript
As a boot camp student
I want the prework notes to be structured on a webpage
So that I can easily find and read the information
GIVEN a Prework Study GUide Website
WHEN I view the study guide
THEN I can see the four topics I learned listed along with a suggestion on what I should study first

README
As a boot camp student,
I want the prework notes to be structured on a webpage ,
So that I can easily find and read the information
GIVEN the prework project repository,
WHEN I view the README for the repository,
THEN I can see a professional README that provides information on the project and how to use it

Deployment
As a boot camp student,
I want the prework notes to be structured on a webpage,
So that I can easily find and read the information.
GIVEN a Prework Study Guide website,
WHEN I visit the website using the URL,
THEN I can access my website from any browser


Add support for picture strings in $fromMillis, $toMillis and $now

Ports the code from jsonata for parsing the picture strings and timezone strings which are optional parameters on $fromMillis, $toMillis and $now and removes the restrictions on specifying those optional parameters bringing the equivalent function to this package.

Thank you for your contributions!

There appears to be an issue with the tests for milliseconds with week number calculation:

$fromMillis(1515326400000, "Week: [W]") returned "Week: 2" and it should have reported Week 1

Using the maven: mvn clean install runs the batch of tests including the:
src/test/java/com/api/jsonata4java.test.expressions FromMillisFunctionTests:
{ "$fromMillis(1515326400000, "Week: [W]")",""Week: 1"",null},
Using a different class I'd developed, the millisecond time converts as follows so I'd expect this to be reported as Week 1 as well.:
Enter date to be converted (or Q to quit):
1515326400000
Timestamp: 2018-01-07 12:00:00.000000
xs:datetime: 2018-01-07T12:00:00.000Z
Default: 2018-01-07T12:00:00.000Z
EpochMS:<PHONE_NUMBER>000
Sun, 07 Jan 2018 12:00:00
January 07 2018 12:00:00
Could you please look into this and repair as needed?


Update Global Banner tracking

WHAT

Remove "Viewed" action tracking from Global Banner.

Introduce hit-scoped custom dimension 38 which has a value of "Global Banner viewed" when the banner is visible.

WHY
Performance analysis has revealed that the viewed action is taking up a lot of our hit allowance & it doesn't have any value currently, which is costing us lots of money.

Relevant Trello card: https://trello.com/c/HM1XWtJN

Thanks for approving this @andysellick   🙌
Andrew has checked the changes and all looks good to him so I'll be merging this into master


Multi cluster doc improve

What type of PR is this? documentation
Which issue does this PR fix: Add new multi cluster doc and diagram to reflect the new controller behaviour, deprecate the outdated description
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

I can change "my-hotel" to "my-gateway". The old doc didn't mention why it's recommended. I can add few sentences in the new doc to explain it.

We should have it clear what are k8s and aws/lattice concepts in picture. May be dont mix them together, if you want them on the same picture try to use layers.
I think only lattice resource need to be presented is service network since its no longer 1:1 map to the k8s gateway. for other k8s resource I can use k8s icon and word "k8s" to make it clear. Not quite sure how the layers looks like


[Bug] - Resolved pagination issue in database summary tab

Notes for Reviewers
This PR fixes #
https://github.com/meshery/meshery/assets/31584129/ef231564-a940-43f9-86f6-407a5844c5b8
Signed commits

[x] Yes, I signed my commits.

@UsmanDev09 Thank you! But I already fixed this issue #8064

@UsmanDev09 @Meyazhagan is this PR good to close?


Engagement/stewardship-focused questions

From Leo Donnachie,
Potentially scope to include some engagement/stewardship-focused questions to support users that are trying to engage colleagues within their organisations and/or with investee companies

Consider engagement questions (EY CBES questionaire)


crop toDataURL('image/svg+xml');

hi. while ive read posts on how to crop canvas, its output is base 64 png. and yes, not everyone has access to the server so doing the trimming client side would definitely be helpful.
would like to request to have a crop for base 64 svg. svg is still best for output because it is vector.

bump. this is a very useful feature. ^_^
i hope this feature gets some interest

Three years in and not even a reply. Bump

Three years in and not even a reply. Bump

Alright this made me emotional and want to close this issue once and for all . Will be back with solution. happy Coding.

PRs are welcome, though if this cropping code could be implemented as a separate library or as a separate function that can doesn't have to imported if it's not used, that would be preferable to avoid bloating this library with features few people need.
Also, I'm not really maintaining this library anymore. I'll try to clean up a few things soon and update the README file with information that I'm looking for a maintainer.

PRs are welcome, though if this cropping code could be implemented as a separate library or as a separate function that can doesn't have to imported if it's not used, that would be preferable to avoid bloating this library with features few people need.
Also, I'm not really maintaining this library anymore. I'll try to clean up a few things soon and update the README file with information that I'm looking for a maintainer.

First of all I've never taken PR before and i don't know how to maintain that, i mean except GitHub few commands and extending functions, features, parameters , etc of given libraries as per requirement, i just make patches and i really don't want to mess up with what's given to us (Thank you so much for that). Some features are logical in nature and some requires external packages to be handled, i made few packages as per my clients requirement but they are not mine at all, i've mentioned everything about them, i cloned it because some owner already abandoned their packages and some requires alot of updates like comparability with  PHP, jQuery, npm, yarn versions... new syntax, etc.
So i took chance as to learn how to do that ....and still learning. I'm really not a good contributor, because that requires proper attentions on issues, making more examples with different set of features, etc. My hands are all full right now otherwise i would have.
Again thank you for such a beautiful package.

I am sorry that I sounded offensive. I did not intend to offend anyone. Thank you for this package, I am happily using it. What I do not like on my search for specific answers is browsing through old and open tickets that did not receive any response, so perhaps I overlooked szimeks apparent response, that he took it up as an enhancement. Again, thank you for for this package.
To anyone desperately looking up ways for cropping SVG, I found out about multiple solutions.

I got lucky, because I am using those signatures in fabric.js, where you can import SVG in a way that it  trims the white-space automatically. See this code snippet:

fabric.loadSVGFromURL(svgFilePath, () => {
  // these are your signature path elements grouped together
    var loadedObjects = new fabric.Group(group);
  },
  function (item, object) {
    object.set("id", item.getAttribute("id"));
    group.push(object);
  }
);

2, You can modify the viewBox property in your SVG xml code to only show the signature.
3. Otherwise, if the background is blank, you could simply omit trimming any whitespace and work with the full vector-"image" of your signature. In another problem, where I include the SVG in a PDF-file, I went this way.

see https://github.com/szimek/signature_pad/issues/49#issuecomment-260976909


ObservableCollections select and selectList methods

Fixed #29

Updated Listeners implementation to simplify listeners presence/absence tracking
Get rid of old tracking via Registration wrapping
Abstract base class for derived collections
Selector-based derived collections

It would be nice to have a test for the new functionality for Listeneres

Nice to clear listeners in CompositeEventSource on the last item remove as you do in other places

In SelectorDerivedCollection you use deprecated getItem() method

I think the follow method in DerivedCollection should return a Registration and there should be a way to dispose the collection. What happens if we remove the last listener from the derived collection? I think, we will still have a listener to the collection which we follow, which is an obvious memory leak.

Before you fix the last issue, I can't merge this into the repo.

Changed CompositeEventSource to lazily init and remove listeners
Switched to getOld/New for item access
Re-written DerivedCollection so all registrations are now maintained privately.

I'm not sure what did you mean by "we will still have a listener to the collection which we follow". Isn't it the case covered by the SelectTest#listRegistrations/collectionRegistrations tests?
Could you reopen this request? It's inconvenient to create a new request for every review iteration. We loose the entire discussion and pollute the repository with duplicating requests.

Ok I will reopen it.

Additional comments:

Please don't use names like this: propertyLsnrs, myScrListRegistration In Java it should be called propertyListeners, mySourceRegistration.

BTW, what's the reason to use AtomicInteger in tests. This class is for concurrency, and we have no concurrency.

You have protected fields in DerivedCollection. Please, get rid of them.

I'm not sure what did you mean by "we will still have a listener to the collection which we follow". Isn't it the case covered by the SelectTest#listRegistrations/collectionRegistrations tests?

Actually I found out how you check this. You assign to a protected field. The method follow has a counterintuitive contract of assigning to the protected registration field. I can't accept a change with such an architectural problem.

I changed field names but I wasn't able to find anything about abbreviations in our style guide. Kept local variables as is. It looks a little overkill to have a 18 characters long name for a 8 lines long scope and our guide explicitly says so "When you create a local variable, try to use short names, i.e. use i instead of index, etc".
I can think of alternative solution with the Value class, but the code would look like count.set(count.get() - 1)
I can't find any protected fields in DerivedCollection.
See 3.

3,4 It was my fault - I pushed changes to a wrong branch. Check the DerivedCollection class now.

I think, you should squash review notes into one commit with the initial one.

The following comment is redundant:   // The following methods are intended for implementation of derived lists, similar to DerivedProperty.

Also, the code which you committed is uncompilable which is very sad.

Otherwise everything looks fine. Please, fix these problems and I will merge it in.

Squashing commits would require a new pull request, github wouldn't allow pull after history rewrite. Is it ok?
I just got 'mvn clean install' successful. What error do you see?

Yes, you should create a new pull request.
I have errors in the Properties class.


Does easyauth support basic authentication?

Hello, I have a fastapi API server as an easyauth client. Is it possible to authenticate the API routes in the client server using Basic Authentication?

Hi Randy,
In general, you will always exchange username / password for a token using the /login endpoint first, then use the token against protected endpoints. The token contains information such as permissions which the endpoint uses to decide if a user is allowed or not.
Let me know if this helps.

For our case, we would like to access the client APIs through a third party application QGIS and it would be tedious for our users if they need to go to another application and login to get a token that they will need to provide to the QGIS application to access our APIs. Is there a way for our client API to manually authenticate our users using the Basic Auth credentials they provide to our client endpoint?

@randyberos , here is one way to accomplish this with an EasyAuthClient
from fastapi import FastAPI

from easyauth.client import EasyAuthClient
from easyauth import get_user

server = FastAPI()

auth_client = EasyAuthClient.create(
    server,
    token_server='<IP_ADDRESS>',
    token_server_port=8090,
    auth_secret='abcd1234',
    default_permissions={'groups': ['users']}
)

async def custom_authenticator(username: str, password: str) -> str:
  token = await auth_client.rpc_server["easyauth"]["generate_auth_token"](
        username, password
  )
  if not "access_token" in token:
      message = (
          "invalid username / password"
          if "invalid username / password" in token
          else token
      )
      raise Exception(message)

  token = token["access_token"]

  # extract token id from token to store in valid token store
  token_id = self.decode_token(token)[1]["token_id"]
  auth_client.store["tokens"][token_id] = ""
  return token

This is a pretty good use case for a future enhancement of both EasyAuthServer & EasyAuthClient to provide a method that does exactly this. In summary, the client will pass the username / password to the connected EasyAuthServer via rpc & get a token, the token id will be cached locally as a valid token, then the token can be used on any endpoint attached with {"Authentication": "Bearer {token}"} header

Thank you for this @codemation. 😊
I will try this approach in our application.


chore(deps): update common-dev-assets digest to 7cf2be8

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
588b0ac -> 7cf2be8

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, click this checkbox.

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 1.0.13 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[FEATURE] add option to clear deploy folder after deploy

Is your feature request related to a problem? Please describe.
Right now, every time I need to manually clear deploy folder after each command before next package.
Describe the solution you'd like
I would like to get option to configure command to clearing deploy folder for me or prompt which will ask me if it should do it.

After our before which command would u imagine this?
What's your current workflow / which commands are you using?

For example, mcdev deploy --da will clear deploy folder from files which was recently pushed to MC.
Right now I am preparing files manually, from retrieve pasting to deploy, then changing code and then command deploy.
After every deploy I need to keep in mind to delete files from before, because if no, then I have bad moments ;P. So I was thinking if it is not good addition to give option to auto delete contents of deploy folder after success deploy.

picking up this topic in 4.4.0 now.
i thought about what flag(s) should be offered:
mcdev deploy --clean

maybe additionally we should offer the same flag for buildDefinition / buildDefinitionBulk. not sure about that though

blocked by pr #721


Handling update either using autoUpdate or Prompt startegy

How to handle the update startegy when new content is available, either using autoUpdate or Prompt startegy?
For instance, I want to prompt the users to update when new content is available, as well as cleanup outdated caches. Ref: Vite Plugin PWA

@vedxp this capability does not exist, but I’d be happy to review a PR implementing new functionality or a doc update illustrating how to achieve this UX.


Carthage build error

error: SWIFT_VERSION '3.0' is unsupported, supported versions are: 4.0, 4.2, 5.0. (in target 'Result-iOS' from project 'Result')
error: SWIFT_VERSION '3.0' is unsupported, supported versions are: 4.0, 4.2, 5.0. (in target 'Result-iOS' from project 'Result')
Please release new version :(

You have to specify like this to take the latest version:
github "snipsco/Postal" "HEAD"


Add missing package to mips build

Fix CGO build on MIPS due to missing gnu/stubs-n64_hard.h file.
Signed-off-by: Ben Kochie<EMAIL_ADDRESS>

This is a missing "recommends" package.


Fix warnings that 'yarn start' compalins about so we don't accidentally add new ones.

i cleaned up some these in my pr, lets hold off for a sec on this one

Okaydoke!

Closing for now.  Can reopen if it ends up being useful.


Support for chemical equations

Is your feature request related to a problem? Please describe.
Support to add chemical equations in the editor would make it easy for people to add these equations rather than pasting images which in the future leads to pixelation. This is similar to using LaTeX for mathematical formula.
Describe the solution you'd like
SMILES support can be added which is a standard way to support chemical equations across the web.
Describe alternatives you've considered
We were using image before this but leads to pixelation.
Additional context
https://en.wikipedia.org/wiki/Simplified_molecular-input_line-entry_system

I'm trying to implement something related, but unfortunately, it's on my backlog, I think this demo shows a good implementation on Kekule.js,
Kekule CKeditor plugin

@michelmar I tried implementing this a long time back with a different editor and couldn't make it work well. But this definitely helps.


Step 18 outdated

Visual Studio 15.7.3 no longer has Add (to iOS project) > New Item... > Visual C# > Code > Class. It is now under Add > New Item... > Apple > Code > Class.
Note: "Add (to iOS project) > Class..." would have been a simpler way to do this and, one would think, less likely to change across VS versions, but it is actually broken in 15.7.3 (probably because of the change from "Visual C#" to "Apple"), but I will add that to Product Feedback.

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

ID: 2de3e72c-8948-4dd5-e37f-9cf81e62c127
Version Independent ID: 7b7c5c7f-4102-8e91-fbe6-7d21fcc8f5be
Content: Xamarin.Forms Quickstart - Xamarin
Content Source: docs/xamarin-forms/get-started/hello-xamarin-forms/quickstart.md
Product: xamarin
GitHub Login: @davidbritch
Microsoft Alias: dabritch

I've fixed this in a forthcoming update.


Alter Table Add column doesn't get the column to appear in the UI

Context
Please explain here below what you were doing when the issue happened
alter table map_data
add column map5_t text,
add column map4_t text,
add column map3_t text,
add column map2_t text,
add column map1_t text
I tried again with varchar. the UI doesn't update, as described in the post and comments on #11114
turns out all 10 fields were there, but I had to manually add a new field to see them.
Steps to Reproduce
Please break down here below all the needed steps to reproduce the issue

alter a table to add one or several columns
check the dataset. scroll left and right.
the new columns do not appear

Current Result
Please describe here below the current result you got
The new columns do not appear by default. I only saw them after manually adding a column via the UI
Expected result
Please describe here below what should be the expected behaviour
I expect that when I refresh the screen after issuing an alter table add column query, that the new columns display. Actually, I don't expect to have the manually refresh the screen, but after refreshing, the new columns still did not appear.
Browser and version
What internet browser (Chrome, Firefox, etc) and version was you using and version
Chrome Version 57.0.2987.133 (64-bit)
.carto file
Don't forget to rename .carto file to .zip file to be able to upload to github
Additional info
Please add any information of interest here below
This bug is of a degree that it makes me lose some confidence in the product. I love carto, and don't want to leave it, but I've been losing a lot of time to bugs like this. Issue #11114 mentioned this, and was already closed, but the problem--at least with adding columns--is still there. Hence this new issue.

+1


persistent api keys

Save API keys in DB so that they don't expire

suppressed by https://github.com/Giskard-AI/giskard/pull/1342


Build failed on Error: EEXIST: file already exists, mkdir '/dev/null'

Hello, I was following your steps and get this error, is it something wrong on NPM_FLAGS="--prefix=/dev/null"? thanks
5:37:28 PM: ############################################### 100.0%
5:37:28 PM: Computing checksum with sha256sum
5:37:29 PM: Checksums matched!
5:37:30 PM: Now using node v8.17.0 (npm v6.13.4)
5:37:31 PM: Attempting ruby version 2.3.6, read from environment
5:37:32 PM: Using ruby version 2.3.6
5:37:32 PM: Using PHP version 5.6
5:37:32 PM: Started restoring cached node modules
5:37:32 PM: Finished restoring cached node modules
5:37:32 PM: Installing NPM modules using NPM version 6.13.4
5:37:33 PM: Error: EEXIST: file already exists, mkdir '/dev/null'
5:37:33 PM: TypeError: Cannot read property 'loaded' of undefined
5:37:33 PM:     at exit (/opt/buildhome/.nvm/versions/node/v8.17.0/lib/node_modules/npm/lib/utils/error-handler.js:97:27)
5:37:33 PM:     at errorHandler (/opt/buildhome/.nvm/versions/node/v8.17.0/lib/node_modules/npm/lib/utils/error-handler.js:216:3)
5:37:33 PM:     at /opt/buildhome/.nvm/versions/node/v8.17.0/lib/node_modules/npm/bin/npm-cli.js:78:20
5:37:33 PM: failed during stage 'building site': Build script returned non-zero exit code: 1
5:37:33 PM:     at cb (/opt/buildhome/.nvm/versions/node/v8.17.0/lib/node_modules/npm/lib/npm.js:225:22)
5:37:33 PM:     at /opt/buildhome/.nvm/versions/node/v8.17.0/lib/node_modules/npm/lib/npm.js:263:24
5:37:33 PM:     at /opt/buildhome/.nvm/versions/node/v8.17.0/lib/node_modules/npm/lib/config/core.js:81:7
5:37:33 PM:     at Array.forEach (<anonymous>)
5:37:33 PM:     at /opt/buildhome/.nvm/versions/node/v8.17.0/lib/node_modules/npm/lib/config/core.js:80:13
5:37:33 PM:     at f (/opt/buildhome/.nvm/versions/node/v8.17.0/lib/node_modules/npm/node_modules/once/once.js:25:25)

Hey @hotyes can you share your whole netlify.toml file?
Or a minimum reproducable repo that I can look at

@CryogenicPlanet I am able to get it run now. This is the netlify.toml I am using:
[build]
    command = "npx pnpm i -r --store=node_modules/.pnpm-store && npx pnpm run build"
    publish = "public"

[build.environment]
    NODE_VERSION = "14"
    NPM_FLAGS = "--prefix=/dev/null"

Yeah, I think the docs for setting the build command are not great, will update!
In the meantime, closing this


fix(deps): bump google-gax to 1.7.5

Uh, @alexander-fenster  minding checkout what's up here?

@JustinBeckwith Permissions problem on video intelligence system tests. @bcoe was going to take a look.


Consider adding section about VCS

Monorepos tend to become very large and optionally have large binary blobs in them (for example art content in gamedev). So different VCS should be considered. For example git as-is is not suitable for large binary objects, etc. Also, it would be great to talk about integration of VCS and build system such as to be able only to checkout folder of particular projects and all of their dependencies.

@RedwanFox Interesting idea.

optionally have large binary blobs in them (for example art content in gamedev)

Storing large blobs, in general, doesn't work very well with Git. Though it is more a VCS thing than strictly related to monorepos. Ofc, If you combine it with a monorepo the problem becomes more apparent, and quicker. Let me think about how to potentially wire this into the page. We want to keep it as lean as possible but still informative.

Also, it would be great to talk about integration of VCS and build system such as to be able only to checkout folder of particular projects and all of their dependencies.

I was actually planning to have some content around this. Git allows you to do sparse-checkouts, and with Nx in particular, you have programmatic access to its project graph. As such you can easily create a script which would allow you to say something like my-customscript checkout proj1 and it would be able to leverage the project graph to checkout proj1 and all the other projects it depends on. Could be an interesting use case for very large repos.
Although truth be told, as part of the the consulting activity I have seen some massive repos, and Git was usually the last issue. It is pretty powerful 😃


Loosen type checks in responder

This one might be a bit of a stretch but here's my reasoning. I think I'm one of the most active ACA-Py plugin developers at the moment and one of the things I've found is that it can be somewhat burdensome to follow the same pattern ACA-Py does for defining messages and handlers in all cases. I've experimented with using a simplified base class other than the AgentMessage in ACA-Py and have had favorable results. There is a loss of functionality but, with these tweaks, the core functions work. From what I've gathered so far, the lost functionality is limited primarily to timing and tracing features, which might be a reasonable trade-off in a plugin context if a different root message class integrates better with the rest of your code.
This PR uses typing.Protocol to define the expected methods on messages to send, loosening the original explicit type check for AgentMessage to a "shape" check. This uses the typing-extensions package to backport typing.Protocol for python 3.6.
Rather than defining just what the responder needs to send a message, it might make sense to define something somewhere else that outlines the minimum functional agent message attributes. To get a message from decrypted object to being handled, a minimum of Handler, and deserialize is required. To get a message from creation (in a handler, for instance) to being sent as an encrypted message, a minimum of to_json and _thread_id is required.
Interested to hear thoughts :slightly_smiling_face:

Codecov Report

:exclamation: No coverage uploaded for pull request base (main@73361c6). Click here to learn what that means.
The diff coverage is 100.00%.

@@           Coverage Diff           @@
##             main    #1096   +/-   ##
=======================================
  Coverage        ?   99.37%
=======================================
  Files           ?      381
  Lines           ?    21881
  Branches        ?        0
=======================================
  Hits            ?    21744
  Misses          ?      137
  Partials        ?        0

While I'm on the subject of my experiments lol, I've also tried out using class decorators to remove a lot of the boilerplate currently required for defining AgentMessages with good success. However, I think I prefer the alternate base class approach because the decorator approach introduces a lot more magic.

That's not a bad option. I think if we want to create a protocol for outbound messages, then to_json might not be the ideal way to do that, though. With DIDComm v2 the structure of the messages will change, and at a minimum the serializer will need the message contents separated from the decorators. A generic way to do that might be to pass in an instance of a 'MessageSerializer' type interface and have the message implementation call methods on that to produce the result. An easier way would be for the serializer to just pull out the decorators and move them (but it's less than ideal if it has to parse the generated JSON to do that).
Another option here would be to create an abstract base class for serializable messages with a method (not to_json) used to produce the expected result, then implement it for AgentMessage by just delegating to to_json, at least for now.

Ah, interesting. My changes were very much coming at this from the minimal changes required approach lol. Parsing through your comment, I think I'm missing something still. In what way is a to_json method insufficient in anticipation of DIDComm v2? Is it a backwards compatibility issue where we want messages to be able to produce JSON conforming to either the original format or DIDComm? Or producing output in forms other than JSON? Or am I off the mark entirely?

@dbluhm  My concern is just that we don't want each message implementation to be worrying about what DIDComm version is currently being used. Or rather that they do have to worry about that, but in the AgentMessage case it can all be handled in one place, and otherwise there's no standard way to pass in that information. If we want to formalize a protocol for converting the message to its external representation then it should probably include some context in the parameters at least, and we may want to do the same when deserializing.

That makes more sense to me now, thanks for the clarification. After a fair amount of thought, I came up with the following:
class DIDCommVersion(Enum):
    """Message formats."""

    v1 = auto()
    v2 = auto()

class BaseMessage(ABC):
    """Abstract base class for messages."""

    @abstractproperty
    def type(self) -> str:
        """Return message type."""

    @abstractproperty
    def id(self) -> str:
        """Return message id."""

    @abstractmethod
    def serialize(
        self, msg_format: DIDCommVersion = DIDCommVersion.v1
    ) -> dict:
        """Return serialized message in format specified."""

    @abstractclassmethod
    def deserialize(
        cls,
        value: dict,
        msg_format: DIDCommVersion = DIDCommVersion.v1
    ):
        """Return message object deserialized from value in format specifified."""

    @abstractproperty
    def Handler(self) -> Type:
        """Return reference to handler class."""

This formally defines a "minimum viable message" and provides an unopinionated class for plugins to extend in whatever way makes sense in the context of the plugin. I considered continuing with usage of typing.Protocol and splitting up the different pieces (SerializableMessage, DeserializableMessage, HandleableMessage, etc.) but did not find much value in that approach. On top of that, I think explicitly inheriting from a base class for messages communicates our intent clearer than doing the structural sub-typing and checking shape before use.
I spent a good while thinking about what providing a MessageSerializer instance would look like. I like the idea -- I think it fits nicely with python's json.dumps(cls=AlternateEncoder) -- but given how we tend to use the to_json/serialize methods, providing a serializer that knows how to handle plugged in message classes and outputs the message in the desired format seems unworkable, unless we define another intermediate format for the serializer to consume. In the end, just providing the desired output format as an enum was the most flexible method I thought up.
If this approach seems agreeable, I'll probably just close out this PR and open a new one with these classes added and using BaseMessage in key places like the dispatcher and responder in place of AgentMessage.

Closing in favor of #1133


How to find openshift crc bundle in latest directory

In this remote directory https://mirror.openshift.com/pub/openshift-v4/clients/crc/latest/
is file https://mirror.openshift.com/pub/openshift-v4/clients/crc/latest/crc_virtualbox_4.1.11.crcbundle
It would be nice to fully automated to get the file without version in crc-version
https://github.com/phracek/openshift4-crc/blob/master/crc-versions.yaml#L5

Fixed


don't cargo test in rust-build smoke-test

-3 Don't run rust tests twice (these got re-introduced in the rust-build task from the --all-features pr)
-12 Don't run the disk cleaner (not actually seeing CI fail now, and it didn't used to take this long. leaving commented)
-3 Don't vendor dependencies (they're not used by the r tests)
-5 Don't run rust doctests (just the 31 doctests, many of which are internal, take 5 minutes on their own)

Perhaps we can move rust doctests out to unit tests in future work

This reduces smoke-test from 31 minutes to 7 minutes.

#1579  👈
main

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

Join @Shoeboxam and the rest of your teammates on  Graphite

Maybe things will speed up in the future with https://github.com/rust-lang/rust/issues/75341.
In the meantime I might open a PR that moves some doctests to unit tests.


imports inside raw string literals are removed

package main

import (
	"fmt"
)

func main() {
	fmt.Println("hello world")
}

const helloWorld = `
package main

import (
	"fmt"
)

func main() {
	fmt.Println("hello world")
}

gets reformated to
package main

import (
	"fmt"
)

func main() {
	fmt.Println("hello world")
}

const helloWorld = `
package main

import (
)

func main() {
	fmt.Println("hello world")
}

There the import is now broken.

@ekle
Thank you for reporting a bug.
It was fixed by #113 and a new version including this fix has been released.
https://github.com/rinchsan/gosimports/releases/tag/v0.3.1
Sorry for your incovenience!

@rinchsan
No need to be sorry.
Thank you for fixing it!


SwiftLocation.shared.currentLocation returns CLLocation

It seems that SwiftLocation.shared.currentLocation returns a CLLocation object and not a CLPlacemark object as the documentation states.

+1
Swift Newbie here. Spent minutes trying to figure how to extract the coordinates from the CLPlacemark object. Used .dynamicType and realised it was CLLocation.

Fixed


Bug Fixes

This just contains a couple of bug fixes for the build system. I also removed the '-g' OpenCL compiler option when nVidia's OpenCL runtime is used since it is not supported.

Both of these issues have been fixed on the /develop branch.  We only merge PR's that target the /develop branch in general.  Please build from the /develop branch for now, there are probably other bug fixes you would like.
We should be pushing the /develop branch into the /master branch within a few weeks.

Thanks Kent. Good to know; I should have checked the developer branch in
the first place. :-)
Robert
On 03/26/2015 08:26 AM, Kent Knox wrote:

Both of these issues have been fixed on the /develop branch. We only
merge PR's that target the /develop branch in general. Please build
from the /develop branch for now, there are probably other bug fixes
you would like.
We should be pushing the /develop branch into the /master branch
within a few weeks.
—
Reply to this email directly or view it on GitHub
https://github.com/clMathLibraries/clBLAS/pull/76#issuecomment-86568385.


Refactoring of Query based classes

[x] Convert to a base abstract class and make the rest of the classes as derived.

Fixed in #56