local backup doesn't work

Describe the bug
every time I go to make a backup or go to the specific backup folder, it is simply empty, that is, it is not making a backup even though I click on "force synchronization", I also changed the file type from markdown to json and none works and doesn't show any error warning.
To Reproduce
Steps to reproduce the behavior:

Go to 'settings'
Click on 'Backup'
Scroll down to 'select the folder'
See error, empty folder without any backup files.

Additional context
I don't know if this is relevant, but the folder selected to store the backup is inside the external storage, i.e. SD Card.

What I observed on Android is that I'm only able to do local storage under the Download folder


Fetch cloud watch  metrics from other aws accounts

Would be good to also specify different accounts to fetch metrics from too.

Agreed, so the option of per metric api key?

Thank you for your suggestion. Now the API to submit data points is supported. I think you can show metrics from other aws accounts by using this API. Here is the link to the API docs:
https://github.com/ks888/LambStatus/wiki/LambStatus-API-v0


JSON-based index names

Addresses #444, changes the index naming scheme to the following format:
hz[_geo][_multi_<offset>]_<JSON>
Where 'offset' is a number corresponding to the offset of the field that is multi-indexed.  We probably won't support having multiple multi fields in a single index as that would require generating all the permutations of multiple fields, which could be very expensive.  geo and multi aren't implemented yet as we do not have them in the API.  Still, the server should parse them fine and warn that they are not supported for when we add them later.
The JSON in the index name should be an array containing field names as strings, or nested fields as arrays of strings.
Example (from the comments in index.js):
Fields indexed: foo.bar, baz
Index name: hz_[["foo","bar"],"baz"]

This works around the problem with deterministic JSON serialization of objects mentioned in #444, and is slightly shorter.

This change is

:+1: good idea for the field name serialization.

Merging after OTS review from @deontologician.


Upgrade dartdoc to 0.11.1

This is a minor change that fixes dart-lang/dartdoc#1401 and is the last dartdoc binary change for Flutter I'm planning to make before I/O.
Compare new version:  http://jcollins1.pdx.corp.google.com:8000/flutter/widgets/OverlayEntry-class.html
with 0.11.0: http://jcollins1.pdx.corp.google.com:8001/flutter/widgets/OverlayEntry-class.html


error in Obx Example when you turn off the connection.

Describe the bug
error in Obx Example when you turn off the connection.
════════ Exception caught by widgets library ═══════════════════════════════════
The following NoSuchMethodError was thrown building Obx(dirty, state: _ObxState#12bfb):
The getter 'totalConfirmed' was called on null.
Receiver: null
Tried calling: totalConfirmed
The relevant error-causing widget was
Obx
package:get_state/…/views/home_view.dart:26
When the exception was thrown, this was the stack
#0      Object.noSuchMethod  (dart:core-patch/object_patch.dart:53:5)
#1      HomePage.build.
package:get_state/…/views/home_view.dart:41
#2      _ObxState.notifyChilds
package:get/…/rx/rx_obx.dart:56
#3      _ObxState.build
package:get/…/rx/rx_obx.dart:72
#4      StatefulElement.build
package:flutter/…/widgets/framework.dart:4648
To Reproduce
Steps to reproduce the behavior:

Go to 'setting and turn off internet connection'
recompile the app and you will get the error ,

Expected behavior
it's seem that Obx.value are never null because it's a instance of "ApiModel"
Flutter Version:
1.7.3
Get Version:
3.3
Describe on which device you found the bug:
Android
Minimal reproduce code
check the example in the package of get

done ! I find the error it's in :
class HomeProvider {
Future fetchData() async {
try {
final response = await Dio().get("https://api.covid19api.com/summary");
return ApiModel.fromJson(response.data);
} catch (e) {
print(e.toString());
return ApiModel();
}
}
}
it must be Null and not ApiModel()
class HomeProvider {
Future fetchData() async {
try {
final response = await Dio().get("https://api.covid19api.com/summary");
return ApiModel.fromJson(response.data);
} catch (e) {
print(e.toString());
return null;
}
}
}

since the PR related to this issued were merged, i'll close this


vertx-hazelcast 4.4.x is not able to unregister member from previous version if they are not cleanly stopped.

Version
4.4.1
Context
In a cluster having Vertx member in different versions (in my case 4.4.1 & 4.3.7), an unclean shutdown of a 4.3.7 member will lead to a broken member map.
4.4.1 members will not be able to correctly unregister the dead 4.3.7 member.
By unclean shutdown, I mean a shutdown that doesn't call vertx.close().
Easiest way to reproduce is to kill a process in a terminal with Ctrl+C.
After this event occurs one time, the hazelcast member map is corrupted and will never recover. A ghost node will be present in the map forever.
It looks to me this is not something that occurs between member of the same version (4.3.7 or 4.4.1).
Do you have a reproducer?

Link to github project/gist

Steps to reproduce
See the reproducer project.
Extra
I tried locally a fix that seems to work.
The fix is located in the method: io.vertx.spi.cluster.hazelcast.HazelcastClusterManager#memberRemoved.
When a member from a previous verison die, the method is called and is not able to resolve the node id nid.
The fix check if the nid is null and in this case fallback to use the node uuid.
  @Override
  public synchronized void memberRemoved(MembershipEvent membershipEvent) {
    if (!active) {
      return;
    }
    Member member = membershipEvent.getMember();
    String nid = member.getAttribute(NODE_ID_ATTRIBUTE);
    if (nid == null) {
      nid = member.getUuid().toString();
    }
    try {
      membersRemoved(Collections.singleton(nid));
    } catch (Throwable t) {
      log.error("Failed to handle memberRemoved", t);
    }
  }

I will provide a PR if this fix seems ok.

Adding a bit more context, it seems that the issue occurs when the dying node is the last 4.3 node in the cluster.
If there is other 4.3 nodes remaining on the cluster they are able to clear the map and the issue is not perceptible.

This is is not a bug, it's due to #170 (and reported as breaking change https://github.com/vert-x3/wiki/wiki/4.4.0-Deprecations-and-breaking-changes#hazelcast-cluster-manager)
Your change doesn't look harmful (but it might not work if Hazelcast has changed the id of the 4.3 member see #164).
If you can propose a PR by next week (4.4.2 release), I'll review it. We'll need to consider the impact on other places in the code where the node id is read.

Hello,
Thanks for your answer.
Perhaps I misunderstood the breaking changes, but it was not clear for me that it was a breaking change between Vertx 4.3 & 4.4.
I will provide a PR proposing a fix for that.
On the other side, what can be the best way to migrate 4.3 to 4.4 without having to shutdown the cluster?
Best,

On the other side, what can be the best way to migrate 4.3 to 4.4 without having to shutdown the cluster?

With the patch you've provided, and if 4.3 nodes don't crash before you have replaced them with 4.4 nodes, you can mix 4.3 and 4.x nodes in the same cluster.

Hello,
From what I can see the fix (#175 ) is not present in the code released under versions 4.4.2, 4.4.3 and 4.4.4.
I just discovered, releases 4.4.2, 4.4.3 and 4.4.4 has been done on branch 4.x and not 4.4.


docs: add theme color to header logo text

The "Anchor" text next to the logo in the top left of the page header did not respect the active theme.
Added dark:text-white to the class list for the span element.
(new docs look awesome @italoacasas !)

Good catch, thanks @callensm


Make Login button functional

Once logged in, the user would already exist in the database. Check that and if it is there, it should go to dashboard page, if not prompt sign up page with error showing "user is not signed up"

done


Helm init fails on Kubernetes 1.16.0

Output of helm version: v2.14.3
Output of kubectl version:  client:  v1.15.3,   server: v1.16.0-rc.1
Cloud Provider/Platform (AKS, GKE, Minikube etc.):  IBM Cloud Kubernetes Service
$ helm init --service-account tiller
$HELM_HOME has been configured at /Users/xxxx/.helm.
Error: error installing: the server could not find the requested resource

$ helm init --debug --service-account tiller
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
.
.
.

Looks like helm is trying to create tiller Deployment with: apiVersion: extensions/v1beta1
According to:   https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16
that is no longer supported.

We've avoided updating tiller to apps/v1 in the past due to complexity with having helm init --upgrade reconciling both extensions/v1beta1 and apps/v1 tiller Deployments. It looks like once we start supporting Kubernetes 1.16.0 we will have to handle that case going forward.

Here's a short-term workaround:
helm init --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

You might be able to achieve the same effect with the --override flag than crazy sed hacks :)

Nice! You might be able to achieve the same effect with the --override flag than crazy sed hacks :)

Yes, but his crazy sed hacks I can copy & paste, whereas this helm init   --override "apiVersion"="apps/v1" just not work. Ok, the sed hack does not work either.

current workaround seems to be something like this:
helm init --output yaml > tiller.yaml
and update the tiller.yaml:

change to apps/v1
add the selector field

---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
....

The following sed works-for-me:
helm init --service-account tiller --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | sed 's@  replicas: 1@  replicas: 1\n  selector: {"matchLabels": {"app": "helm", "name": "tiller"}}@' | kubectl apply -f -

The issue with @mattymo solution (using kubectl patch --local) is that is seems to not work when its input contains multiple resource (here a Deployment and a Service).

Kubernetes 1.16.0 was release yesterday:  9/18/2018.
Helm is broken on this latest Kubernetes release unless the above work around is used.
When will Helm 2.15.0 be released ?

If you want to use one less sed :)
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -
Thanks!

Today I met the same issue, I changed the label by myself. I change the label to apps/v1 and add  selector part,as of now it perform great, below is my yaml file:
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

Hi @mihivagyok , @PierreF

The following sed works-for-me:
helm init --service-account tiller --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | sed 's@  replicas: 1@  replicas: 1\n  selector: {"matchLabels": {"app": "helm", "name": "tiller"}}@' | kubectl apply -f -

The issue with @mattymo solution (using kubectl patch --local) is that is seems to not work when its input contains multiple resource (here a Deployment and a Service).

If you want to use one less sed :)
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -
Thanks!

Can you use helm after it?
Installation of nginx returns error:
helm install --name nginx stable/nginx-ingress
Error: validation failed: unable to recognize "": no matches for kind "Deployment" in version "extensions/v1beta1"

@jbrette you are my hero! I was struggling with the selector stanza.

Today I met the same issue, I changed the label by myself. I change the label to apps/v1 and add selector part,as of now it perform great, below is my yaml file:
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

how to change ? can you describe more details?

Today I met the same issue, I changed the label by myself. I change the label to apps/v1 and add selector part,as of now it perform great, below is my yaml file:
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

@gm12367 how to change and can you describe more details?

Today I met the same issue, I changed the label by myself. I change the label to apps/v1 and add selector part,as of now it perform great, below is my yaml file:
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          httpGet:
            path: /liveness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
        - containerPort: 44135
          name: http
        readinessProbe:
          httpGet:
            path: /readiness
            port: 44135
          initialDelaySeconds: 1
          timeoutSeconds: 1
        resources: {}
      serviceAccountName: tiller
status: {}

@gm12367 how to change and can you describe more details?

For example, you can use helm init --service-account tiller --tiller-namespace kube-system --debug to print YAML-format manifests, --debug option will do this

@gm12367  Yes, I can see the print but just output. So, what command I can change the output?

@gm12367 I want to change apps/v1 and add selector part

@puww1010 I just redirected the output in a file, and then used VIM to change it. Below commands as reference.
helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml
vim helm-init.yaml
kubectl apply -f helm-init.yaml

if your go environment is set up and you can't wait until the following PR which fixes this issue [Helm init compatible with Kubernetes 1.16] #6462  is merged, you can always do:
Build
mkdir p ${GOPATH}/src/k8s.io
cd ${GOPATH}/src/k8s.io
git clone -b kube16 https://github.com/keleustes/helm.git
cd helm
make bootstrap build

Test:
kubectl version

Client Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:36:53Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}
Server Version: version.Info{Major:"1", Minor:"16", GitVersion:"v1.16.0", GitCommit:"2bd9643cee5b3b3a5ecbd3af49d09018f0773c77", GitTreeState:"clean", BuildDate:"2019-09-18T14:27:17Z", GoVersion:"go1.12.9", Compiler:"gc", Platform:"linux/amd64"}

/bin/helm init --wait --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3
Creating /home/xxx/.helm
Creating /home/xxx/.helm/repository
Creating /home/xxx/.helm/repository/cache
Creating /home/xxx/.helm/repository/local
Creating /home/xxx/.helm/plugins
Creating /home/xxx/.helm/starters
Creating /home/xxx/.helm/cache/archive
Creating /home/xxx/.helm/repository/repositories.yaml
Adding stable repo with URL: https://kubernetes-charts.storage.googleapis.com
Adding local repo with URL: http://<IP_ADDRESS>:8879/charts
$HELM_HOME has been configured at /home/xxx/.helm.

Tiller (the Helm server-side component) has been installed into your Kubernetes Cluster.

Please note: by default, Tiller is deployed with an insecure 'allow unauthenticated users' policy.
To prevent this, run `helm init` with the --tiller-tls-verify flag.
For more information on securing your installation see: https://docs.helm.sh/using_helm/#securing-your-helm-installation

kubectl get deployment.apps/tiller-deploy -n kube-system -o yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  annotations:
    deployment.kubernetes.io/revision: "1"
  creationTimestamp: "2019-09-22T01:01:11Z"
  generation: 1
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
  resourceVersion: "553"
  selfLink: /apis/apps/v1/namespaces/kube-system/deployments/tiller-deploy
  uid: 124001ca-6f31-417e-950b-2452ce70f522
spec:
  progressDeadlineSeconds: 600
  replicas: 1
  revisionHistoryLimit: 10
  selector:
    matchLabels:
      app: helm
      name: tiller
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:
    metadata:
      creationTimestamp: null
      labels:
        app: helm
        name: tiller
    spec:
      automountServiceAccountToken: true
      containers:
      - env:
        - name: TILLER_NAMESPACE
          value: kube-system
        - name: TILLER_HISTORY_MAX
          value: "0"
        image: gcr.io/kubernetes-helm/tiller:v2.14.3
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          httpGet:
            path: /liveness
            port: 44135
            scheme: HTTP
          initialDelaySeconds: 1
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        name: tiller
        ports:
        - containerPort: 44134
          name: tiller
          protocol: TCP
        - containerPort: 44135
          name: http
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          httpGet:
            path: /readiness
            port: 44135
            scheme: HTTP
          initialDelaySeconds: 1
          periodSeconds: 10
          successThreshold: 1
          timeoutSeconds: 1
        resources: {}
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
      dnsPolicy: ClusterFirst
      restartPolicy: Always
      schedulerName: default-scheduler
      securityContext: {}
      terminationGracePeriodSeconds: 30
status:
  availableReplicas: 1
  conditions:
  - lastTransitionTime: "2019-09-22T01:01:23Z"
    lastUpdateTime: "2019-09-22T01:01:23Z"
    message: Deployment has minimum availability.
    reason: MinimumReplicasAvailable
    status: "True"
    type: Available
  - lastTransitionTime: "2019-09-22T01:01:11Z"
    lastUpdateTime: "2019-09-22T01:01:23Z"
    message: ReplicaSet "tiller-deploy-568db6b69f" has successfully progressed.
    reason: NewReplicaSetAvailable
    status: "True"
    type: Progressing
  observedGeneration: 1
  readyReplicas: 1
  replicas: 1
  updatedReplicas: 1

@jbrette Still having the same issue after following your instruction

@jbrette Still having the same issue after following your instruction

Looks like you typed "helm" instead of "./bin/helm"....so you are using the old version of the binary.

After successful init you won't be able to install a chart package from repository until replacing extensions/v1beta1 in it as well.
Here is how to adapt any chart from repository for k8s v1.16.0
The example is based on prometheus chart.
git clone https://github.com/kubernetes/charts
cd charts/stable

Replace extensions/v1beta1 to policy/v1beta1 PodSecurityPolicy:
sed -i 's@apiVersion: extensions/v1beta1@apiVersion: policy/v1beta1@' `find . -iregex ".*PodSecurityPolicy.*" -exec egrep -R 'extensions/v1beta1' {} + | awk -F ":" '{print $1}'`

NetworkPolicy apiVersion is handled well by _helpers.tpl for those charts where it is used.
Replace extensions/v1beta1 to apps/v1 in Deployment, StatefulSet, ReplicaSet, DaemonSet
sed -i 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' `find . -iregex ".*yaml\|.*ylm" -exec awk '/kind:\s+(Deployment|StatefulSet|ReplicaSet|DaemonSet)/ {print FILENAME}' {} +`

Create a new package:
helm package ./prometheus
Successfully packaged chart and saved it to: /home/vagrant/charts/stable/prometheus-9.1.1.tgz

Install it:
helm install /home/vagrant/charts/stable/prometheus-9.1.1.tgz

Getting the same error when running helm init --history-max 200
output
$HELM_HOME has been configured at /Users/neil/.helm.
Error: error installing: the server could not find the requested resource

$ helm version
Client: &version.Version{SemVer:"v2.14.3", GitCommit:"0e7f3b6637f7af8fcfddb3d2941fcc7cbebb0085", GitTreeState:"clean"}
Error: could not find tiller

This branch works https://github.com/keleustes/helm/tree/kube16. You can build the branch yourself. I also uploaded the binary here for your convenience https://s3-us-west-2.amazonaws.com/bin.cryptexlabs.com/github.com/keleustes/helm/kube16/helm. One caveat is you have to use the canary image flag helm init --canary-image since the build is unreleased

You should not need the canary image to make this work. I would suggest using helm init --tiller-image gcr.io/kubernetes-helm/tiller:v2.14.3 as @jbrette mentioned earlier if you want to try out #6462.
I'd recommend users to try one of the workarounds provided earlier first before trying out a PR; that way they can continue to use Helm 2.14.3 instead of a custom dev branch that's still under review.

When i do the command it deploy it but after that cans see it in pods and says Error from server (NotFound): pods "tiller-deploy" not found

helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

deployment.apps/tiller-deploy created
service/tiller-deploy created
But when i do  kubectl get pods --all-namespaces cant see the pods
NAMESPACE     NAME                          READY   STATUS    RESTARTS   AGE
kube-system   coredns-5644d7b6d9-559hw      1/1     Running   0          23h
kube-system   coredns-5644d7b6d9-xcmjd      1/1     Running   0          23h
kube-system   etcd-fmp                      1/1     Running   0          24h
kube-system   kube-apiserver-fmp            1/1     Running   0          24h
kube-system   kube-controller-manager-fmp   1/1     Running   1          24h
kube-system   kube-flannel-ds-amd64-ffx2g   1/1     Running   0          23h
kube-system   kube-proxy-lfvrz              1/1     Running   0          24h
kube-system   kube-scheduler-fmp            1/1     Running   0          24h
kubectl get all --all-namespaces | grep tiller
kube-system   service/tiller-deploy   ClusterIP   xxx           44134/TCP                2m52s
kube-system   deployment.apps/tiller-deploy   0/1     0            0           2m54s
kube-system   replicaset.apps/tiller-deploy-77855d9dcf   1         0         0       2m54s

@DanielIvaylov I think you don't have the tiller service account. Please create it, and then the deployment will create the tiller pod too.
Thanks!

@DanielIvaylov I think you don't have the tiller service account. Please create it, and then the deployment will create the tiller pod too.
Thanks!
Sorry, im new i tought that this is going to start it. How i start the tiller service account?

@DanielIvaylov
kubectl --namespace kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

Added below flag to api server (/etc/kubernetes/manifests/kube-apiserver.yaml) that temporarily re-enabled those deprecated API.
--runtime-config=apps/v1beta1=true,apps/v1beta2=true,extensions/v1beta1/daemonsets=true,extensions/v1beta1/deployments=true,extensions/v1beta1/replicasets=true,extensions/v1beta1/networkpolicies=true,extensions/v1beta1/podsecuritypolicies=true
This fixed the helm v2

For people on windows, we were able to install/upgrade tiller via powershell like so:
$(helm init --output yaml) -replace "extensions/v1beta1","apps/v1"

Here's a short-term workaround:
helm init --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

Actually, it's not good enough. I still get an error:
error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

This can be patched in with:
/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

for me the kubectl patch is hanging
no messages in the /var/log/syslog file
service accounts already exist
kubeflow@masternode:~$ kubectl --namespace kube-system create sa tiller
Error from server (AlreadyExists): serviceaccounts "tiller" already exists
kubeflow@masternode:~$ kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller
Error from server (AlreadyExists): clusterrolebindings.rbac.authorization.k8s.io "tiller" already exists
can you please advise

executing the below
export PATH=$PATH:/usr/local/bin
which helm
which tiller
helm install
--name nfs-client-provisioner
--set nfs.server=<IP_ADDRESS>
--set nfs.path=/nfsroot
--set storageClass.name=nfs
--set storageClass.defaultClass=true
stable/nfs-client-provisioner
returns back with

/usr/local/bin/helm
/usr/local/bin/tiller
Error: could not find tiller

appreciate any help as this is now a show stopper

@cyrilthank It seems the tiller error is because there is no tiller deployment running, try running this command to install tiller:
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -
helm version should return the server (tiller) version if its up and running properly

Thank you Sir.
You have been helpful in enabling us to proceed with kubeflow to the next step

ok now i think i got this issue
https://github.com/kubeflow/kubeflow/issues/4184
back as blocker
Appreciate it much if you could help with advice on how i may get some help on the https://github.com/kubeflow/kubeflow/issues/4184

@cyrilthank try the steps provided above: https://github.com/helm/helm/issues/6374#issuecomment-533853888
You need to replace the deprecated api versions with the new one

kubeflow_workaround_and_error_traces.txt
Thank you Sir for your patient replies especially in keeping this issue open
Sorry about this but looks like i am doing something wrong in the workaround steps
Appreciate if you could review the steps in the attached traces and advise me on what i am doing wrongly

@cyrilthank you just need to run the sed commands against your kubeflow yamls to replace the old api extension with the new one (no need to deploy prometheus at all 😆 ). Sorry If I didnt express myself well enough.
The fix is basically replacing extensions/v1beta1 with apps/v1in your kubeflow dpl yamls

ah so i did a dumb copy :(
my KFAPP=/nfsroot/kf-poc
i still seem to be getting a few messages and the final error out
can you please help as i depend on you now to move to the next step on kubeflow
kubeflow_workaround_sed_and_error_traces.txt

@cyrilthank you just need to run the sed commands against your kubeflow yamls to replace the old api extension with the new one (no need to deploy prometheus at all laughing ). Sorry If I didnt express myself well enough.
The fix is basically replacing extensions/v1beta1 with apps/v1in your kubeflow dpl yamls

apps/v1beta2 also to apps/v1
https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

Thanks much @uniuuu for your help
Can you please advise where/how to obtain the yaml files referenced in https://github.com/helm/helm/issues/6374#issuecomment-535888077
https://github.com/helm/helm/issues/6374#issuecomment-533840097
https://github.com/helm/helm/issues/6374#issuecomment-533185074
requesting since after making the sed changes we still have encountered the errors referenced in

can you please advise if the step
kubectl convert -f  --output-version /
needs to be executed for every  being every yaml file in the KFAPP location including .kache

If you have applied the workaround mentioned above when working with helm init, and still get the following error when trying things like helm version, it's because the helm deployment cannot be found.
Error: could not find tiller

You need to run kubectl get events --all-namespaces | grep -i tiller to know why it's not ready.
For example, my issue is simply as below, because I don't need serviceaccount "tiller" with microk8s.
microk8s.kubectl get events --all-namespaces | grep -i tiller
kube-system    23m         Warning   FailedCreate                   replicaset/tiller-deploy-77855d9dcf            Error creating: pods "tiller-deploy-77855d9dcf-" is forbidden: error looking up service account kube-system/tiller: serviceaccount "tiller" not found

So I did the workaournd without the service account
- helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -
+ helm init spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

could not find till

If you have applied the workaround mentioned above when working with helm init, and still get the following error when trying things like helm version, it's because the helm deployment cannot be found.
Error: could not find tiller

You need to run kubectl get events --all-namespaces | grep -i tiller to know why it's not ready.
For example, my issue is simply as below, because I don't need serviceaccount "tiller" with microk8s.
microk8s.kubectl get events --all-namespaces | grep -i tiller
kube-system    23m         Warning   FailedCreate                   replicaset/tiller-deploy-77855d9dcf            Error creating: pods "tiller-deploy-77855d9dcf-" is forbidden: error looking up service account kube-system/tiller: serviceaccount "tiller" not found

So I did the workaournd without the service account
- helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -
+ helm init spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

@cyrilthank you just need to run the sed commands against your kubeflow yamls to replace the old api extension with the new one (no need to deploy prometheus at all 😆 ). Sorry If I didnt express myself well enough.
The fix is basically replacing extensions/v1beta1 with apps/v1in your kubeflow dpl yamls

Hi @Jabbo16
I tried manually changing the yaml file for selector errors  as below
"./suggestion/base/suggestion-bayesianoptimization-service.yaml"
selector:
matchLabels:
app: katib
component: suggestion-bayesianoptimization
...
selector:
matchLabels:
app: katib
component: suggestion-bayesianoptimization
and the file "./suggestion/base/suggestion-bayesianoptimization-deployment.yaml"
selector:
matchLabels:
app: katib
component: suggestion-bayesianoptimization
...
selector:
matchLabels:
app: katib
component: suggestion-bayesianoptimization
but i still get the below error
service/katib-suggestion-random configured
error when applying patch:
to:
Resource: "/v1, Resource=services", GroupVersionKind: "/v1, Kind=Service"
Name: "katib-suggestion-bayesianoptimization", Namespace: "kubeflow"
Object: &{map["apiVersion":"v1" "kind":"Service" "metadata":map["annotations":map["kubectl.kubernetes.io/last-applied-configuration":"{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"katib-suggestion-bayesianoptimization","namespace":"kubeflow","selector":{"labels":{"app":"katib","component":"suggestion-bayesianoptimization"}}},"spec":{"ports":[{"name":"api","port":6789,"protocol":"TCP"}],"selector":{"app":"katib","component":"suggestion-bayesianoptimization"},"type":"ClusterIP"}}\n"] "creationTimestamp":"2019-09-27T09:26:14Z" "name":"katib-suggestion-bayesianoptimization" "namespace":"kubeflow" "resourceVersion":"55475" "selfLink":"/api/v1/namespaces/kubeflow/services/katib-suggestion-bayesianoptimization" "uid":"516ff052-59ad-43c1-a826-7d52020bcff8"] "spec":map["clusterIP":"<IP_ADDRESS>" "ports":[map["name":"api" "port":'\u1a85' "protocol":"TCP" "targetPort":'\u1a85']] "selector":map["app":"katib" "component":"suggestion-bayesianoptimization"] "sessionAffinity":"None" "type":"ClusterIP"] "status":map["loadBalancer":map[]]]}
for: "STDIN": error when creating patch with:
original:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"katib-suggestion-bayesianoptimization","namespace":"kubeflow","selector":{"labels":{"app":"katib","component":"suggestion-bayesianoptimization"}}},"spec":{"ports":[{"name":"api","port":6789,"protocol":"TCP"}],"selector":{"app":"katib","component":"suggestion-bayesianoptimization"},"type":"ClusterIP"}}
modified:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"katib-suggestion-bayesianoptimization","namespace":"kubeflow","selector":{"matchLabels":{"app":"katib","component":"suggestion-bayesianoptimization"}}},"spec":{"ports":[{"name":"api","port":6789,"protocol":"TCP"}],"selector":{"matchLabels":{"app":"katib","component":"suggestion-bayesianoptimization"}},"type":"ClusterIP"}}\n"},"name":"katib-suggestion-bayesianoptimization","namespace":"kubeflow","selector":{"matchLabels":{"app":"katib","component":"suggestion-bayesianoptimization"}}},"spec":{"ports":[{"name":"api","port":6789,"protocol":"TCP"}],"selector":{"matchLabels":{"app":"katib","component":"suggestion-bayesianoptimization"}},"type":"ClusterIP"}}
current:
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{"kubectl.kubernetes.io/last-applied-configuration":"{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"katib-suggestion-bayesianoptimization","namespace":"kubeflow","selector":{"labels":{"app":"katib","component":"suggestion-bayesianoptimization"}}},"spec":{"ports":[{"name":"api","port":6789,"protocol":"TCP"}],"selector":{"app":"katib","component":"suggestion-bayesianoptimization"},"type":"ClusterIP"}}\n"},"creationTimestamp":"2019-09-27T09:26:14Z","name":"katib-suggestion-bayesianoptimization","namespace":"kubeflow","resourceVersion":"55475","selfLink":"/api/v1/namespaces/kubeflow/services/katib-suggestion-bayesianoptimization","uid":"516ff052-59ad-43c1-a826-7d52020bcff8"},"spec":{"clusterIP":"<IP_ADDRESS>","ports":[{"name":"api","port":6789,"protocol":"TCP","targetPort":6789}],"selector":{"app":"katib","component":"suggestion-bayesianoptimization"},"sessionAffinity":"None","type":"ClusterIP"},"status":{"loadBalancer":{}}}
for: "STDIN": unable to find api field in struct ObjectMeta for the json field "selector"
Error from server (Invalid): error when creating "STDIN": Deployment.apps "katib-suggestion-bayesianoptimization" is invalid: [spec.selector: Required value, spec.template.metadata.labels: Invalid value: map[string]string(nil): selector does not match template labels]
Please help
requesting as i am not getting any response on https://github.com/kubeflow/kubeflow/issues/4184
for the APIV3 error

@cyrilthank I removed your comment because it isn't relevant to the discussion involved here. Please continue to follow up in kubeflow/kubeflow#4184. Thanks!

helm init spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

Slight correction
helm init --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

+1

@puww1010 I just redirected the output in a file, and then used VIM to change it. Below commands as reference.
# helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml
# vim helm-init.yaml
# kubectl apply -f helm-init.yaml

I tried doing this. After editing the file in VIM i use the kubectl apply command, but it doesn't seem to do anything. When I run helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml again or helm init --output yaml the changes haven't been applied. Anyone else experience this?

If you want to use one less sed :)
helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -
Thanks!

I just upgraded our k8s and I faced this problem and I used above solution. It creates deployment but replicaset fails and this is what I get from kubectl describe -n kube-system replicasets.apps tiller-deploy-77855d9dcf:
Events:
  Type     Reason        Age                 From                   Message
  ----     ------        ----                ----                   -------
  Warning  FailedCreate  41s (x14 over 82s)  replicaset-controller  Error creating: pods "tiller-deploy-77855d9dcf-" is forbidden: error looking up service account kube-system/tiller: serviceaccount "tiller" not found

Where I can find a yaml file to create that serviceaccount?

@DanielIvaylov
kubectl --namespace kube-system create sa tiller
kubectl create clusterrolebinding tiller --clusterrole cluster-admin --serviceaccount=kube-system:tiller

This solved my problem!

#6462 has been merged and will be available in the next release (2.15.0). For now, feel free to use the workarounds provided above or use the canary release.
Thanks everyone!

Canary image still produces the same error unless it doesn't have this merge yet,

@puww1010 I just redirected the output in a file, and then used VIM to change it. Below commands as reference.
# helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml
# vim helm-init.yaml
# kubectl apply -f helm-init.yaml

I tried doing this. After editing the file in VIM i use the kubectl apply command, but it doesn't seem to do anything. When I run helm init --service-account tiller --tiller-namespace kube-system --debug >> helm-init.yaml again or helm init --output yaml the changes haven't been applied. Anyone else experience this?

Yeah, happening for me as well.

You might need to change the image location to gcr.azk8s.cn/kubernetes-helm/tiller:v2.14.3 the gcr.io location seems to be blocked.

While a completely valid issue, that issue is slightly orthogonal to the issue present in this issue, gcr.io is blocked in China, unfortunately. See https://github.com/helm/charts/issues/14607 for more information.

we have been able to  fix this issue by rolling back kubernetes to 1.15.4

Thanks @UmamaheshMaxwell for sharing this.
Can you please share the steps you used to rollback the kubernetes version?

@cyrilthank if it's minikube, minikube config set kubernetes-version v1.15.4

Thanks @UmamaheshMaxwell for sharing this.
Can you please share the steps you used to rollback the kubernetes version?

@cyrilthank  we have been using our own VMs ( Ubuntu 18+), below are the setps to install k8s version 1.15.4

kubeadm reset
sudo apt-get install kubelet=1.15.4-00 kubectl=1.15.4-00 kubeadm=1.15.4-00
sudo kubeadm init --pod-network-cidr=<IP_ADDRESS>/16 --apiserver-advertise-address=x.x.x.x --apiserver-cert-extra-sans=x.x.x.x --kubernetes-version "1.15.4"

--pod-network-cidr=<IP_ADDRESS>/16 - flannel
--apiserver-advertise-address=x.x.x.x - private IP of your VM ( Master)
--apiserver-cert-extra-sans=x.x.x.x - Public IP of your VM ( Master)
Let me know if you still have any questions.

@cyrilthank if it's minikube, minikube config set kubernetes-version v1.15.4

Thanks @MrSimonEmms  mine is not mini I think I will have to go with @UmamaheshMaxwell 's steps

Thanks @UmamaheshMaxwell for sharing this.
Can you please share the steps you used to rollback the kubernetes version?
@cyrilthank  we have been using our own VMs ( Ubuntu 18+), below are the setps to install k8s version 1.15.4
kubeadm reset
sudo apt-get install kubelet=1.15.4-00 kubectl=1.15.4-00 kubeadm=1.15.4-00
sudo kubeadm init --pod-network-cidr=<IP_ADDRESS>/16 --apiserver-advertise-address=x.x.x.x --apiserver-cert-extra-sans=x.x.x.x --kubernetes-version "1.15.4"
--pod-network-cidr=<IP_ADDRESS>/16 - flannel
--apiserver-advertise-address=x.x.x.x - private IP of your VM ( Master)
--apiserver-cert-extra-sans=x.x.x.x - Public IP of your VM ( Master) ( This is required, if you are trying to access your Master from your local machine.
Note: Follow the below link to set up a kubeconfig file for a self-hosted Kubernetes cluster (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
Let me know if you still have any questions.

Thanks @UmamaheshMaxwell for your patient reply
I have an existing kubernetes 1.16 setup can you please confirm if I can try running these steps?

Thanks @UmamaheshMaxwell for sharing this.
Can you please share the steps you used to rollback the kubernetes version?
@cyrilthank  we have been using our own VMs ( Ubuntu 18+), below are the setps to install k8s version 1.15.4
kubeadm reset
sudo apt-get install kubelet=1.15.4-00 kubectl=1.15.4-00 kubeadm=1.15.4-00
sudo kubeadm init --pod-network-cidr=<IP_ADDRESS>/16 --apiserver-advertise-address=x.x.x.x --apiserver-cert-extra-sans=x.x.x.x --kubernetes-version "1.15.4"
--pod-network-cidr=<IP_ADDRESS>/16 - flannel
--apiserver-advertise-address=x.x.x.x - private IP of your VM ( Master)
--apiserver-cert-extra-sans=x.x.x.x - Public IP of your VM ( Master) ( This is required, if you are trying to access your Master from your local machine.
Note: Follow the below link to set up a kubeconfig file for a self-hosted Kubernetes cluster (http://docs.shippable.com/deploy/tutorial/create-kubeconfig-for-self-hosted-kubernetes-cluster/)
Let me know if you still have any questions.

Thanks @UmamaheshMaxwell for your patient reply
I have an existing kubernetes 1.16 setup can you please confirm if I can try running these steps?

Yeah @cyrilthank, even we had kubernetes 1.16.1 but we had to roll it back to 1.15.4, below is the link if you want to set it up from scratch.
VM's OS Version
Distributor ID:	Ubuntu
Description:	Ubuntu 18.04.3 LTS
Release:	18.04
Codename:	bionic

Clean up kuberenetes
kubeadm reset
sudo apt-get purge kubeadm kubectl kubelet kubernetes-cni kube*
sudo apt-get autoremove
sudo rm -rf ~/.kube

Setup Kubernetes (Both Master and Node)
https://www.howtoforge.com/tutorial/how-to-install-kubernetes-on-ubuntu/
(you better automate the steps suggested in above link as much as you can, to save your time)
Let me know if you still need any further help. Happy Journey with roll back :), hope you have a smooth journey with it.

You might need to change the image location to gcr.azk8s.cn/kubernetes-helm/tiller:v2.14.3 the gcr.io location seems to be blocked.

While a completely valid issue, that issue is slightly orthogonal to the issue present in this issue, gcr.io is blocked in China, unfortunately. See helm/charts#14607 for more information.

I'm not in China, but the US. But I think my VPN blocked that site. Anyway, I followed all the steps outlined in this thread and couldn't get it working until I tried to get the image manually and saw it was not responding--just something else to try in case someone else gets stuck at the same spot as me.

I'm also getting the error:
$ helm init
$HELM_HOME has been configured at C:\Users\user\.helm.
Error: error installing: the server could not find the requested resource

I'm trying a solution proposed in this issue, particularly this. However, after modifying the tiller.yaml file accordingly, I'm not able to update the configuration.
I'm trying the following:
$ kubectl apply -f tiller.yaml
deployment.apps/tiller-deploy configured
service/tiller-deploy configured

But then, if I run:
$ helm init --output yaml > tiller2.yaml

The tiller2.yaml file shows:
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  template:

So I assume that I'm not updating the configuration properly. What would be the correct way to do it?

helm init --service-account tiller --override spec.selector.matchLabels.'name'='tiller',spec.selector.matchLabels.'app'='helm' --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

Its worked for me, Thank you so much

As the Kubernetes API evolves, APIs are periodically reorganized or upgraded. When APIs evolve, the old API is deprecated and eventually removed.
The v1.16 release will stop serving the following deprecated API versions in favor of newer and more stable API versions:
NetworkPolicy (in the extensions/v1beta1 API group)
    Migrate to use the networking.k8s.io/v1 API, available since v1.8. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1 API.
PodSecurityPolicy (in the extensions/v1beta1 API group)
    Migrate to use the policy/v1beta1 API, available since v1.10. Existing persisted data can be retrieved/updated via the policy/v1beta1 API.
DaemonSet, Deployment, StatefulSet, and ReplicaSet (in the extensions/v1beta1 and apps/v1beta2 API groups)
    Migrate to use the apps/v1 API, available since v1.9. Existing persisted data can be retrieved/updated via the apps/v1 API.

The v1.20 release will stop serving the following deprecated API versions in favor of newer and more stable API versions:
Ingress (in the extensions/v1beta1 API group)
    Migrate to use the networking.k8s.io/v1beta1 API, serving Ingress since v1.14. Existing persisted data can be retrieved/updated via the networking.k8s.io/v1beta1 API.

As a helm n00b who is using minikube, I was able to get around this issue by setting a kubernetes version like so:
$ minikube delete
$ minikube start --kubernetes-version=1.15.4

Hope it helps!

@PierreF I used your solution ( https://github.com/helm/helm/issues/6374#issuecomment-533186177 ) with k8s v1.16.1 and helm v2.15.0 and the tiller is not working.
Readiness probe failed: Get http://<IP_ADDRESS>:44135/readiness: dial tcp <IP_ADDRESS>:44135: connect: connection refused

@joshprzybyszewski-wf I used following command
minikube start --memory=16384 --cpus=4 --kubernetes-version=1.15.4
kubectl create -f istio-1.3.3/install/kubernetes/helm/helm-service-account.yaml
helm init --service-account tiller
helm install istio-1.3.3/install/kubernetes/helm/istio-init --name istio-init --namespace istio-system
helm install istio-1.3.3/install/kubernetes/helm/istio --name istio --namespace istio-system

And now get,
Error: validation failed: [unable to recognize "": no matches for kind "DestinationRule" in version "networking.istio.io/v1alpha3", unable to recognize "": no matches for kind "DestinationRule" in version "networking.istio.io/v1alpha3", unable to recognize "": no matches for kind "attributemanifest" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "attributemanifest" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "handler" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "handler" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "instance" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2", unable to recognize "": no matches for kind "rule" in version "config.istio.io/v1alpha2"]

Here's a short-term workaround:
helm init --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

Actually, it's not good enough. I still get an error:
error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

This can be patched in with:
/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

you missed to add macthLabels post selector.

I was forwarded to @jbrette 's solution. This is what I got when I ran it
error: error parsing STDIN: error converting YAML to JSON: yaml: line 11: mapping values are not allowed in this context

This has been fixed in Helm 2.16.0.

I was forwarded to @jbrette 's solution. This is what I got when I ran it
error: error parsing STDIN: error converting YAML to JSON: yaml: line 11: mapping values are not allowed in this context

Check the yaml files, in most cases that referenced line has { } or [ ] and still has other things defined under it which causes the error.

Just a side note to @PierreF's and @mihivagyok's solution. Those did not work for me when I use private helm repos.
helm repo add companyrepo https://companyrepo
Error: Couldn't load repositories file (/home/username/.helm/repository/repositories.yaml).

I guess that happens because helm init is not run, just generates yaml file. I fixed that by running helm init -c as an extra.

in k8s v1.16.6, helm init otput require spec.selector fyi .

current workaround seems to be something like this:
helm init --output yaml > tiller.yaml
and update the tiller.yaml:

change to apps/v1
add the selector field

---
apiVersion: apps/v1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
  replicas: 1
  strategy: {}
  selector:
    matchLabels:
      app: helm
      name: tiller
....

It's works, since kubernetes change apiVersion apps/v1 to for Deployment, there is one thing need to be change is we need to add selector matchLabels for spec

Another workaround can be to use helm 3, which does not use tiller.

helm init --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

Hi, while trying this am getting this :
jenkins@jenkin:~/.kube$ helm init --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -
Command 'kubectl' not found, but can be installed with:
snap install kubectl
Please ask your administrator.
jenkins@jenkin:~/.kube$

Output of helm version: v2.14.3
Output of kubectl version: client: v1.15.3, server: v1.16.0-rc.1
Cloud Provider/Platform (AKS, GKE, Minikube etc.): IBM Cloud Kubernetes Service
$ helm init --service-account tiller
$HELM_HOME has been configured at /Users/xxxx/.helm.
Error: error installing: the server could not find the requested resource

$ helm init --debug --service-account tiller
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  creationTimestamp: null
  labels:
    app: helm
    name: tiller
  name: tiller-deploy
  namespace: kube-system
spec:
.
.
.

Looks like helm is trying to create tiller Deployment with: apiVersion: extensions/v1beta1
According to: https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16
that is no longer supported.

am getting this error: how can I solve it???
root@jenkin:~# helm init --service-account tiller
$HELM_HOME has been configured at /root/.helm.
Error: error installing: unknown (post deployments.extensions)
root@jenkin:~#

Here's a short-term workaround:
helm init --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -

Actually, it's not good enough. I still get an error:
error validating data: ValidationError(Deployment.spec): missing required field "selector" in io.k8s.api.apps.v1.DeploymentSpec

This can be patched in with:
/usr/local/bin/kubectl patch --local -oyaml -f - -p '{"spec":{"selector": {"app":"helm","name":"tiller"}}}'

I am getting this error :
jenkins@jenkin:~/.helm$ helm init --output yaml | sed 's@apiVersion: extensions/v1beta1@apiVersion: apps/v1@' | kubectl apply -f -
Command 'kubectl' not found, but can be installed with:
snap install kubectl
Please ask your administrator.
jenkins@jenkin:~/.helm$

Workaround, using jq:
helm init -o json | jq  '(select(.apiVersion == "extensions/v1beta1") .apiVersion = "apps/v1")' | jq  '(select(.kind == "Deployment") .spec.selector.matchLabels.app = "helm")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.name = "tiller")' | kubectl create -f -

Workaround, using jq:
helm init -o json | jq '(select(.apiVersion == "extensions/v1beta1") .apiVersion = "apps/v1")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.app = "helm")' | jq '(select(.kind == "Deployment") .spec.selector.matchLabels.name = "tiller")' | kubectl create -f -

You can't update resource with kubectl create

@ikarlashov easy enough to replace 'create' with 'apply.'


[NEW ALGORITHM] Longest Common Substring in Dynamic Programming

Issue will be closed if:

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

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

Name:
Longest Common Substring in Dynamic Programming
About:
The Longest Common Substring problem is a classic problem in dynamic programming. Given two strings, the goal is to find the longest substring that is common to both strings. A substring is a sequence of characters that occurs consecutively within a string.

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

Assignees:

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

can you please assign this issue to me?


Show Closed if position has been closed

If user closes position show Closed in portfolio sections in the UI. Closed should be default table label color, not green and not red. Changes are needed in both trading page position section and in portfolio positions quad.

this has been implemented on the portfolio page for the new order and position rows.
we are waiting on the trading page to be updated with these rows.


Support for cmd + plus, cmd + minus

Hello,
is it possible to detect cmd+plus (plus -> keyCode: 107) and cmd+minus (minus -> keyCode: 109)? I tried set keyName='cmd+*' and then detect the key by keyCode in onKeyDown but that doesn't work because the event.keyCode is always equal to cmd (91) and key === 'cmd+*'.
Thanks!

@cernym43 Cmd + * hotkeys are not supported

I was considering this library but this feature not working is a total dealbreaker. It's a standard convention for zoom in/out, etc. Other libraries seem to work around this by converting '+' to 'plus', etc. See for example:
https://gist.github.com/abuduba/c41d40a1b45990c086de6d3b24bdd85a#file-hotkeys-js-L115

@cernym43 Example: https://codesandbox.io/s/hotkeys-127-sph13
hotkeys("cmd+*", function(event) {
  event.preventDefault();
  if (event.key === "=") {
    console.log("====>", event);
  }
  if (event.key === "-") {
    console.log("---->", event);
  }
});

https://github.com/jaywcjlove/hotkeys/issues/108


gnome-notify: init at 0.1.5

Description of changes
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
24.05 Release Notes (or backporting 23.05 and 23.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[x] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

I'm just wondering if gnome-notify is a correct name for the package: the project isn't even on GNOME GitLab...

Yeah, but probably ntfy-notify or notify-client would be more neutral?


Hard to distinguish between a test host crash because of a hang or an actual crash

Example log:
C:\helix\work\workitem>C:\helix\work\correlation\dotnet.exe C:\helix\work\correlation\sdk\6.0.0\vstest.console.dll System.Net.Security.Tests.dll --Settings:.runsettings --Platform:x64 --Blame:"CollectDump;CollectAlways=true;DumpType=Full;CollectHangDump;HangDumpType=Full;TestTimeout=900s" -- RunConfiguration.DotNetHostPath="C:\helix\work\correlation\dotnet.exe"
Microsoft (R) Test Execution Command Line Tool Version 16.8.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
Data collector 'Blame' message: VSTEST_DUMP_PATH is specified. Dump files will be saved in: C:\helix\work\workitem\uploads, and won't be added to attachments..
 Reason: Test host process crashed
Data collector 'Blame' message: VSTEST_DUMP_PATH is specified. Dump files will be saved in: C:\helix\work\workitem\uploads, and won't be added to attachments..
Data collector 'Blame' message: The specified inactivity time of 15 minutes has elapsed. Collecting hang dumps from testhost and its child processes.
Data collector 'Blame' message: VSTEST_DUMP_PATH is specified. Dump files will be saved in: C:\helix\work\workitem\uploads, and won't be added to attachments..
Data collector 'Blame' message: Dumping 8144 - dotnet.
Results File: C:\helix\work\workitem\TestResults\ContainerAdministrator_03766C25FF57_2020-10-12_16_26_49.trx
Html test results file : C:\helix\work\workitem\TestResults\TestResult_ContainerAdministrator_03766C25FF57_20201012_164227.html

Attachments:
  C:\helix\work\workitem\TestResults\5eaac373-c39f-4541-afe3-2459ab467952\Sequence_a8afda8e091d49939835686d0fa1543a.xml
Passed!  - Failed:     0, Passed:  4542, Skipped:    20, Total:  4562, Duration: 9 m 33 s - System.Net.Security.Tests.dll (netcoreapp6.0)
Test Run Aborted.

The active Test Run was aborted because the host process exited unexpectedly. Please inspect the call stack above, if available, to get more information about where the exception originated from.
The test running when the crash occurred:
System.Net.Security.Tests.SslStreamAlertsTest.SslStream_StreamToStream_HandshakeAlert_Ok

This test may, or may not be the source of the crash.

The log says that the run was aborted because the test host process crashed but after that it says that the inactivity time has elapsed. I'm unsure if this means that the test process crashed because of a test crash or because a test hang.

I tried to tell the runner that datacollector is killing the testhost, but I could not find a good way, this probably needs more love.

In NuGet.Client team we use dotnet test hang detection and longRunningTestSeconds setting to enable long-running (hung) test detection. If any tests is running longer than time specified, xUnit will display the test as long running one in the log followed by dotnet blame log.
[Long Running Test] 'NuGet.Commands.Test.RuntimeTargetsTests.RestoreTargets_RestoreWithRuntimesAsync', Elapsed: 00:14:03
[Long Running Test]' NuGet.Commands.Test.NETCoreProject2ProjectTests.NETCoreProject2Project_VerifyCompileForTransitiveSettings(expected: "BDXY", ab: True, bc: False, cd: True, ax: True, xy: True, yd: True)', Elapsed: 00:14:02
  Blame: Creating hang dump of process dotnet (5225).
  The active test run was aborted. Reason: Test host process crashed
  Data collector 'Blame' message: The specified inactivity time of 15 minute/s has elapsed. Collecting a dump and killing the test host process..

@kartheekp-ms How does that relate to this issue?

@ViktorHofer - The title of the issue says Hard to distinguish between a test host crash because of a hang or an actual crash. I agree with that. I thought using xUnit longRunningTestSeconds setting will help because it adds additional information [Long Running Test] before hang/crash dump was collected.

I think it would be best if VSTest itself logs all the information that is useful to identify a hanging test and not rely on an adapter's feature for that.

This needs additional synchronization with datacollector. What happens is that as soon as we kill testhost the on exit event is triggered, but vstest.console does not know that there is something killing the testhost on purpose, so it just reports a crash, and then blame data collector sends a message saying it killed testhost.


[DOC] How to setup and start working with VS Code on Nebari

The current docs need to be expanded and migrated over to Nebari.
notion

Blocked by https://github.com/Quansight/qhub/issues/1350

More fixes to VSCode were merged yesterday. This is now unblocked.


⚠ Bofrost.at has degraded performance

In 331bb27, Bofrost.at (https://www.bofrost.at) experienced degraded performance:

HTTP code: 200
Response time: 1267 ms

Resolved: Bofrost.at performance has improved in ec2aae1 after 19 minutes.


small changes but huge diff

Output of restic version
restic 0.9.5 compiled with go1.12.4 on linux/amd64
How did you run restic exactly?
MYSQLDUMP_ARGS="--skip-dump-date --single-transaction --complete-insert --add-drop-table --quick --quote-names --triggers --routines --events"

$ mysqldump -u $DB_USER -p$DB_PASS $MYSQLDUMP_ARGS $db | sed 's$VALUES ($VALUES\n($g' | sed 's$),($),\n($g' | restic -r $RESTIC_REPO backup --stdin --stdin-filename db.sql
repository 1f1943b9 opened successfully, password is correct
created new cache in /root/.cache/restic

Files:           1 new,     0 changed,     0 unmodified
Dirs:            0 new,     0 changed,     0 unmodified
Added to the repo: 493.713 MiB

$ mysqldump -u $DB_USER -p$DB_PASS $MYSQLDUMP_ARGS $db | sed 's$VALUES ($VALUES\n($g' | sed 's$),($),\n($g' | restic -r $RESTIC_REPO backup --stdin --stdin-filename db.sql
repository 1f1943b9 opened successfully, password is correct

Files:           0 new,     1 changed,     0 unmodified
Dirs:            0 new,     0 changed,     0 unmodified
Added to the repo: 54.000 MiB

$ restic -r $RESTIC_REPO snapshots
 snapshots
repository 1f1943b9 opened successfully, password is correct
ID        Time                 Host                     Tags        Paths
-------------------------------------------------------------------------------------------
0b9eb47e  2019-05-28 12:29:40  myhost                               /root/db.sql
74288416  2019-05-28 12:30:08  myhost                               /root/db.sql
-------------------------------------------------------------------------------------------

2 snapshots

$ restic -r $RESTIC_REPO diff 0b9eb47e 74288416

repository 1f1943b9 opened successfully, password is correct
comparing snapshot 0b9eb47e to 74288416:

M    /db.sql

Files:           0 new,     0 removed,     1 changed
Dirs:            0 new,     0 removed
Others:          0 new,     0 removed
Data Blobs:     33 new,    33 removed
Tree Blobs:      0 new,     0 removed
  Added:   53.981 MiB
  Removed: 53.981 MiB

$ restic -r $RESTIC_REPO restore 0b9eb47e  --target /var/tmp/db1
repository 1f1943b9 opened successfully, password is correct
restoring <Snapshot 0b9eb47e of [/root/db.sql] at 2019-05-28 12:29:40.114524008 +0200 CEST by root@myhost> to /var/tmp/db1

$ restic -r $RESTIC_REPO restore 74288416  --target /var/tmp/db2
repository 1f1943b9 opened successfully, password is correct
restoring <Snapshot 74288416 of [/root/db.sql] at 2019-05-28 12:30:08.189910784 +0200 CEST by root@mmyhost> to /var/tmp/db2

$ diff /var/tmp/db1/db.sql /var/tmp/db2/db.sql | wc --bytes
15202

$ diff /var/tmp/db1/db.sql /var/tmp/db2/db.sql | wc --lines
392

"sed 's$VALUES ($VALUES\n($g' | sed 's$),($),\n($g'" - split long INSERT line to multiple lines, it prevents keep whole table in one INSERT line.

What backend/server/service did you use to store the repository?
Expected behavior
Restic diff shoud be ~15KB or something near that.
As we see from comparing 2 sql files, simple diff command shows only 15202 bytes

Actual behavior
Restic diff shows 54MB

Steps to reproduce the behavior
1.init new repo
2.make stdin backup of mysql db
3.make some changes in db
4. make backup again

Do you have any idea what may have caused this?
no
Do you have an idea how to solve the issue?
no
Did restic help you or made you happy in any way?
I really like restic, i already migrate backup of servers files from duplicity to restic and it works awesome.  Thanks!

I have run into this as well, and it has been discussed before.
https://forum.restic.net/t/restic-for-large-backup-db/428/6
It seems to have something to do with restic not being able to find enough similarity between dumps to dedupe them, and the lack of compression on the backed.
As a workaround, I gzip the dumps, which still does the same thing, but it's growing at ~6MB/snapshot instead of ~50MB/snapshot.

Is there any development in this problem/bug? Is it still present?

@JsBergbau Not that I know. Is there anything in particular you are thinking/expecting be done about it?
@Junker One would have to look more deeply into how the data differs between the dumps, and relate that to restic's deduplication. I don't know off the top of my head how mysqldump orders the lines in the file, but perhaps the --order-by-primary to mysqldump can be useful to improve ordering of the lines, hence making it easier for the deduplication in restic to do its thing? Depends on what the default order is of course, and I don't have anything to check that with here right now. Also, I think there's some comments and dates that differ between the dumps, might want to turn those off with the various other options to mysqldump.

@rawtaz:
I'm worried that the dedup machanism isn't always working well with other files, too.
Let my shortly explain, perhaps I'm wrong how restic works. As far as I understood https://restic.net/blog/2015-09-12/restic-foundation1-cdc restic using some kind of rolling checksum detect duplicates.
What I've done:
I've backep up a moodle database about 700 MB in size. I just visited a few pages, causing moodle to write some logdata to the DB. Then I've dumped again.
Originaldump is 725,302 KB, second dum 725,303 KB.
I've added first dump to the repository. Then I replaced the content of first dump with the content of the second dump (so filename was the same). After that restic reportet
Files:           0 new,     1 changed,     0 unmodified
Dirs:            0 new,     1 changed,     0 unmodified
Added to the repo: 23.623 MiB

Thats quite a lot added.
See Notepad++ Compareplugin Screenshot. Very few changed

diff dump1 dump2 > diff.txt gives a filsize of 4,849 KB So the question is whats going on that restic rolling checksum performs quite bad in that MYSQL scenario?

@JsBergbau
Restic's chunking algorithm aims for 1MB of blob size.
Changes made to the file, however small they are, as long as they're spread out in N spatially distinct places (i.e. at least 1MB away from each other), then restic will have to create at least ~N MB of new blobs.

Ok thanks for your explanatin. Then everything is working as expected. Thought it might be a hidden bug.

I'm closing this as the larger than expected backup size is basically a "works as designed" as restic is built around block based deduplication. It could, however, be possible to reduce the size of the backup by using a smaller chunk size, which is discussed in #1071. (Compression in restic would of course help too).


change behavior when choosing « non » at the last question

Currently, when clicking on « non » at the last question, it remove one point but the ending screen is the same than when you click on « oui ».
I think that it would be nice to have another end screen when clicking on « non ».

Thank you for your suggestion, we'll think about that...


Enable all named trilinos packages by default

The ExaSMR ECP app requires
+amesos +amesos2 +anasazi +aztec +belos +ifpack +teuchos
gotype=long_long +epetra +epetraext +kokkos +ifpack2 +intrepid +ml
+sacado +shards +tpetra +stratimikos +hdf5 +mpi

when linking against an externally installed trilinos.  Not all Trilinos packages are enabled by default on Spack, and we might soon be disabling even more of them by default. Since E4S is usually distributed as a binary package, prefer to provide all packages that clients might need. (The alternative is that apps see "Trilinos" support but end up having to compile their own version because of a missing package.)
We might  have to iterate on this as building more packages increases the chance of incompatibilities with a particular  platform.

@eugeneswalker Working on a patch to teko so that it concretizes correctly with gotype=long. In the meantime, can I also update this PR so that we have only a single variant of trilinos, with all the available packages enabled? There should be no advantage to having separate installs of trilinos with complementary options, and I'd like to change the spack trilinos package so that it has a "minimal" install by default, and E4S will have a "complete" install. Having three separate trilinos versions that are essentially compatible (but some just missing features) is likely to confuse users.

@eugeneswalker Working on a patch to teko so that it concretizes correctly with gotype=long. In the meantime, can I also update this PR so that we have only a single variant of trilinos, with all the available packages enabled?

Of course, please do. Thank you for doing this.

Thank you for working on this!

Thanks for testing and merging!


Hang problem.

Hey, I'm trying to execute simple query inside iex, but it hangs.
This is my config:
config :moebius,
  connection: [
    hostname: "localhost",
    database: "database_dev",
    pool_mod: DBConnection.Poolboy
  ],
  scripts: "priv/queries"

Supervision:
  def start(_type, _args) do
    import Supervisor.Spec, warn: false

    # Define workers and child supervisors to be supervised
    children = [
      supervisor(Repo, []),
      worker(Moebius.Db, [Moebius.get_connection])
    ] ++ cowboy_worker

    opts = [strategy: :one_for_one, name: Taped.Supervisor]
    Supervisor.start_link(children, opts)
  end

and query:
$ iex -S mix

iex(1)> import Moebius.DocumentQuery
iex(2)> result = db(:videos) |> Moebius.Db.first

# and iex hangs

Found a problem, I need to use 'import Moebius.Query`. Now works fine.


TIM-88 feat:Desktop Layout

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#30  👈
#29
main

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

Join @tamrivera05 and the rest of your teammates on  Graphite

Merge activity

May 7, 3:25 PM EDT: Graphite rebased this pull request after merging its parent, because this pull request is set to merge when ready.


Nested Organizational Units may not be specified.

AWS supports Organizational Units to a depth of 5.  Organizational Units may be specified as the target for deployment of SCPs, but only at the level directly beneath the root of an Organization.
A delimiter character is mentioned in one test file, but the feature is not implemented.

#20 PR written to implement feature.

Thanks for reaching out to us. We have added this to our backlog.

Is there any estimate on when this feature would be implemented?

Is there any estimate on when this feature would be implemented?

Because Control Tower does not support nested OU's, adding this feature could cause some confusion.

Now that Control Tower officially supports nested OUs, how long until this framework supports it?
https://aws.amazon.com/about-aws/whats-new/2021/11/aws-control-tower-supports-nested-organizational-units/

Now that Control Tower officially supports nested OUs, how long until this framework supports it?
https://aws.amazon.com/about-aws/whats-new/2021/11/aws-control-tower-supports-nested-organizational-units/

yeah, many are eager to deploy nested OU in Control Tower but cannot proceed until this feature is added in the solution.

This feature has been released.


[SEI-5665]: ADDED PRECALCULATED REPORTS TOPIC

Harness Developer Pull Request
Added the topic on precalculated reports.
What Type of PR is This?

[ ] Issue
[x] Feature
[ ] Maintenance/Chore

If tied to an Issue, list the Issue(s) here:

Issue(s)

House Keeping
Some items to keep track of. Screen shots of changes are optional but would help the maintainers review quicker.

[x] Tested Locally
[ ] Optional Screenshot.

Please check the Execution Link of the Pipeline for the Website Draft URL. This is located in the Preview Step behind the Harness VPN and also is available in #hdh_alerts. E.g Website Draft URL: https://unique-id--harness-developer.netlify.app. Current Draft URL is: https://65d275e45624ed7cdc612072--harness-developer.netlify.app


Crash with reactor control

Sometimes when I open the reactor control the client crashs.
http://pastebin.com/JyHFiifk

Strange. Let me know if you can discover any reproduction steps. However, the stacktrace is pure vanilla, so I doubt this is BR.

Ticking memory connection indicates a  problem with your ram, for example that you haven't allocated enough ram.

I guess ram is no problem.
allocated ram: 40%
latest log: http://pastebin.com/PMSXkJek
it never happens with empty hand.
held items while crashing: electromagnet, energy cell

The second part of your latest log tells that the game tried to place the block that you have in your hand and in parallel it opens the GUI which causes a network packet problem.

Which mod(s) are the electromagnet and energy cell items from?

If they are the ones I am thinking off, then they are from EnderIO.

the magnet is from eio, energy cell from TE

New realization: It happens every time I open the control while holding an TC pickaxe.
right next to the pickaxe is a TC shovel (I mention it because of the right click feature of TC Tools):
Crashlog and latest log didnt change.

TC = Thaumcraft? This sounds like the tools might not be handling containerless inventories properly, but I'll try to take a look when I get a chance.

I'd assume TC = Tinkers' Construct

Of course

I have the same issue while holding the Resonant Energy cell from Thermal Expansion... know a fix?

Having the same problem while holding a TiCo tool

I have the same crash while holding an atomic disassembler from Mekanism.


Add automoderator

Implements an auto-moderation function to Chiya.
Tasks TBD:

[x] Implement the links filter
[x] Migrate the /censor list pagination to buttons. Moved to a separate branch.
[x] Implement automodding only selected categories.
[x] Implement excluding users/roles from automod, and re-including them.
[x] Implement disabling automod entries and re-enabling them later, when required.
[x] Implement searching for automod terms, rather than listing them and paginating through.
[x] Rewrite the entire automod logic to not read the DB every single time a message comes through.
[ ] Rewrite DB cache system to not use a hacky global variable

Currently supports:

exact
links
substring
regex
fuzzy (by using fuzzywuzzy, will look into whether python-Levensthein is really necessary)

Base features of automod is complete.

The cacheing system needs to be re-written for improving efficiency.

Closing in favor of #210


Rewrite interrupts to use x86-interrupt ABI

Now that the Rust compiler understands extern "x86-interrupt" as a calling convention, we don't need to use naked functions (and the ugly macro) to write interrupts on x86. This allows more of our interrupt-handling code to be cross-platform between 32- and 64-bit x86 systems, which is nice. This CC may also be slightly faster than naked functions in some cases.
This PR also includes some minor refactoring to the IDT type and other parts of the interrupt handling subsystem.
Closes #78.

now that i've fixed the CI build (which I should have probably done in another branch but I am lazy and stupid) this can be merged.


Fix #1613 - when marking notification as read, use that in useInfinit…

…eNotificationsScroll

@angielt assigning you to review this one since you worked on notifications


Did you get a chance to look at some similar papers?

During my PhD, I have tried to solve the same issue of using NMF based methods for source apportionment. Please check the papers out:

Main article titled "Generalised non-negative matrix factorisation for air pollution source apportionment" available at   https://doi.org/10.1016/j.scitotenv.2022.156294
Software article titled "pyGNMF: A Python library for implementation of generalised non-negative matrix factorisation method" available at https://doi.org/10.1016/j.softx.2022.101257

GNMF method does not make any assumption about the structure of the uncertainty matrix and can also be a dense matrix.
Feel free to look at the mentioned papers. I have spent quite some time optimising the code so that it runs as fast as possible. However, I was not able complete the error estimation part in the pyGNMF method and thus was published without it.

Thank you for these resources @niravlekinwala. We will take a look at the GNMF algorithm that you developed in your article, as well as the pyGNMF package that you published.


Custom CSS?

I would like to apply custom CSS in Quark. Is there a way to do it?  The existing custom.css file seems to have no effect.

Hi @ThosG , I just tested adding the following to the default custom.css file in Quark and it seemed to work-ok, maybe a Browser refresh issue?
body a {
    color: #CC0000;
}

Let me know if that works for you too.
Paul

@paulhibbitts

maybe a Browser refresh issue?
Doh. Thanks Paul. So simple.


Start Godot Project Manager center of the screen.

Godot version:
Godot 3.2.2 64-bit (GDScript) - Btw. is there a 32-bit PC on the globe? I doubt it. Godot should only be available in 64-bit (Windows / Linux, like Mac) But anyway... 🙂
OS/device including version:
Window 10 64-bit (Version 1909)
Issue description:
The window of Godot Proejct Manager is not centered of the screen. It's a bit annoying. Nothing critical but would be great if this gonna be polished. ❤
In Godot the project launcher (play, F5) is also not centred until the hdpi flag is set in the project settings. Maybe this is a similar issue. But I rather think that this is just a spawned window of the console application without window position property set. I'm not experienced with C++, but in C# there are options for a window form to spawn. A property for the start position of the window. It should start at the middle / center of the screen.
Steps to reproduce:

Use a 4k resolution (3840 x 2160 px, OS UI scale 200%)
Start Godot. (In my case with hidden console, but it does not matter.)
See that the window is not centered. It's aligned at the right bottom area of the screen.

Looks like the computation for window position (top left, so center minus half size) doesn't take into account the upscaling of the window.

Yes that's also plausible. Does the SDK have an option for centered window? Or is this computed manually? I would prefer the auto solution of the window SDK if possible and work correctly. If not is the scale value known? Can this be a part of the calculation?

Duplicate of https://github.com/godotengine/godot/issues/13017.


.d.ts files are missing for the new Date lab components

The files are needed for simple usage in TypeScript

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
No *.d.ts files are present in lab/DateRangePicker
Expected Behavior 🤔
Generated *.d.ts files in lab/DateRangePicker
Steps to Reproduce 🕹
Steps:

Install the latest version (alpha.16)
check node_modules/

Thanks for the report. This will be fixed in the next release.
Duplicate of #23559

Thanks!


TradingAPI check_order() no longer returns free_space_new and the 3 transaction_XXX properties

The create order docu shows that the response on check_order() has 6 parameters.
I did see all of them in the past, but recently it only returns:

confirmation_id
response_datetime

This behaviour is observed on both NASDAQ and Euronext Amsterdam.

Hello @funnel20,
you are right, I think they have changed their API.
The check_order response looks like this now :
{
    "confirmationId": "MOCK_CONFIRMATION_ID",
    "freeSpaceNew": 1.2345,
    "showExAnteReportLink": true,
    "transactionFee": 1.2
}

A new release let you access these new parameters.

Hi @Chavithra,
Thanks, I'll test it tomorrow. I see you have it assigned to me. Do you want me to update the docu?

Hi @Chavithra, Thanks, I'll test it tomorrow. I see you have it assigned to me. Do you want me to update the docu?

The assignment thing as likely no meaning except: waiting for feedback.
Your contribution is always welcome.
Thanks for letting me know about this bug.

@Chavithra I'd like to test the update, but pip doesn't have version 2.0.14:
ERROR: Could not find a version that satisfies the requirement degiro-connector==2.0.14 (from versions: 0.0.4, 0.0.6, 0.0.7, 0.0.8, 0.0.9, 0.0.11, 0.1.0, 0.1.1, 0.1.3, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6, 1.0.7, 1.0.8, 1.0.9, 1.0.10, 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.0.9, 2.0.10, 2.0.11, 2.0.12, 2.0.13) ERROR: No matching distribution found for degiro-connector==2.0.14
Can you please release it?

@Chavithra I'd like to test the update, but pip doesn't have version 2.0.14:
ERROR: Could not find a version that satisfies the requirement degiro-connector==2.0.14 (from versions: 0.0.4, 0.0.6, 0.0.7, 0.0.8, 0.0.9, 0.0.11, 0.1.0, 0.1.1, 0.1.3, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.0.4, 1.0.5, 1.0.6, 1.0.7, 1.0.8, 1.0.9, 1.0.10, 2.0.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.5, 2.0.6, 2.0.7, 2.0.8, 2.0.9, 2.0.10, 2.0.11, 2.0.12, 2.0.13) ERROR: No matching distribution found for degiro-connector==2.0.14
Can you please release it?

fixed

Cool. I'm working on improved docu for Chapter 4 (Orders). I'll send you a PR once ready for review.

I've tested confirm_order(), but only see 3 of these parameters:
confirmation_id: "e2a1da94-aaaa-4f24-85c0-6c9320804534"
response_datetime {
  seconds:<PHONE_NUMBER>
  nanos: 569196000
}
transactionFee: 2.5
showExAnteReportLink: true

freeSpaceNew is missing.
I also notice that these parameter names have camel case syntax, instead of the Pythonian underscores.
Regarding the docu, do you have any idea what showExAnteReportLink means?

Cool. I'm working on improved docu for Chapter 4 (Orders). I'll send you a PR once ready for review.

Update is pending as PR https://github.com/Chavithra/degiro-connector/pull/59

Apparently the buy price is not returned when an order is confirmed. Is there an easy way to get the buy price with the order id?

Apparently the buy price is not returned when an order is confirmed. Is there an easy way to get the buy price with the order id?

When the order is confirmed, it's not executed by the exchange, so the price is not known. You can retrieve the execution price from the transaction history. Unfortunately that doesn't report the order_id, so you should link the order to the matching transaction. For an example, see: https://github.com/Chavithra/degiro-connector/issues/41

@coveritytest As indicated in the order docu, you should use parameter stop_price instead of price for Order.OrderType.STOP_LOSS.

Thanks for your help, I'm sorry, I deleted all my comments, so can you. Then it's clean again.

@Chavithra Did you see my feedback?
And can you update please?

Hello @funnel20 I indeed didn’t see your feedback.
Thank you for this reminder.
Noted this point will work on it the following days.

@Chavithra Awesome. I already wrote the docu with the Pythonian names.

@Chavithra I've tried to solve this for you, but I've no clue how. Especially since I have no idea where the file trade.proto is stored on my local machine.
Could you please have a look into it?

Hey @funnel20,
REPORT EX-ANTE
When you pass an order in the website you probably have a link called like this :

Download the Costs and Charges Report

I think this is the report ex-ante, to know the cost before confirming the order.
FREE SPACE NEW
I can't reproduce this issue :

missing free_space_new in the response of check_order function.

Do you still have this issue ? if so with which product ?
Thanks

Hi @Chavithra . I'm using version 2.0.15 of the-connector.
I have placed orders for a Dutch stock (ABN-AMRO) and Apple (APPL) on Nasdaq.
My code for AAPL:
order = Order(
    action=Order.Action.BUY,
    order_type=Order.OrderType.LIMIT,
    price=162.4,
    product_id=331868,
    size=1,
    time_type=Order.TimeType.GOOD_TILL_DAY,
)

# FETCH CHECKING_RESPONSE
checking_response = trading_api.check_order(order=order)
logging.info(checking_response)

This prints:
2022-02-06T20:11:23.987 INFO - confirmation_id: "20033f1e-XXXXXXX"
response_datetime {
  seconds:<PHONE_NUMBER>
  nanos: 987875000
}
transactionFee: 0.5
showExAnteReportLink: true

Just tried this same code and can't reproduce the issue.
1/ Do you have the Free new space when you try the same operation on the websit ?
2/ Would it be possible to try with version 2.0.16 ?

This is what I get in check order:

With 2.0.16 I do see the name changes of the other 2 parameters, but still no free_space_new:

INFO - confirmation_id: "63e60fc3-921c-4976-ba14-7451c1928308"
response_datetime {
  seconds:<PHONE_NUMBER>
  nanos: 82671000
}
transaction_fee: 2.5
show_ex_ante_report_link: true

However, please note that the original name was transaction_fees (plural, see last "s") instead of transaction_fee.

@Chavithra Are you sure that you don't have an old version of the connector somewhere on your machine?
What is your raw output?

The free_space_new seems to work in the current version.
Closing this issue for now.
Thanks


PP-6782 Change controllers extension to .controller.js

WHAT

We have updated extension for most of controllers to end with .controller.js. This changes extension for rest of the controllers

Superseded by https://github.com/alphagov/pay-selfservice/pull/2165


Cursor::getPixelRect calls deprecated TextEditor::pixelRectForScreenRange

Prerequisites

[x] Put an X between the brackets on this line if you have done all of the following:

Reproduced the problem in Safe Mode: http://flight-manual.atom.io/hacking-atom/sections/debugging/#using-safe-mode
Followed all applicable steps in the debugging guide: http://flight-manual.atom.io/hacking-atom/sections/debugging/
Checked the FAQs on the message board for common solutions: https://discuss.atom.io/c/faq
Checked that your issue isn't already filed: https://github.com/issues?utf8=✓&q=is%3Aissue+user%3Aatom
Checked that there is not already an Atom package that provides the described functionality: https://atom.io/packages

Description
Cursor::getPixelRect calls deprecated TextEditor::pixelRectForScreenRange. Causing a deprecation warning in latest Atom Beta 1.13.0-beta9.
This is now a view method. Call TextEditorElement::pixelRectForScreenRange instead.
Steps to Reproduce
Use the color-picker plugin on latest beta, check deprecation warnings.  Throws this call stack in the warning:
TextEditor.pixelRectForScreenRange - /Applications/Atom Beta.app/Contents/Resources/app.asar/src/text-editor.js:3559:12
Cursor.getPixelRect - /Applications/Atom Beta.app/Contents/Resources/app.asar/src/cursor.js:675:26

I'm sure this happens in other plugins, this just happens to be the one that shows it for me.
Versions
Atom    : 1.13.0-beta9
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0
OS X El Capitan 10.11.6 (15G1212)

getPixelRect is a private method and shouldn't be used in packages (hence why it's not documented anywhere).
Your issue is still valid though, we shouldn't be using pixelRectForScreenRange if it's deprecated.

I think we should simply remove that method. It doesn't look like it's used anywhere.

Before you go ahead and do that, is there an alternative?

Yeah, TextEditorElement::pixelPositionForScreenPosition. To obtain a screen position for a cursor call, Cursor::getScreenPosition.

Sweet, thanks! I'll push this in an update ASAP.

@maxbrunsfeld I've pushed the update. Not using Cursor.getPixelRect in color-picker v2.2.4. :)


Refactor input poll

Just to refactor slow code.
On my lazy tests it works x2-3 faster (0.4ms+ -> 0.1ms). Will be noticeable on the 1 ms polling interval (the minimum for JS intervals is 4 ms as described in HTML5 specs).
Needs testing.

How did you come with the number :-s ? Can you explain a bit about the reason it will be an improvement? (what is the drawback of old implementation, how it is solved with the new way)

First of all, the current polling algorithm with setInterval is quite bad. Due to inherited problems with it (can be blocked and interval is not guaranteed, heap trash). No idea yet what to use instead (requestAnimationFrame, maybe).
Second, this refactor is just for readability and removing bad code.
I compared old and new exec time before pushing into the RTC. With new code the mean exec time was around 0.1ms, old code -- up to 0.5ms. (:
This code is ugly and slow, hope, you understand why. It's noticeable even with 12 elements in array (sic!). There is shouldn't be 2x-3x difference in exec time.
// pack keys state
let bits = '';
KEY_BITS.slice().reverse().forEach(elem => {
  bits += keyState[elem] ? 1 : 0;
});
let data = parseInt(bits, 2);

Thank you for the very detailed explanation. I got it now. Your refactor on that part is more performant (but I still not sure why 12 elements array is noticeable :-?). As it is late here, I will do a quick check tomorrow to see if it works logicalwise.  :+1:

I was thinking about your poll algorithm and found a pretty straightforward bug:
a key press state can be reset only with the corresponding keyup event but you can easily miss it. As example, if you lose browser focus while pressing any keys they won't reset on focus return, only when you press again the same keys.
(on the gif it hard to tell because of encoding artefacts, but I'm holding left key before alt-tabbing from the window and going back where it still active)

I'm aware of this key stuck issue when playing. It is indeed troublesome.
I think on backend we can keep the last state update time and reset everything when the last state update time is > 1second.

Btw, I'm testing your change now :D


[Overview] UX issues in the CWA

Description
Feel free to use this issue to report smaller UX and UI issues from people on social media. UX issues are any problems that users have with understanding the usage of functionality inside the CWA. Examples for this are:

Users being unable to find an existing functionality (even though it exists in the app)
Users having issues navigating the app
Common mistakes/incorrect usage of a feature
Misunderstandings about the inner workings of a feature
Confusion about the relation the other Corona apps (luca, CovPass, CovPassCheck)

In short: Anything that deviates from the intended usage of the app.
Motivation
Usually, these problems are not necessarily the users' and can be improved by us. The more input we get from real users of the app, the better we can judge where improvements should be made.

Corona-Warn-App Open Source Team

Thanks for this issue!
Disclaimer: I just forward here what Twitter users told me, this does not have to be my own opinion!

Don't move functions inside of the app w/o further notice. Users where confused when this was done with the contact journal, now it was done again with the vaccination certificates.
There should be a big red arrow pointing to where the feature now is.
The legal text that was shown after a tap on the "Certificates" tab in version 2.4, even if the user had already registered vaccination certificates, were confusing for many users. They thought the certificates were deleted.
Stop changing the UI from release to release, with each new version since 2.3, the user had to adapt their usage to the new UI.
First the got used to the certificate on the home screen, then the certificate was moved to it's own tab (showing some "Valid to" date nobody understands or concerns) and then, with version 2.5, they are welcomed with big fat QR-Codes and they wonder where they can find the other infos. There were literally users out there who needed an explanation that they now have to tap on the QR-code.
Simplify the texts in the app and make them as short and as understandable as possible.
With each new feature, users of the CWA are normally welcomed with an info page with much texts, only one illustrations and many are unmotivated to use the new feature in this way. And the users that don't just quit the app, will probably not read the texts and just press the "Continue" button.
Related to CovPass, see this Tweet, where a user says that he thinks that CWA should also display a green ✅, similar to CovPass.