GCE kube-lego-gce service created without selector

As far as I understood, service that should be created should has selector
selector:    app: kube-lego
but instead I have empty selector. That's why ingress saying it is unhealthy, that's why can pass reachability test(fail with 502).
Ingress showing my routes correctly and point to proper service, but as soon as service not point to any pod, it is unhealthy, if I understand correctly. Do you know what can be the problem?

@pavel-kurnosov could you share the service created by kube-lego?
$ kubectl get svc kube-lego -n your-namespace -o yaml

@gianrubio Yes, I dont have kube-lego, instead I have kube-lego-gce
kubectl get svc kube-lego-gce -n aispot -o yaml
apiVersion: v1
kind: Service
metadata:
  annotations:
    kubernetes.io/kube-lego-managed: "true"
  creationTimestamp: 2017-04-08T23:23:48Z
  name: kube-lego-gce
  namespace: aispot
  resourceVersion: "1161519"
  selfLink: /api/v1/namespaces/aispot/services/kube-lego-gce
  uid: 6b3b87b4-1cb2-11e7-bcb4-42010af00040
spec:
  clusterIP: <IP_ADDRESS>
  ports:
  - nodePort: 30957
    port: 8080
    protocol: TCP
    targetPort: 8080
  sessionAffinity: None
  type: NodePort
status:
  loadBalancer: {}

It's weird, the selector is hardcoded so it' ll be always created.
What happens if you delete this service and restart kube-lego (it'll recreate the service)?
What version are you using?

First, I started installing using helm.
After that I remove everything and did manually. First using last version, then tried use canary build.
Yes, when I remove service and restrart kube-lego it is recreating same service. Problem that when I udpate it manually, it is replaced after some time again with wrong version ((

Sorry, I just realise now you're using GCE, so the svc is created with empty selector
Maybe this issue can help you. If not, please enable log level debug LEGO_LOG_LEVEL=debug and share kube-lego logs.

Yes, I seen this issue, I added already /* to root.
This is logs:
2017-04-10T10:24:48.214082666Z time="2017-04-10T10:24:48Z" level=info msg="kube-lego 0.1.4-dev-aa96e546 starting" context=kubelego
2017-04-10T10:24:48.249273174Z time="2017-04-10T10:24:48Z" level=info msg="connected to kubernetes api v1.6.0" context=kubelego
2017-04-10T10:24:48.250140182Z time="2017-04-10T10:24:48Z" level=info msg="server listening on http://:8080/" context=acme
2017-04-10T10:24:48.373518556Z time="2017-04-10T10:24:48Z" level=info msg="disable provider no TLS hosts found" context=provider provider=nginx
2017-04-10T10:24:48.373658478Z time="2017-04-10T10:24:48Z" level=info msg="process certificate requests for ingresses" context=kubelego
2017-04-10T10:24:48.376671453Z time="2017-04-10T10:24:48Z" level=info msg="creating new secret" context=secret name=api-dev-secret namespace=aispot
2017-04-10T10:24:48.376804533Z time="2017-04-10T10:24:48Z" level=info msg="no cert associated with ingress" context="ingress_tls" name=routes-ing namespace=aispot
2017-04-10T10:24:48.376903030Z time="2017-04-10T10:24:48Z" level=info msg="requesting certificate for mydomain.no" context="ingress_tls" name=routes-ing namespace=aispot
2017-04-10T10:25:58.903316029Z time="2017-04-10T10:25:58Z" level=warning msg="authorization failed after 1m0s: reachability test failed: wrong status code '502'" context=acme domain=mydomain.no
2017-04-10T10:25:58.903576316Z time="2017-04-10T10:25:58Z" level=error msg="Error while processing certificate requests: no domain could be authorized successfully" context=kubelego
2017-04-10T10:25:59.023897111Z time="2017-04-10T10:25:59Z" level=info msg="disable provider no TLS hosts found" context=provider provider=nginx
2017-04-10T10:25:59.025193047Z time="2017-04-10T10:25:59Z" level=info msg="process certificate requests for ingresses" context=kubelego
2017-04-10T10:25:59.029105897Z time="2017-04-10T10:25:59Z" level=info msg="creating new secret" context=secret name=api-dev-secret namespace=aispot
2017-04-10T10:25:59.029261295Z time="2017-04-10T10:25:59Z" level=info msg="no cert associated with ingress" context="ingress_tls" name=routes-ing namespace=aispot
2017-04-10T10:25:59.029387719Z time="2017-04-10T10:25:59Z" level=info msg="requesting certificate for mydomain.no" context="ingress_tls" name=routes-ing namespace=aispot
2017-04-10T10:27:09.500504463Z time="2017-04-10T10:27:09Z" level=warning msg="authorization failed after 1m0s: reachability test failed: wrong status code '502'" context=acme domain=mydomain.no
2017-04-10T10:27:09.500702265Z time="2017-04-10T10:27:09Z" level=error msg="Error while processing certificate requests: no domain could be authorized successfully" context=kubelego
2017-04-10T10:27:09.531657749Z time="2017-04-10T10:27:09Z" level=info msg="disable provider no TLS hosts found" context=provider provider=nginx
2017-04-10T10:27:09.531837820Z time="2017-04-10T10:27:09Z" level=info msg="process certificate requests for ingresses" context=kubelego
2017-04-10T10:27:09.534477379Z time="2017-04-10T10:27:09Z" level=info msg="creating new secret" context=secret name=api-dev-secret namespace=aispot
2017-04-10T10:27:09.534608592Z time="2017-04-10T10:27:09Z" level=info msg="no cert associated with ingress" context="ingress_tls" name=routes-ing namespace=aispot
2017-04-10T10:27:09.534729052Z time="2017-04-10T10:27:09Z" level=info msg="requesting certificate for mydomainno" context="ingress_tls" name=routes-ing namespace=aispot
2017-04-10T10:28:37.288533812Z time="2017-04-10T10:28:37Z" level=warning msg="authorization failed after 1m0s: reachability test failed: wrong status code '502'" context=acme domain=mydomain.no
2017-04-10T10:28:37.288796524Z time="2017-04-10T10:28:37Z" level=error msg="Error while processing certificate requests: no domain could be authorized successfully" context=kubelego
2017-04-10T10:28:37.318681250Z time="2017-04-10T10:28:37Z" level=info msg="disable provider no TLS hosts found" context=provider provider=nginx
2017-04-10T10:28:37.318863316Z time="2017-04-10T10:28:37Z" level=info msg="process certificate requests for ingresses" context=kubelego
2017-04-10T10:28:37.321200281Z time="2017-04-10T10:28:37Z" level=info msg="creating new secret" context=secret name=api-dev-secret namespace=aispot
2017-04-10T10:28:37.321298796Z time="2017-04-10T10:28:37Z" level=info msg="no cert associated with ingress" context="ingress_tls" name=routes-ing namespace=aispot
2017-04-10T10:28:37.321393129Z time="2017-04-10T10:28:37Z" level=info msg="requesting certificate for mydomain.no" context="ingress_tls" name=routes-ing namespace=aispot

@pavel-kurnosov this log are not verbose.. Are you using rbac in k8s 1.6?

No, I don't. As far as I see it is still in beta and require manually specify it, which I didn't.

@pavel-kurnosov during this week I'll bootstrap a gce k8s 1.6.0 so I'll figure it out what happens.
The gce provider was not detected by kube-lego, most of the lines has provider=nginx it should be provider=gce

Okay I see, can I using properties to force kube-lego to use gce?

Okay, I found a way to make it work for now:
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: kube-lego
  namespace: kube-lego
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: kube-lego
    spec:
      containers:
      - name: kube-lego
        image: jetstack/kube-lego:canary
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
        env:
        - name: LEGO_EMAIL
          valueFrom:
            configMapKeyRef:
              name: kube-lego
              key: lego.email
        - name: LEGO_LOG_LEVEL
          valueFrom:
            configMapKeyRef:
              name: kube-lego
              key: lego.log_level
        - name: LEGO_DEFAULT_INGRESS_CLASS
          valueFrom:
            configMapKeyRef:
              name: kube-lego
              key: lego.default_class
        - name: LEGO_SUPPORTED_INGRESS_CLASS
          valueFrom:
            configMapKeyRef:
              name: kube-lego
              key: lego.default_support
        - name: LEGO_URL
          valueFrom:
            configMapKeyRef:
              name: kube-lego
              key: lego.url
        - name: LEGO_NAMESPACE
          valueFrom:
            configMapKeyRef:
              name: kube-lego
              key: lego.namespace
        - name: LEGO_POD_IP
          valueFrom:
            fieldRef:
              fieldPath: status.podIP
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          timeoutSeconds: 1

And configmap:
apiVersion: v1
metadata:
  name: kube-lego
  namespace: kube-lego
data:
  # modify this to specify your address
  lego.email<EMAIL_ADDRESS>
  # configre letencrypt's staging api, for prod https://acme-v01.api.letsencrypt.org/directory
  lego.url: "https://acme-staging.api.letsencrypt.org/directory"

  # specify class explicitly
  lego.default_class: "gce"

  # specify support class explicitly
  lego.default_support: "gce"

  lego.log_level: "debug"

 # specify  explicitly namespace
  lego.namespace: "myNamespace"
kind: ConfigMap

After specifying all this config and restar, in 5 minutes when all updates was propagated, I got my first certificate and then all was fine.
Hope, it is going to help someone. And you @gianrubio to debug  :)

Okay, today after update ingress(new host), kube-lego didn't manage to start properly:
2017-04-11T21:24:29.677958774Z time="2017-04-11T21:24:29Z" level=debug msg="setting up svc endpoint" context=provider namespace=aispot pod_ip=<IP_ADDRESS> provider=gce
2017-04-11T21:24:29.716822971Z time="2017-04-11T21:24:29Z" level=debug msg=reset context=provider provider=nginx
2017-04-11T21:24:29.716954340Z time="2017-04-11T21:24:29Z" level=debug msg=finalize context=provider provider=nginx
2017-04-11T21:24:29.722592832Z time="2017-04-11T21:24:29Z" level=info msg="disable provider no TLS hosts found" context=provider provider=nginx
2017-04-11T21:24:29.722689144Z time="2017-04-11T21:24:29Z" level=info msg="process certificate requests for ingresses" context=kubelego
2017-04-11T21:24:29.726964968Z time="2017-04-11T21:24:29Z" level=info msg="cert does not cover all domains" context="ingress_tls" domains=[domain domain1] name=routes-ing namespace=aispot
2017-04-11T21:24:29.727076126Z time="2017-04-11T21:24:29Z" level=info msg="requesting certificate for domain,domain1" context="ingress_tls" name=routes-ing namespace=aispot
2017-04-11T21:24:29.970108028Z time="2017-04-11T21:24:29Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:29.970879320Z time="2017-04-11T21:24:29Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:29.988963579Z time="2017-04-11T21:24:29Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:24:29.990280847Z time="2017-04-11T21:24:29Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:30.456037337Z time="2017-04-11T21:24:30Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:30.489155406Z time="2017-04-11T21:24:30Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:24:30.657360007Z time="2017-04-11T21:24:30Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:30.667848864Z time="2017-04-11T21:24:30Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:31.349074046Z time="2017-04-11T21:24:31Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:31.359231891Z time="2017-04-11T21:24:31Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:31.474874665Z time="2017-04-11T21:24:31Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:31.484321840Z time="2017-04-11T21:24:31Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:24:32.010579574Z time="2017-04-11T21:24:32Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:32.021152806Z time="2017-04-11T21:24:32Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:32.886234324Z time="2017-04-11T21:24:32Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:32.895511425Z time="2017-04-11T21:24:32Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:33.026831130Z time="2017-04-11T21:24:33Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:33.037078202Z time="2017-04-11T21:24:33Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:24:34.724697491Z time="2017-04-11T21:24:34Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:34.735611358Z time="2017-04-11T21:24:34Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:34.962259067Z time="2017-04-11T21:24:34Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:34.977988428Z time="2017-04-11T21:24:34Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:24:36.773031143Z time="2017-04-11T21:24:36Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:36.782294844Z time="2017-04-11T21:24:36Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:24:37.694468243Z time="2017-04-11T21:24:37Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:37.705378491Z time="2017-04-11T21:24:37Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:38.946813694Z time="2017-04-11T21:24:38Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:38.976756629Z time="2017-04-11T21:24:38Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:24:42.957553115Z time="2017-04-11T21:24:42Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:42.974799906Z time="2017-04-11T21:24:42Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:47.283721915Z time="2017-04-11T21:24:47Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:47.301028974Z time="2017-04-11T21:24:47Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:24:47.386623540Z time="2017-04-11T21:24:47Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:47.398377298Z time="2017-04-11T21:24:47Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:51.750171886Z time="2017-04-11T21:24:51Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:51.761099114Z time="2017-04-11T21:24:51Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:24:57.653118371Z time="2017-04-11T21:24:57Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:24:57.671210390Z time="2017-04-11T21:24:57Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1
2017-04-11T21:24:59.314200868Z time="2017-04-11T21:24:59Z" level=debug msg="testing reachability of http://domain/.well-known/acme-challenge/_selftest" context=acme domain=domain
2017-04-11T21:24:59.332454072Z time="2017-04-11T21:24:59Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain
2017-04-11T21:25:15.555292971Z time="2017-04-11T21:25:15Z" level=debug msg="testing reachability of http://domain1/.well-known/acme-challenge/_selftest" context=acme domain=domain1
2017-04-11T21:25:15.571910352Z time="2017-04-11T21:25:15Z" level=debug msg="error while authorizing: reachability test failed: wrong status code '502'" context=acme domain=domain1

I just added a PR to associate the app: kube-lego selector with the GCE service. This fixed the issue for me.

@simonswine could you explain why kibe-lego creates the service selector empty when provider is GCE?
Does #147 fix this issue?

It is the only way to support kube-lego between namespaces with GCE ingress.
#147 is probably only working if you run kube-lego in the same namespace where you run your app and the ingress object. It is definitely breaking multi namespace support for GCE ingress.
Kube-Lego is managing the endpoints list for the kube-lego-gce service. To debug that behaviour:
kubectl describe svc kube-lego-gce and kubectl get endpoints kube-lego-gce -o yaml should provide more insights what the problem is here. I think the endpoint should be there (setting up svc endpoint in the logs).
Are you running more than one instance of  kube-lego in your cluster?
cf. https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/ (Empty selector)

The namespace question is interesting. I installed kube-lego using the yaml included in the project examples/gce/lego folder, which specifies the kube-lego namespace. I can see that the kube-lego deployment and pod are running in the kube-lego namespace. However the kube-lego-gce service is running in the default namespace. Our application services and ingress are all in the default namespace. We only have one instance of kube-lego running.
kubectl describe svc kube-lego-gce:
Name:			kube-lego-gce
Namespace:		default
Labels:			<none>
Annotations:		kubernetes.io/kube-lego-managed=true
Selector:		app=kube-lego
Type:			NodePort
IP:			<IP_ADDRESS>
Port:			<unset>	8080/TCP
NodePort:		<unset>	31677/TCP
Endpoints:		<none>
Session Affinity:	None
Events:			<none>

kubectl get endpoints kube-lego-gce -o yaml:
apiVersion: v1
kind: Endpoints
metadata:
  creationTimestamp: 2017-04-12T17:04:28Z
  name: kube-lego-gce
  namespace: default
  resourceVersion: "2597926"
  selfLink: /api/v1/namespaces/default/endpoints/kube-lego-gce
  uid: 16ea4244-1fa2-11e7-b4e1-42010a800035
subsets: []

With #147 the issue is corrected for this configuration.

Hey @jessejohnston-isp,
The issue here is that service selectors do not work between namespaces. So if you add a selector to the kube-lego-gce service in the default namespace, it will match no pods, as kube-lego itself runs in the kube-lego namespace.
This is a known caveat with Ingress/services, and as far as I can tell not one they intend to 'fix'. You can see @thockin suggesting a workaround here, which is what kube-lego implements (manually managing Endpoints to point to the service/pod IP in another namespace).
#147 will fix the issue iff the kube-lego pod exists in the same namespace as the Ingress resource you have created, because otherwise, kube-controller-manager will return an empty list of pods when querying for pods in the namespace of your service in order to create the Endpoints resource.
Hope I'm being clear enough here - it's not the easiest to explain! I'd imagine your PR is working for you because kube-lego is still manually creating the Endpoints resource for you, as it's intended to do (regardless of the presence of the selector). If you were to remove this line https://github.com/jessejohnston-isp/kube-lego/blob/039933e9108b6234a7aa1339654f6eb7a8c8ae61/pkg/provider/gce/gce.go#L96 (where the Endpoints resource is manually created), I think you'll find #147 no longer works cross namespace.

Hi @munnerz,
That absolutely makes sense...and in the kubernetes dashboard I see that the kube-lego-gce service still matches no pods.  However, without #147 it did not work at all. We saw an endless stream of 502 errors from kube-lego because /.well-known/acme-challenge/_selftest was not reachable externally. My speculation, like that of @pavel-kurnosov, was that it was because kube-lego-gce was not selecting any pods, and therefore the request to acme could not be routed anywhere. After applying the PR the problem immediately resolved.

Personally, I think this is hack to apply it to any namespace. For me, namespace is separate area and each namespace should not have access to other in any case. I don't mind to have kube-lego in same namespace to make it working, but because of empty selector, now it will not.
Can we as workaround have a property, which will add selector, so we can control it.

@gianrubio Did you have a change to check new version on GCP?

I'm also having the same issue. Using the deployment and config map noted earlier by @pavel-kurnosov I was able to get lego to deploy one cert.  When I added my second service and ingress to GCE the backend was unreachable and thus no cert was obtained.  I'm happy to help debug as I believe the kube-lego solution is more intuitive than the other option available.

Looking here: https://github.com/jetstack/kube-lego/blob/2d228d8a5779e4b231f5c5bc70c7ea8c0de1004a/pkg/provider/gce/gce.go#L90
I see it the gce component calls SetKubeLegoSpec which sets the Selector and then the code at L90 sets the Selector to an empty map.

I'm also facing this problem and investigated. Looks like it have something to do with this issue instead https://github.com/jetstack/kube-lego/issues/68 The no-selector implementation is correct but the problem is that the endpoint is shown as UNHEALTHY.

Same problem here, I couldn't get to it to work. Will try the workaround with #147

Same problem here, with GKE 1.7.8.
I've got kube-lego in one namespace, I managed to deploy one service in another namespace. But when I tried to deploy a second service in a third namespace it keeps on having 502 errors

@jamatute I seem to be having the same problem (the service in the second namespace I create uses the certificate created for the first service - which is issued to a different subdomina). Which "solution" did fix this problem for you, I could not find that out from the #68 issue?

@anselms I manually created a healthcheck to the desired endpoint and attached it to the kube-lego-gce backend.
After a pair of minutes it marks it as healthy and the certificate is issued.
You have to do it manually, so it's more a workaround than a solution

Same issue with my GKE deployment with kube-lego in a separate 'kube-lego' namespace and my service/deployment in another namespace.
Is there any perspective how to resolve this with a proper (and flexible) configuration/without manual workarounds?

Just so you know, I just experienced that issue too, with version 1.6 of kube-lego.


Can't see error text when field in table view cell

First off, thanks for writing and publishing this!
When I add error text to a field, the underline turns red, but I cannot see the error text.  If I use Reveal to look at the views, the text is there, but hidden.
The field is attached to all 4 sides of the content view of the cell, and the cell should grow based on autolayout (height methods return UITableViewAutomaticDimension).
Any thoughts on how to get this to work?  I also tried changing the error padding, but no help.
Thanks

Thanks for raising this issue.
Looks like it's a problem with dynamic height tableview cells. I had a play around with it on the weekend but couldn't get it to work the way it should. I would like to improve the way I'm setting up constraints on the error label, so I'll have a go at that when I get the time over the next few weeks. (I'm moving overseas so I'm a bit busy right now!)
As a workaround in the mean time, instead of returning UITableViewAutomaticDimension from tableView:heightForRowAtIndexPath:, calculate the height of the cell using the textfield's intrinsic content size. This seemed to work ok for me. For example:
- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
        return self.textField.intrinsicContentSize.height;
}


Fixes warnings in inkscape console because namespaces

Title autodescriptive

This is so awesome I'm almost crying. I'll tests it ASAP.
Would you mind checking the template file as well? I use it as an example for newcomers: https://raw.githubusercontent.com/Xaviju/inkscape-open-symbols/master/template.svg
¡GRACIAS!

Isn't it already in the diff?
https://github.com/Xaviju/inkscape-open-symbols/pull/77/commits/88b3d11d95b30cc2a9269f682fdfe4acd7bad261#diff-d67fb6aacbcb7054c1a8616c6520461f

Oh sorry, I didn't see it! I'll test it tomorrow. :D

@Xaviju, completely off-topic, but your comment triggered it, check your LinkedIn.


Chore: Gaia v19

Related PRs:

https://github.com/neutron-org/neutron-integration-tests/pull/334
https://github.com/neutron-org/neutron-docs/pull/226

https://github.com/neutron-org/neutron-tests/actions/runs/10290798573

https://github.com/neutron-org/neutron-tests/actions/runs/10355320703


Fixes individual news article title

fixes #685
I just switched 'page_title' to 'news.title' in the if statement.
This worked as every page(besides the news.html) grabs the overlay title from the url.
May want to look into a better solution down the road.

I think we still want the page_title conditional so just move the news title check above it and use an elseif for page title
Sent from my iPhone

On Dec 15, 2018, at 5:46 PM, Hank Tadeusiak<EMAIL_ADDRESS>wrote:
fixes #685
I just switched 'page_title' to 'news.title' in the if statement.
This worked as every page(besides the news.html) grabs the overlay title from the url.
May want to look into a better solution down the road.
You can view, comment on, or merge this pull request online at:
https://github.com/jonfroehlich/makeabilitylabwebsite/pull/699
Commit Summary
fixes individual news article title, uses article name instead of part of page url
File Changes
M website/templates/snippets/display_short_carousel_snippet.html (4)
Patch Links:
https://github.com/jonfroehlich/makeabilitylabwebsite/pull/699.patch
https://github.com/jonfroehlich/makeabilitylabwebsite/pull/699.diff
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

This should be fixed now.


evaluate "Docker for Mac" as a Dinghy replacement

You have to agree to an NDA to get into the private beta, but I've gleaned plenty of information from public sources:
https://blog.docker.com/2016/03/docker-for-mac-windows-beta/
https://news.ycombinator.com/item?id=11352594
I've been saying for 18 months that Docker should solve the OS X dev problem themselves, so I'm a big fan of this. From what I've read so far it seems pretty close to Dinghy in terms of features.

Mounted volumes are shared from the host using an as-yet-unknown solution that appears to support fsevents. Hopefully its performance is at least close to NFS, if not better.
Claims that it remaps MacOS X UIDs into Linux ones (no more permissions problems), which could mean a couple different things. Hopefully it is aimed at editing code on a mounted volume.
DNS resolving, apparently with routing the docker network interfaces directly to the host rather than through any proxy. I'd considered doing this too but never got around to it, it's a nice improvement over Dinghy's current solution. The HTTP proxy would still be nice for making SSL termination easy but that could be layered on top.

Not sure how DNS names will be chosen. I've come to really like the docker-compose based names but even if it's just <containername>.docker.local that'd be ok.

Uses xhyve, which is about 10% slower than virtualbox for typical dev tasks in my testing. However, I've already switched to the dinghy xhyve driver myself because it's so much more pleasant than virtualbox for this use case.

Overall it sounds really nice. The proof will be once we can actually try it out, but if it works as well as they claim I'll probably just deprecate Dinghy once Docker for Mac is publicly released. That's assuming Docker for Mac is a free product, I'd hope it would be but they haven't said, and it sounds like at least parts of it will not be open source.

Looks like that's already been clarified, Docker for Mac will be free and open source.
https://news.ycombinator.com/item?id=11353747

Agreed.  This looks to be very exciting.  I'm waiting for my invite :-)

Me too!

I've been testing the beta today. The way it maps permissions for mounted volumes is different, and a little weird. It seems to map all bind mounted volumes to whatever UID:GID you are currently running as inside the container. So when you gosu foo, the owner and group of all your bind mounted volumes will change from root to foo.
In theory, this sounds like it should resolve the existing issue where you have to create/modify a user inside the container to match the UID:GID of the bind mounted volumes (which can't be changed). But I was previously working around that by doing gosu "$(stat -c '%u' "${DIR}"):$(stat -c '%g' "${DIR}")" which no longer works as expected.
So at the very least, this different behaviour has broken parity with images that work under regular Docker Engine.
Here's what their docs say. Sounds like this feature might be short-lived:

Presently, all requesting processes are treated as owners and group members on all bind mounted file system resources. This behavior simultaneously solves uid/gid mapping headaches and creates new compatibility (and possibly security) issues. A finer-grained ownership model is in development.

I tested out the beta for a bit yesterday, but ran into I/O errors when trying to bundle install onto a host-mounted volume. I haven't had a chance to dig further yet. Interestingly they're almost exactly the same git clone I/O errors I got when trying to run the unfsd NFS daemon as a non-root user. git seems to be especially sensitive to filesystem bugs.

Unfortunately the Docker for Mac beta is significantly slower than dinghy for my workflow. I use the vmware driver -- between the osxfs driver burning significant CPU and the overhead of xhyve, a build which normally takes a little over 4 minutes ends up taking over 20 minutes.
I currently use vagrant for most of my development environment management, but jumped on the docker for mac beta in hopes it would simplify my workflow. And it does! However, the performance is bad enough that it's unusable for me. I have no doubt that xhyve performance will improve over time... eventually, it may be a good alternative. Dinghy to the rescue! :)

Yeah, I believe them when they say the FS performance will improve over time, they should be able to beat NFS performance using their architecture, with some work.

I've been playing with Docker for Mac the past few days. What I'm missing is the DNS functionality that Dinghy provides. I'm hoping that they include a custom DNS but looking at this thread it doesn't look like it...anytime soon anyways. Is there anyway to break out the DNS part of Dinghy into its own component that can be reused by Dinghy and standalone by Docker for Mac users?

Yep, the HTTP proxy and DNS server have been split into a separate project, install instructions are at https://github.com/codekitchen/dinghy-http-proxy#os-x

@codekitchen That's great. Thank you. I will give it a spin....I still find Docker for Mac unstable so I'll stick to Dinghy for the time being. 🍰

osxfs still can't compete with nfs or even the vbox guest additions. It's so slow. IMO, Docker for Mac is not a complete replacement yet.

Hey @codekitchen,
Sorry for a silly question. Is it possible to run dinghy with docker-beta?
Thx!

Hey @codekitchen,
Sorry for a silly question. Is it possible to run dinghy with docker-beta?
Thx!

@igorvpcleao From what I understand, the only thing you'd want from Dinghy would be its proxy & DNS which are available here https://github.com/codekitchen/dinghy-http-proxy. One major aspect of Docker for mac is to make osxfs performant and stable. So the NFS and fsevents from Dinghy should not really be needed in Docker for mac.
So if/once https://forums.docker.com/t/custom-dns-for-resolving-containers/8361 gets fixed/merged then I think that Dinghy might be up for deprecation all together.
But until Docker for mac is stable (which it wasn't when I tried it last month) I'm sticking to Dinghy. Now I just received e-mail from Docker that Docker for mac/windows is RC. Might be worth testing it out again.

Thanks @michaellopez!
Good to hear that. I don't know why, but I'm still experiencing problems with shared folders. Solving this DNS issue will make the transference among host and container faster?

Yeah that's a great summary, thanks @michaellopez
One twist is that we've got devs using Linux laptops and running Docker directly on the host, and it's nice that the Dinghy HTTP proxy works the same way for them. So we may continue on using it anyway, even if Docker for Mac introduces its own solution there.

@igorvpcleao No, proxy & DNS is only for resolving virtual hosts on the host to a container ip and port. It does nothing with shared folders or osxfs in Docker for mac.

Until osxfs is as fast as nfs I think there will still be a need for dinghy. It would be good to be able to use docker for Mac with nfs until that happens. Will it be possible?

I don't currently have any plans to support that, I haven't even looked into whether it's possible to tell docker for mac to disable its own built-in filesystem so that it could use NFS instead.

Since Mac Docker now has a public beta I thought I'd try rebenchmarking.
Here's my results, I guess I'll stick with docker-osx-dev for now.
Mac benchmark (without Docker)
dd if=/dev/zero of=/tmp/output bs=8k count=100k; rm -f /tmp/output
102400+0 records in
102400+0 records out
838860800 bytes transferred in 1.132447 secs (740750602 bytes/sec)

docker-osx-dev (revision ea0617d)
dd if=/dev/zero of=/usr/src/app/output bs=8k count=100k; rm -f /usr/src/app/output
app_1  | 102400+0 records in
app_1  | 102400+0 records out
app_1  | 838860800 bytes (839 MB) copied, 0.261691 s, 3.2 GB/s

Dinghy Docker over NFS (4.4.1)
dd if=/dev/zero of=/usr/src/app/output bs=8k count=100k; rm -f /usr/src/app/output
app_1  | 102400+0 records in
app_1  | 102400+0 records out
app_1  | 838860800 bytes (839 MB) copied, 26.5691 s, 31.6 MB/s

Mac Docker Public Beta (1.12.0-rc2-beta17 build: 9779)
dd if=/dev/zero of=/usr/src/app/output bs=8k count=100k; rm -f /usr/src/app/output
app_1  | 102400+0 records in
app_1  | 102400+0 records out
app_1  | 838860800 bytes (839 MB) copied, 34.3933 s, 24.4 MB/s

Thanks for the benchmark.
How would you explain the fact that dockerosx-dev is faster than native ?
If I clearly understood, you ran that commands inside your containers ? and /usr/src/app/output is mounted on the host ? So this is a  benchmark only on writing performance ?
Could you provide the same benchmark but for reading performance ?
Thanks

As I understand it your docker-osx-dev benchmark is meaningless, because docker-osx-dev only does one-way syncing from the OS X host to the VM, not the other way around. So you're simply measuring the VM write performance. That's the primary reason we chose NFS for Dinghy, rather than rsync, because we have containers that we need to write to shares and persist them back to the OS X host.

little update on this, the current docker-for-mac releases are not longer invite only, you do no longer need to enter a private beta key and therefore no NDA/Terms acceptance needed. This probably helps you.
I am very surprised to see that the rc2 does perform that well against NFS - most of the people in this thread, me included, are not using osxfs since its is absolutely to slow for everything: https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/109
I am here, because i am considering switching from docker for mac with rsync ( custom solution ) to dinghy. Eventhough rsync as the solution lets you run the containers in good speed, the sync is plain PITA in the end. On the paper, its working - but:

fswatcher are worse then the shares on OSX
fswacher ( ruby wrapper or the c implementation from brew ) needs about 80% of my CPU when watching my dev folder. This scales with then number of file, feels linear
due to the way the events are propageted, there is no "bundling or grouping" this means, lets say you trigger rsync on a fswatcher event. No consider you switch a branch in SCM - you happen to have about 400 or more fswatcher events - each tries to sync all the data. This is VERY slow due to the connection overhead
fswatcher regulary forgets to fire events - it is not relyable or convenient to use

So in the end i am about to give up with rsync ( being using it with vboxn, then fusion now docker for mac ) and trying to think about a NFS solution.
In general, anything except file sharing is pretty cool in docker for mac, so all i want is docker for mac with NFS most probably. But if the performance is as bad as up there ( close to osxfs ) i would rahter not use it.
Any real world examples?

@EugenMayer I'm not sure if you are looking for "testimonals" for Dinghy...But we are using Dinghy in our daily workflow at my company. I can't see how working with Docker on a mac can be done without it at the moment. We use modern Macbook Pros and so far no performance issue. Watchers are inside the container, Dinghy forwards file system events on OSX into the container. I can't say that we have very large trees being watched, but I am very meticulous about our builds, just watching what really needs watching. I often see tool.watch('**'), which of course will not perform well with a large tree. I'd be happy to answer any questions, or run something on our setup given that you provide something to run :)

You run the watcher to compile/generate any kind of assets in the container right?
If you lets say change ruby files, you would not need watchers for that, those are synced using NFS, right?
Even without any node_modules/bower/coffescript/scss files, only watching for js/css/code we end up haing arround 12k files. This does, for sure, kill fswatcher + rsync but does totaly defeat osxfs ( we are talking about a factor far above 100 slower then rsync/native)
Am i right that NFS read performance is considerable bette then its write performance? Most of the people in the linked thread, when using synthetic benchmarks, use write benchmarks. I consider those benchmarks useless. No data generated ( written ) in the VM should ever happen to be saved on the code-base. Those data either stays in the container volume, or if to be persisted, on volumes whatever.
osxfs is pretty slow in reading also, so thats were i would need compare it to NFS and then NFS to native ( native is what i have right now ). When running a PHP cli up, parsing about 600 PHP files to bootstrap the app, reading performance does matter a lot :)
In case, when we have them all here: Docker 4 Mac, dinghy - what about dlite. How does dinghy compare to dlite?

@EugenMayer Yes, we use watchers inside the container to do things like recompile on save. The files are synced with NFS, but NFS does NOT trigger file system events inside the container. That's why Dinghy uses https://github.com/codekitchen/fsevents_to_vm, it reacts to file system events on OSX and sends a packet to the VM that trigger file system events for the container.
I honestly haven't worked on projects where I need to watch 12k files. I can't understand how it comes to that, but I respect that fact that those kinds of repositories do exist and needs to be worked with.
I do not have any source on NFS performance at hand, but I have a vague memory of reading somewhere that write performance better than read, yes.
If only the "checkout another branch" scenario, or similar, is the only case where the watchers poses a problem (meaning, commands that run seldom) and if you are using Dinghy, then maybe you can kill the fsevents_to_vm process, do the checkout and restart it again with dinghy up (note: untested :)

I am not happy with this amount of files - but you cant change it. Though, its at least not only repo :)
dlite 1.x seems to do less, which fits my needs a bit more as its seems. It does not support switching the provider, which is nice on dinghy side, though i use xhyve anyway.
dinghy provides dnsmasq and used with xhyve that colides with my boxen-stack dnsmasq. No needs for proxies (at least i can disable that).
It seems like dlite 2 and dinghy seem to be very similar - but i guess i am hijacking this topic.
Coming back to the performance, both using NFS while dlite uses the OSX build in server. Not sure if this harms or is better, but that could be different in performance terms ( either way )
I guess i try both of them compared against docker4mac+rsync and report back on my "real world test"

Made some tests with dinghy and docker 4 mac:
dinghy
NFS
drush cc all  7.97s user 1.40s system 28% cpu 32.817 total
NO SHARE
drush cc all  7.52s user 0.79s system 75% cpu 10.993 total
Docker for Mac
OSXFS
drush cc all  8.42s user 4.06s system 24% cpu 51.265 total
NO SHARE
drush cc all  7.02s user 0.72s system 77% cpu 10.005 total

So NFS vs OSXFS is about 1.5 times slower, but in seconds, thats quiet some bit: 32s vs 51s
Bot compared to no share with 10s is 3-5 times slower. But since adds on each command this is for us, unusable.
Find: The import of the DB dump was a lot faster on Docker 4 mac "no share", so the I/O performance in terms of write is a lot better

As an aside for anyone that's not familiar with drush: the commands above are "bootstrapping" Drupal (loading and interpreting all the PHP files), connecting to the database, and then clearing or invalidating all of the caches. That could be any combination of cache tables in the db, redis, memcache, etc. That process is a pretty good benchmark for how Drupal will perform under average conditions.

Can we keep this issue discussion to the original purpose please? This side discussion is interesting but would be a lot better in a separate issue.

Created https://github.com/EugenMayer/docker_sync as a result of all the tests, including the tests with dinghy. It has docker-for-mac support ( and docker-machine and  all others ). Might be a way for dinghy also ( since dinghy is more, dns..proxy..) .. but it is rsync based, not NFS based, due to the performance issues with NFS.
When you plan to switch to docker-for-mac you might want to look at that gem, probably out-sourcing the sync part and keeping anything else like the http-proxy/dnsmasq in dinghy.

Sounds interesting and is maybe a better implementation than docker-osx-dev, but if I am not wrong performance comes with some high restrictions compared to dinghy. Mainly there is no sync back, aka files created by processes in the container won't be synced back to the host.

@mickaelperrin docker-sync now supports unison also, which is a 2 way Sync. So also that case is covered, just check the docs

Hi everyone, now that Docker for Mac is out and stable has anyone switched to it? If so, what are the performances like? I wonder if there's a difference between the beta and the stable release.

@mnapoli eventhough there has been quiet some work on osxfs for the last stable release, benachmarks are already telling, nothing changed performance wise. This post is a pretty good statement from the docker for mac developers, what to expect from osxfs, when and what issues there are: https://forums.docker.com/t/file-access-in-mounted-volumes-extremely-slow-cpu-bound/8076/158?u=eugenmayer - it has been posted pretty recently

@EugenMayer thanks for the link, I'll be staying with Dinghy for now then.

So Docker announced that Docker for Mac and Windows is now "ready for production", but based on the top comment in this HN thread, I am not in any rush to move over still:
https://news.ycombinator.com/item?id=12184567
On top of all those issues, it does not support anything similar to the .docker container DNS which our workflow relies on heavily.
Dinghy fo' lyfe :metal:

@MrMMorris The *.docker container DNS is not needed. Docker for Mac/Windows exposes container ports directly on the host OS. So you can access your containerised services directly on localhost. If you were relying on the *.docker DNS to test things that expect a domain name in the host header, or test a site that behaves differently on subdomains, or wanted to keep cookies separate, etc., then you can just use *.lvh.me, which is a wildcard DNS that maps to <IP_ADDRESS>. This is now one more thing (the hostname/port you access a service on) that works the same on Docker for Mac/Win as it does on Docker for Linux, or when running an project natively on the host OS.

@mrmachine he is most probably referencing to dnsmasq, and even if everything is on localhost, you wont be able to use myproject.dev and yourporject.dev without a tool. Installing dnsmasq is as easy as
brew install dnsmasq
cp $(brew list dnsmasq | grep /dnsmasq.conf.example$) /usr/local/etc/dnsmasq.conf
sudo cp $(brew list dnsmasq | grep /homebrew.mxcl.dnsmasq.plist$) /Library/LaunchDaemons/
sudo launchctl load /Library/LaunchDaemons/homebrew.mxcl.dnsmasq.plist

You can modify its config at /usr/local/etc/dnsmasq.conf and adjust ist, by default it routes all *.dev to localhost, but you can also use *.docker or whatever.
So it is fairly easy, and in addition, also useful for not only docker related things

@EugenMayer I know he meant the *.docker wildcard DNS (dnsmasq). But you don't need a tool to access services via a domain name on localhost. As I said, just use *.lvh.me. It's a real wildcard domain that maps to <IP_ADDRESS>, so you don't need dnsmasq. Just access myproject.lvh.me and yourproject.lvh.me on any computer without installing anything.
This won't work with Dinghy because the IP is not <IP_ADDRESS>, which is why you need dnsmasq to access services via hostname with Dinghy.

Using *.lvh.me is a good tip, but note it's not quite the same thing -- since there's no HTTP proxy to do vhost resolving, you'd need to run each container on a different port. Doable of course, but not as straightforward as just typing in a domain name, especially when your dev work involves running many HTTP services.

Also note that dinghy-http-proxy has been extracted into a separate project that works just fine with Docker for Mac (I have a handful of co-workers doing this), see https://github.com/codekitchen/dinghy-http-proxy#using-outside-of-dinghy

@codekitchen thanks for the tip! although it is still a more manual setup compared to Dinghy

@codekitchen unless I'm missing something, there's still only one docker host (VM) with Dinghy, so you can still only ever bind one container to a given port at a time. With Docker for Mac you just also have to avoid conflict with non-container services that are also running on localhost? With Dinghy, I think it's still not possible to say run two containers that both expose port 80 to the host? Or is the Dinghy proxy doing something clever like forwarding port 80 to whatever internally exposed port the containers are running (like dockercloud-haproxy does)? If the container is exposing multiple ports, how does the proxy know which one to proxy?

Yes, it proxies HTTP requests to the other running containers based on hostname, without them having to map a port to the host. See the docs https://github.com/codekitchen/dinghy-http-proxy

Just as a quick update, we still aren't seeing acceptable volume share performance in Docker for Mac. Some people at my company who only work on small projects have been using it daily without issue, but it's still too slow to use on our larger ruby and nodejs codebases.

So the long and the short of it is, if you're comfortable with Dinghy, stick with dinghy because it is faster for large codebases?  It'd probably be good to add some notes about this on the main Readme - I just got very confused when I visited the docker website and everything had changed...

That's a good call, I'll add something to the README

I am evaluating http://docker-sync.io/ for increasing performance when using large codebases.
It definitely needs some work so if anyone wants to give it a try and contribute anything they can, that would be great!

I've been recommending developers move away from Docker for Mac to Dinghy as the former seems to be awfully buggy at the moment and is exponentially slower with non-trivial projects using volume sharing.  Some encouragement from me to keep working on this project -- it is valuable.

@xfxf
"move away from Docker for Mac to Dinghy as the former seems to be awfully buggy"
Is this still the case? Would love to see this issue be kept up to date. Thanks

@debovis You can help keep it up to date. Try out Docker for Mac and report back with your findings. The more data we have the better! 👍

I swapped back to Docker For Mac about a month ago, and swapped back to dinghy about a week ago.  dinghy is still exponentially faster than Docker For Mac.

I changed to docker for mac with http://docker-sync.io/
and this tweak applied
https://github.com/docker/for-mac/issues/668
is really fast

can confirm what @rodrigoaguilera said, using the fix https://github.com/docker/for-mac/issues/668 with d4m gives a huge boost in our setup, its enormous for bigger installations / apps, maybe it does  scale over linear. Still have to stick with docker-sync though for the host-mounts / shares, those are still very slow

Hi everyone,
I've just used this article  after a clean upgrade (OSX 10.13) to install docker for mac.
Personally, I use delegated on volume (more infos) and it seems pretty fast at the moment. For example, before this update, my Laravel application was really slow (it took more than 5 seconds to load a page) but now, it's done in less than 1 second.

Using the delegated flag does sound promising, I'll have to try that out. Thanks for the tip @robinparisi

Hello :) here a speed Test between dinghy and docker4mac.
Native:
docker run --rm -it -w /pwd alpine time dd if=/dev/zero of=speedtest bs=1024 count=100000
100000+0 records in
100000+0 records out
real	0m 0.23s
user	0m 0.03s
sys	0m 0.20s

Dinghy:
docker run --rm -it -v "$(PWD):/pwd" -w /pwd alpine time dd if=/dev/zero of=speedtest bs=1024 count=100000
100000+0 records in
100000+0 records out
real	0m 0.66s
user	0m 0.02s
sys	0m 0.21s

docker4mac cached:
docker run --rm -it -v "$(PWD):/pwd:cached" -w /pwd alpine time dd if=/dev/zero of=speedtest bs=1024 count=100000
100000+0 records in
100000+0 records out
real	0m 17.51s
user	0m 0.31s
sys	0m 1.73s

docker4mac delegated:
docker run --rm -it -v "$(PWD):/pwd:delegated" -w /pwd alpine time dd if=/dev/zero of=speedtest bs=1024 count=100000
100000+0 records in
100000+0 records out
real	0m 19.36s
user	0m 0.19s
sys	0m 2.12s


From someone who is somewhat tech illiterate

How do I open this up to play? I downloaded an app that recognizes the Python files, but all it does is open for not even a second before closing itself. I've tried this multiple times, and even checked to make sure it wasn't just running in the background, but nothing has come up.

Hey if all you want to do is play the game, go to http://www.aidungeon.io/ and click play.

@kborb
Even then it's not so obvious at all. I thought I was just looking at a readme file, not the actual program.
The "How to play" section actually refers to the page you're on when you open:
https://colab.research.google.com/github/nickwalton/AIDungeon/blob/master/AIDungeon_2.ipynb
You wanna use the menus at the top of that page, like described.


Keymap for sendLines and sendFile

Closing issues, as the main feature inteded collides with Vim-Ionide keymaps, and is therefore more or less obsolete.


Allow using custom Session class

Current Session class stores user context in memory. This is legit when we are only serving bot on single machine. Once we are going to serve it onto multiple servers behind load balancer, we should allow user to implement their own Session logic to utilize Redis, Memcache etc.

@tjwudi Yeah we need to implement implementations for Redis.
The Session is a bit of a weird class right now and in theory some of its behaviour could be handled by the Bot or the Client.


Clean

This cleans up the files in the Root directory that shouldn't be in git ... the CoreData Entities that are added as 'Class Definitions are regenerated at build time

Theses are temporary. I have them to see the structure while coding. I could remove later when done with the CoreData work.


First stab at CircleCI 2.0 migration

Based heavily on the work in https://github.com/openzipkin/brave-cassandra/pull/9
The original used the zulu-9 JDK. Initially I tried running the build on a Docker image with the same JDK, but immediately ran into problems (it's not set up to be a test execution environment); for example there's no sudo in the official Zulu 9 image. Note that CircleCI doesn't publish JDK version 9 (see https://hub.docker.com/r/circleci/openjdk/tags/). This PR uses OpenJDK 8, I'm not sure if this causes problems – @adriancole ?
A difference from https://github.com/openzipkin/brave-cassandra/pull/9: instead of messing around with find moving test result reports, I tried directly pointing CircleCI at the SureFire output (as theorized in https://github.com/openzipkin/brave/pull/725#discussion_r199327738). Unfortunately this job doesn't actually run any tests (just like the PR in brave-cassandra, no tests were run before the migration either), so the result of this change is unconfirmed.
I'll also note here that the build definition is looooooooooooong, and I feel error-prone with all the regexes and ignores and so on, and duplicated between many (?) repositories. (Yes, I might have been involved in setting them up originally, I'll still say this is not good). Deduping them is a good area for future research.

Note that CircleCI doesn't publish JDK version 9 (see https://hub.docker.com/r/circleci/openjdk/tags/).

I'm not sure why, but JDK 9 tags are available even though not listed in DockerHub. See, for example, this build: https://circleci.com/gh/openzipkin/brave/1393. That said, we should move to JDK 10 probably since 9 is EOL, but I wanted to just port things as close to the current state as possible first.

instead of messing around with find moving test result reports, I tried directly pointing CircleCI at the SureFire output

This works fine and is (IMO) preferable if the build is not multi-module. With multi-module projects, the test results are scattered in each of the sub-projects, and this is why we need to collect the reports.

I'm not sure why, but JDK 9 tags are available even though not listed in DockerHub.

Oh wow. It looks like the UI lists a nice round 100 tags, with no paging. Confirming JDK 9 images exist, fixing:
$ curl https://registry.hub.docker.com/v1/repositories/circleci/openjdk/tags | jq '.[] | .name' -r | grep '^9'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 19998    0 19998    0     0  28527      0 --:--:-- --:--:-- --:--:-- 28527
9
-- SNIP --
9-jdk
9-jdk-browsers
9-jdk-node
-- SNIP --

the 2.0 migration guide tells to rename and move the file to .circleci/config.yml

Good catch, thanks. Lemme fix that.

Build is green; changes were direct fix of review comments, so I won't wait for another round of reviews (let me know if that's against Zipkin practices).
Squash and merge.

what you did is fine!
On Sun, 1 Jul 2018, 12:56 Zoltán Nagy<EMAIL_ADDRESS>wrote:

Build is green; changes were direct fix of review comments, so I won't
wait for another round of reviews (let me know if that's against Zipkin
practices).
Squash and merge.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
https://github.com/openzipkin/zipkin-api/pull/52#issuecomment-401585006,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAD61wELC1sSBWfIXL6axd6OhYd-NoeGks5uCGR9gaJpZM4U-DhO
.


fix/fetch index.html with webFetch

Coverage decreased (-0.2%) to 86.125% when pulling 5563d87f78f201843f90a43043b78ef089b38394 on hunterlester:fix into f883a4186833d39201f4f8ef042ed6f27c06ff4e on maidsafe:master.

The PR works only index.html. Other files are not loaded


[admin] Fix formatting

Docs Build status updates of commit ab63d7e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs/getting-started.md
:white_check_mark:Succeeded

docs/how-to-set-a-custom-property-in-a-word-processing-document.md
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching the docs.microsoft.com contributor guidesPost your question in the Docs support channel


net461, why?

Any technical reason why this targets net461?

That's because the following error:

Install-Package : Could not install package 'IdentityServer4.MongoDB 1.0.1'. You are trying to install this package into a project that targets '.NETFramework,Version=v4.6.1', but the package does not contain any assembly references or content files that are compatible with that framework.

I have projects targeting .NET Full that need to use. Maybe I should change it to net452, like IdentityServer4.EF.


Discuss: where to store ommers

Akula for example stores them inside Header as Vec<Header> or as we have that num|hash mapping for headers we could store them inside Header table.
More on discussion here: https://github.com/foundry-rs/reth/pull/190#discussion_r1020122565

Closed as we landed on storing ommers in a dedicated table


Relax FSharp.Core dependency?

Hello,
in a similar way as it has been done for Feliz is it possible to relax the dependency over FSharp.Core?

In fact, I am asking that because I don't really know why I get a warning about a downgrade to FSharp.Core 4.7.0 instead of 4.7.1.
Do you know how is FSharp.Core version determined when not present in an fsproj?

Hi Maxime, it should be easy to do, I will get to it ASAP.

Do you know how is FSharp.Core version determined when not present in an fsproj?

I think it depends on the currently used SDK, latest one uses a more recent version of F# core

Ok thank you and I have the same feeling as you.
Note: I never had the problem because I was using paket with a redirection but I am trying to simplify my repositories by using nuget instead of  paket and npm instead of  yarn.

Published Fable.Mocha v2.9.1 which should have a relaxed and chill version constraint on FSharp.Core :rocket:

I am trying to simplify my repositories by using nuget instead of paket and npm instead of yarn.

Happy to hear that 😍


Added ability to change tooltip animate opacity.

Proposed changes
Ability to change tooltip default opacity using options.  The ultimate result are tooltips that can be transparent.
Types of changes

[ ] Bug fix (non-breaking change which fixes an issue).
[X] New feature (non-breaking change which adds functionality).
[ ] Breaking change (fix or feature that would cause existing functionality to change).

Checklist:

[X] I have read the CONTRIBUTING document.
[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.
[ ] I have added tests to cover my changes.
[ ] All new and existing tests passed.

Note: this PR has been merged to materializecss/materialize (https://github.com/materializecss/materialize/pull/23)


Use fetch instead of http

Hello,
The package uses http (in tests). Will it be possible to use the fetch package instead ?
http is deprecated in favor of fetch : https://docs.meteor.com/api/http

@dr-dimitru does your new package<EMAIL_ADDRESS>still use http ? or you have migrated to fetch ? thanks. If you have migrated to fetch you can close the issue.

@dokithonon yes! I only patched dependencies and ran tests


SCM Decorations missing

OK I was able to find 100% repro steps out of sources on master. I can't repro on Insiders tho... 🙈
There's a bit of setup:
git init foo
git init bar
echo hello > foo/file.json

Then, open both folders in a single workspace window
Go to the SCM viewlet, file.json should appear as untracked with the letter U
Click file.json and it will open a diff editor, now in the SCM view it appears as 1,U due to the JSON syntax error
Reload

🐛 It only shows 1 instead of U. As soon as you hit Refresh on the repository, the U appears!
This could also very well be an issue in Git and not decorations. @jrieken Can you check whether the decorations are reaching your model at least?

Does this repo consistently? Otherwise you can enable trace logging. Whenever I retrieve data it's being logged as trace-message

Go to the SCM viewlet, file.json should appear as untracked with the letter U

This is just in one window, right? The bar windows doesn't show anything. I have followed your steps but wasn't able to reproduce....

OK it seems I can't get 100% repro but I'm more on 50% now. It's also irrelevant to the error decoration, as I am able to repro without that decoration.
After enabling trace logging, that message doesn't show up for those decorations. Will dig deeper.

Oh man, it's related to the ignore decorator. When I comment that one out, not only git decorations come much faster but also the bug does not reproduce.

Caught it:
https://github.com/microsoft/vscode/blob/1b0f70606a81edbba6f260d507aaf2828cf8bc03/extensions/git/src/decorationProvider.ts#L47
If two provideDecoration calls for the same uri overlap, the second one's resolve and reject will overwrite the first one's, so that first one will never complete! This points to a potential issue in decorations in which if some providers do not complete, this affects other provider's decorations as well. This might also be a pretty ugly memory leak of pending provideDecoration calls, since we might listen on them forever and ever. @jrieken Leaving this investigation to you.
I've fixed it in https://github.com/microsoft/vscode/commit/fad4d8d254f9959bb64b9ebb9f6a0742ec4cc005 and now I can't repro no more! 💪

Caught it:

Hmmm... You saw this in source or actually for real? The refetch while pending fetch shouldn't happen and it would be pretty horrible if it does.

I think what's more likely is that this is happening because the we don't honour the cancellation token that is passed to the provide call. Internally we cancel requests re-fetching them while they are in flight

You saw this in source or actually for real?

Saw it running out of sources, but I have some users reporting similar issues: https://github.com/microsoft/vscode/issues/98241, https://github.com/microsoft/vscode/issues/53260, https://github.com/microsoft/vscode/issues/93701

I think what's more likely is that this is happening because the we don't honour the cancellation token that is passed to the provide call. Internally we cancel requests re-fetching them while they are in flight

Makes sense! Should we still do some work in the core in case people don't respect the token? (Remember you implemented the original ignore decoration provider 😆)

Should we still do some work in the core in case people don't respect the token

We do which makes me wonder how this reproduced... I'll need to step through this to get a repo and an understanding


Migrating to 2.0.0

Hey there,
just a quick heads up. When I update our sources to 2.0.0, it still runs the tests and works fine locally. But if I run it on our gitlab-ci the tests run and coverage gets reported as zero percent on the commandline.

I'm seeing this also when I run on our jenkins-ci

Same results in this environment from command-line  (1.2.0 works; 2.0.0 reports zero hits)
Linux 904f5451827d 4.9.87-linuxkit-aufs #1 SMP Wed Mar 14 15:12:16 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
.NET Command Line Tools (2.1.4)
Product Information:
Version:            2.1.4
Commit SHA-1 hash:  5e8add2190
Runtime Environment:
OS Name:     ubuntu
OS Version:  17.10
OS Platform: Linux
RID:         linux-x64
Base Path:   /usr/share/dotnet/sdk/2.1.4/
Microsoft .NET Core Shared Framework Host
Version  : 2.0.5
Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54
Command-line:
dotnet restore && dotnet build --no-restore && dotnet test netcore2Hello.Test/ --no-build /p:CollectCoverage=true /p:CoverletOutputFormat=cobertura
using a different output format has no effect

Hi @Razzeee @xtiancapil @dlkay0 did #110 fix this?

#110 is an issue and thus doesn't fix stuff ;)
So you're saying I should try https://github.com/tonerdo/coverlet/issues/110#issuecomment-392688542 excluding the test adapter?

@Razzeee yes that's what I meant. Sorry for not being more specific

SO I did run dotnet test /p:CollectCoverage=true /p:Exclude=[NUnit3.TestAdapter]* on our linux CI server and it still reports 0% with version 2.0

Thanks for the update @melih154, I'm still unable to reproduce this in Linux

@aburgett87
I switched from 2.0.5 based on ubuntu to 2.0.7 based on official dotnet-docker:2.0.7-sdk-2.1.200 and excluded NUnit3.TestAdapter (/p:Exclude=[NUnit3.TestAdapter]*) and the combination yielded a valid coverage report using coverlet 2.0.0.
I've also managed to get colored source to display.
My issue is resolved.

It's working for us again. Using the latest version in combination with dotnet core 2.1


Google Cloud (GCP) integration

you already have google drive, cloud uses the same auth if i recall correctly, and id love to use this for an easy integration, and it seems like this would be a pain-free add.
:)

I can show you my implementation if you’re interested, but I had to make a
bunch of changes and then switch to firebase, so it’s not really something
I can actively use at this point anyway, however, I will be continuing to
flesh out the firebase, which is essentially just a wrapper around Google
cloud itself. So it could still satisfy your needs, but if not, I
definitely still have a way of interacting with Google cloud
On Mon, Mar 11, 2024 at 12:28 Thomas Faust @.***> wrote:

Hi @NextdoorPsycho https://github.com/NextdoorPsycho, do you want to
contribute a PR?
—
Reply to this email directly, view it on GitHub
https://github.com/ehwplus/fl_cloud_storage/issues/7#issuecomment-1988858283,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AG7WI7ESQO6RRFNVEEL5MKDYXXLRTAVCNFSM6AAAAABEPIXXZGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOBYHA2TQMRYGM
.
You are receiving this because you were mentioned.Message ID:
@.***>


fix(spaces): Display using infinite scroll

This ensures the spaces listing is not limited to
only first 20 results, or something thereof. Further spaces are
displayed on scroll. Fixes #290

Please don't merge, as this is dependent on https://github.com/fabric8-ui/ngx-fabric8-wit/pull/52

[test]


Unrecoverable error when joining node attempts to retrieve etcd member list from itself

Tracking issue for the sequence of events discussed in https://github.com/rancher/rke2/issues/5557#issuecomment-1981691021
If users deploy an external load-balancer or DNS round-robin address list to provide the fixed registration endpoint, and add server nodes to the target pool before they have finished joining the cluster, nodes may attempt to join themselves. This can leave the joining node in a permanently broken state that requires manual cleanup to resolve.
We should enhance the cluster join process to allow detecting cases where a server is attempting to join itself, and either retry or return an error, rather than continuing on with partial information.

Can we get this prioritised please starting from 1.26 because we are running into this issue on all our LTS releases and right now this issue is getting masked in the rke2-server retry loop that we have put in
Ideally, the node joining should work on the first attempt and we noticed sometimes it would take 5 to 10 restarts

I'm confused what you mean by LTS, we do not offer LTS releases for k3s or rke2.
Sorry for the confusion, when I mean LTS, it's our LTS release cadence where we bundle RKE2 and we periodically provide k8's update to our customers

We do have a health probe defined for 9345 port at load-balancer to route traffic destined for 9345 port. It seems that it is forwarding request to same node since rke2 is bringing up this port the moment rke2 service is started. Should we change the health probe to use a different port i.e either use etcd port or API server port, would it solve the issue and will there be any repercussions if we use a different port as a health probe on LB?

Same answer as I gave at https://github.com/rancher/rke2/issues/5557#issuecomment-1986046348, except for k3s the health-check would look like:
curl -ksf https://node:token@<IP_ADDRESS>:6443/v1-k3s/readyz

@brandond Most of the load balancers support health probe on single port so its not practically possible to have health probes on multiple probes
Also the curl based check you have suggested that is also not feasible via LB as we won't be aware of token at the time of configuring healthprobe on the backend pool
Is it possible to have health probe on a single port and if yes what would be that port/component ?

You can set the token manually; you don't have to let the server generate a random one for you.
If all of your servers are control-plane+etcd, I would health check the apiserver on 6443.

yeah all our servers are control-plane + etcd, we will try with 6443 and get back here with the outcome. Thanks Brandon

@brandond With 6443 as health probe for rke2 port, We are not seeing any issue. Thanks for you help 🙏

Unable to replicate / validate in k3s, but was able to replicate with rke2. Validation is done on the rke2 commit with k3s pull through and tracked in here: https://github.com/rancher/rke2/issues/5804#issuecomment-2065413396


Encrypt the bucket and log access on the AWS S3 Bucket of the TFState

Encrypt the bucket and log the access on the AWS S3 Bucket of the Terraform State - both bucket-wide.

This looks great, thank you!
Two questions:
1. Could you update the README to indicate that encryption and access logging will be turned on by default and can be enabled with the new `skip_xxx` params?

2. How did you test these changes?

(1) OK - will do.
(2) I'm not familiar with the way a PR should be done in GoLang - thought that the maintainers do the testing. Is there a procedure for testing your code within Terragrunt?

Whoops, hit enter too soon! What I was trying to write:

I'm not familiar with the way a PR should be done in GoLang - thought that the maintainers do the testing. Is there a procedure for testing your code within Terragrunt?

Since Terragrunt talks to AWS, and our CI builds have credentials for our AWS account, we can't automatically run tests on external PRs: https://circleci.com/docs/2.0/oss/#pass-secrets-to-builds-from-forked-pull-requests
So, we ask contributors to run tests themselves. You can test it manually and/or automatically. Once I merge, all the CI tests will run, but I want to have some sense of confidence so I don't merge broken code into master.

@brikis98 Tested with:
[root@localhost go-project]# re-go.sh
=== RUN   TestConfigValuesEqual
=== PAUSE TestConfigValuesEqual
=== RUN   TestForcePathStyleClientSession
=== PAUSE TestForcePathStyleClientSession
=== RUN   TestGetAwsSessionConfig
=== PAUSE TestGetAwsSessionConfig
=== RUN   TestToTerraformInitArgs
=== PAUSE TestToTerraformInitArgs
=== RUN   TestToTerraformInitArgsUnknownBackend
=== PAUSE TestToTerraformInitArgsUnknownBackend
=== RUN   TestToTerraformInitArgsNoBackendConfigs
=== PAUSE TestToTerraformInitArgsNoBackendConfigs
=== RUN   TestDiffersFrom
=== PAUSE TestDiffersFrom
=== RUN   TestParseTerraformStateLocal
=== PAUSE TestParseTerraformStateLocal
=== RUN   TestParseTerraformStateRemote
=== PAUSE TestParseTerraformStateRemote
=== RUN   TestParseTerraformStateRemoteFull
=== PAUSE TestParseTerraformStateRemoteFull
=== RUN   TestParseTerraformStateEmpty
=== PAUSE TestParseTerraformStateEmpty
=== RUN   TestParseTerraformStateInvalid
=== PAUSE TestParseTerraformStateInvalid
=== CONT  TestConfigValuesEqual
=== CONT  TestParseTerraformStateLocal
=== CONT  TestParseTerraformStateInvalid
--- PASS: TestParseTerraformStateInvalid (0.00s)
=== RUN   TestConfigValuesEqual/equal-both-empty
=== PAUSE TestConfigValuesEqual/equal-both-empty
=== RUN   TestConfigValuesEqual/equal-empty-and-nil
=== PAUSE TestConfigValuesEqual/equal-empty-and-nil
=== RUN   TestConfigValuesEqual/equal-empty-and-nil-backend-config
=== PAUSE TestConfigValuesEqual/equal-empty-and-nil-backend-config
=== RUN   TestConfigValuesEqual/equal-one-key
=== PAUSE TestConfigValuesEqual/equal-one-key
=== RUN   TestConfigValuesEqual/equal-multiple-keys
=== PAUSE TestConfigValuesEqual/equal-multiple-keys
=== RUN   TestConfigValuesEqual/equal-encrypt-bool-handling
=== PAUSE TestConfigValuesEqual/equal-encrypt-bool-handling
=== RUN   TestConfigValuesEqual/equal-general-bool-handling
=== PAUSE TestConfigValuesEqual/equal-general-bool-handling
=== RUN   TestConfigValuesEqual/equal-ignore-s3-tags
=== PAUSE TestConfigValuesEqual/equal-ignore-s3-tags
=== RUN   TestConfigValuesEqual/equal-ignore-dynamodb-tags
=== PAUSE TestConfigValuesEqual/equal-ignore-dynamodb-tags
=== RUN   TestConfigValuesEqual/unequal-wrong-backend
=== PAUSE TestConfigValuesEqual/unequal-wrong-backend
=== RUN   TestConfigValuesEqual/unequal-values
=== CONT  TestParseTerraformStateRemoteFull
--- PASS: TestParseTerraformStateRemoteFull (0.00s)
--- PASS: TestParseTerraformStateLocal (0.00s)
=== PAUSE TestConfigValuesEqual/unequal-values
=== RUN   TestConfigValuesEqual/unequal-non-empty-config-nil
=== PAUSE TestConfigValuesEqual/unequal-non-empty-config-nil
=== RUN   TestConfigValuesEqual/unequal-general-bool-handling
=== PAUSE TestConfigValuesEqual/unequal-general-bool-handling
=== CONT  TestConfigValuesEqual/equal-both-empty
=== CONT  TestConfigValuesEqual/equal-ignore-s3-tags
=== CONT  TestConfigValuesEqual/equal-general-bool-handling
=== CONT  TestConfigValuesEqual/equal-encrypt-bool-handling
=== CONT  TestConfigValuesEqual/unequal-general-bool-handling
=== CONT  TestConfigValuesEqual/unequal-values
=== CONT  TestToTerraformInitArgsNoBackendConfigs
--- PASS: TestToTerraformInitArgsNoBackendConfigs (0.00s)
=== CONT  TestToTerraformInitArgsUnknownBackend
[terragrunt] 2019/02/03 23:34:40 Backend config has changed from map[foo:different] to map[foo:bar]
--- PASS: TestToTerraformInitArgsUnknownBackend (0.00s)
[terragrunt] 2019/02/03 23:34:40 Backend config has changed from map[something:%!s(bool=false)] to map[something:%!s(bool=true)]
=== CONT  TestGetAwsSessionConfig
=== CONT  TestConfigValuesEqual/unequal-non-empty-config-nil
=== CONT  TestConfigValuesEqual/equal-ignore-dynamodb-tags
=== RUN   TestGetAwsSessionConfig/all-values
=== PAUSE TestGetAwsSessionConfig/all-values
=== CONT  TestConfigValuesEqual/unequal-wrong-backend
=== RUN   TestGetAwsSessionConfig/no-values
=== PAUSE TestGetAwsSessionConfig/no-values
[terragrunt] 2019/02/03 23:34:40 Backend type has changed from s3 to wrong
=== RUN   TestGetAwsSessionConfig/extra-values
=== PAUSE TestGetAwsSessionConfig/extra-values
=== CONT  TestToTerraformInitArgs
=== CONT  TestParseTerraformStateEmpty
=== CONT  TestDiffersFrom
[terragrunt] 2019/02/03 23:34:40 Backend  has not changed.
[terragrunt] 2019/02/03 23:34:40 Backend s3 has not changed.
[terragrunt] 2019/02/03 23:34:40 Backend type has changed from s3 to atlas
[terragrunt] 2019/02/03 23:34:40 Backend s3 has not changed.
[terragrunt] 2019/02/03 23:34:40 Backend config has changed from map[region:us-east-1 bucket:foo key:bar] to map[bucket:different key:bar region:us-east-1]
[terragrunt] 2019/02/03 23:34:40 Backend config has changed from map[bucket:foo key:bar region:us-east-1] to map[bucket:foo key:different region:us-east-1]
[terragrunt] 2019/02/03 23:34:40 Backend config has changed from map[bucket:foo key:bar region:us-east-1] to map[bucket:foo key:bar region:different]
[terragrunt] 2019/02/03 23:34:40 Backend config has changed from map[something:true] to map[something:%!s(bool=false)]
=== CONT  TestParseTerraformStateRemote
=== CONT  TestConfigValuesEqual/equal-multiple-keys
=== CONT  TestConfigValuesEqual/equal-one-key
=== CONT  TestConfigValuesEqual/equal-empty-and-nil-backend-config
=== CONT  TestConfigValuesEqual/equal-empty-and-nil
--- PASS: TestConfigValuesEqual (0.00s)
    --- PASS: TestConfigValuesEqual/equal-both-empty (0.00s)
    --- PASS: TestConfigValuesEqual/equal-general-bool-handling (0.00s)
    --- PASS: TestConfigValuesEqual/equal-ignore-s3-tags (0.00s)
    --- PASS: TestConfigValuesEqual/equal-encrypt-bool-handling (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-values (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-general-bool-handling (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-non-empty-config-nil (0.00s)
    --- PASS: TestConfigValuesEqual/equal-ignore-dynamodb-tags (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-wrong-backend (0.00s)
    --- PASS: TestConfigValuesEqual/equal-multiple-keys (0.00s)
    --- PASS: TestConfigValuesEqual/equal-one-key (0.00s)
    --- PASS: TestConfigValuesEqual/equal-empty-and-nil-backend-config (0.00s)
    --- PASS: TestConfigValuesEqual/equal-empty-and-nil (0.00s)
=== CONT  TestForcePathStyleClientSession
=== RUN   TestForcePathStyleClientSession/path-style-true
=== PAUSE TestForcePathStyleClientSession/path-style-true
=== RUN   TestForcePathStyleClientSession/path-style-false
=== PAUSE TestForcePathStyleClientSession/path-style-false
=== RUN   TestForcePathStyleClientSession/path-style-non-existent
=== PAUSE TestForcePathStyleClientSession/path-style-non-existent
=== CONT  TestForcePathStyleClientSession/path-style-true
=== CONT  TestForcePathStyleClientSession/path-style-non-existent
=== CONT  TestForcePathStyleClientSession/path-style-false
=== CONT  TestGetAwsSessionConfig/all-values
=== CONT  TestGetAwsSessionConfig/extra-values
=== CONT  TestGetAwsSessionConfig/no-values
--- PASS: TestGetAwsSessionConfig (0.00s)
    --- PASS: TestGetAwsSessionConfig/all-values (0.00s)
    --- PASS: TestGetAwsSessionConfig/extra-values (0.00s)
    --- PASS: TestGetAwsSessionConfig/no-values (0.00s)
--- PASS: TestToTerraformInitArgs (0.00s)
--- PASS: TestParseTerraformStateEmpty (0.00s)
--- PASS: TestDiffersFrom (0.00s)
--- PASS: TestParseTerraformStateRemote (0.00s)
--- FAIL: TestForcePathStyleClientSession (0.00s)
    --- FAIL: TestForcePathStyleClientSession/path-style-non-existent (0.28s)
        require.go:765:
                Error Trace:    remote_state_s3_test.go:154
                Error:          Expected nil, but got: &errors.Error{Err:(*awserr.baseError)(0xc00005a980), stack:[]uintptr{0x766e41, 0x79d339, 0x7a3eeb, 0x4e2c5f, 0x45d551}, frames:[]errors.StackFrame(nil), prefix:"Error finding AWS credentials (did you set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables?)"}
                Test:           TestForcePathStyleClientSession/path-style-non-existent
                Messages:       Unexpected error creating client for test: Error finding AWS credentials (did you set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables?): NoCredentialProviders: no valid providers in chain. Deprecated.
                                        For verbose messaging see aws.Config.CredentialsChainVerboseErrors
    --- FAIL: TestForcePathStyleClientSession/path-style-true (0.31s)
        require.go:765:
                Error Trace:    remote_state_s3_test.go:154
                Error:          Expected nil, but got: &errors.Error{Err:(*awserr.baseError)(0xc00005a980), stack:[]uintptr{0x766e41, 0x79d339, 0x7a3eeb, 0x4e2c5f, 0x45d551}, frames:[]errors.StackFrame(nil), prefix:"Error finding AWS credentials (did you set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables?)"}
                Test:           TestForcePathStyleClientSession/path-style-true
                Messages:       Unexpected error creating client for test: Error finding AWS credentials (did you set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables?): NoCredentialProviders: no valid providers in chain. Deprecated.
                                        For verbose messaging see aws.Config.CredentialsChainVerboseErrors
    --- FAIL: TestForcePathStyleClientSession/path-style-false (0.33s)
        require.go:765:
                Error Trace:    remote_state_s3_test.go:154
                Error:          Expected nil, but got: &errors.Error{Err:(*awserr.baseError)(0xc00005a980), stack:[]uintptr{0x766e41, 0x79d339, 0x7a3eeb, 0x4e2c5f, 0x45d551}, frames:[]errors.StackFrame(nil), prefix:"Error finding AWS credentials (did you set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables?)"}
                Test:           TestForcePathStyleClientSession/path-style-false
                Messages:       Unexpected error creating client for test: Error finding AWS credentials (did you set the AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables?): NoCredentialProviders: no valid providers in chain. Deprecated.
                                        For verbose messaging see aws.Config.CredentialsChainVerboseErrors
FAIL
exit status 1
FAIL    _/root/go-project/terragrunt/remote     0.335s

Haven't tested it with real AWS account yet - fixed 3 bugs and it should be fine now.
Will try and test it through a real AWS account probably tomorrow evening after my work day is finished and get home.

@brikis98 I guess I'm a geek... and couldn't resist the temptation - tested with an AWS account:
[root@localhost go-project]# re-go.sh
=== RUN   TestConfigValuesEqual
=== PAUSE TestConfigValuesEqual
=== RUN   TestForcePathStyleClientSession
=== PAUSE TestForcePathStyleClientSession
=== RUN   TestGetAwsSessionConfig
=== PAUSE TestGetAwsSessionConfig
=== RUN   TestToTerraformInitArgs
=== PAUSE TestToTerraformInitArgs
=== RUN   TestToTerraformInitArgsUnknownBackend
=== PAUSE TestToTerraformInitArgsUnknownBackend
=== RUN   TestToTerraformInitArgsNoBackendConfigs
=== PAUSE TestToTerraformInitArgsNoBackendConfigs
=== RUN   TestDiffersFrom
=== PAUSE TestDiffersFrom
=== RUN   TestParseTerraformStateLocal
=== PAUSE TestParseTerraformStateLocal
=== RUN   TestParseTerraformStateRemote
=== PAUSE TestParseTerraformStateRemote
=== RUN   TestParseTerraformStateRemoteFull
=== PAUSE TestParseTerraformStateRemoteFull
=== RUN   TestParseTerraformStateEmpty
=== PAUSE TestParseTerraformStateEmpty
=== RUN   TestParseTerraformStateInvalid
=== PAUSE TestParseTerraformStateInvalid
=== CONT  TestConfigValuesEqual
=== RUN   TestConfigValuesEqual/equal-both-empty
=== CONT  TestParseTerraformStateLocal
=== CONT  TestParseTerraformStateRemoteFull
--- PASS: TestParseTerraformStateLocal (0.00s)
=== PAUSE TestConfigValuesEqual/equal-both-empty
=== RUN   TestConfigValuesEqual/equal-empty-and-nil
=== PAUSE TestConfigValuesEqual/equal-empty-and-nil
=== RUN   TestConfigValuesEqual/equal-empty-and-nil-backend-config
=== PAUSE TestConfigValuesEqual/equal-empty-and-nil-backend-config
=== RUN   TestConfigValuesEqual/equal-one-key
=== PAUSE TestConfigValuesEqual/equal-one-key
--- PASS: TestParseTerraformStateRemoteFull (0.00s)
=== RUN   TestConfigValuesEqual/equal-multiple-keys
=== PAUSE TestConfigValuesEqual/equal-multiple-keys
=== RUN   TestConfigValuesEqual/equal-encrypt-bool-handling
=== PAUSE TestConfigValuesEqual/equal-encrypt-bool-handling
=== RUN   TestConfigValuesEqual/equal-general-bool-handling
=== PAUSE TestConfigValuesEqual/equal-general-bool-handling
=== RUN   TestConfigValuesEqual/equal-ignore-s3-tags
=== PAUSE TestConfigValuesEqual/equal-ignore-s3-tags
=== RUN   TestConfigValuesEqual/equal-ignore-dynamodb-tags
=== PAUSE TestConfigValuesEqual/equal-ignore-dynamodb-tags
=== RUN   TestConfigValuesEqual/unequal-wrong-backend
=== CONT  TestToTerraformInitArgsNoBackendConfigs
--- PASS: TestToTerraformInitArgsNoBackendConfigs (0.00s)
=== CONT  TestToTerraformInitArgsUnknownBackend
--- PASS: TestToTerraformInitArgsUnknownBackend (0.00s)
=== CONT  TestToTerraformInitArgs
--- PASS: TestToTerraformInitArgs (0.00s)
=== CONT  TestGetAwsSessionConfig
=== RUN   TestGetAwsSessionConfig/all-values
=== PAUSE TestGetAwsSessionConfig/all-values
=== RUN   TestGetAwsSessionConfig/no-values
=== CONT  TestForcePathStyleClientSession
=== CONT  TestParseTerraformStateInvalid
=== CONT  TestParseTerraformStateRemote
--- PASS: TestParseTerraformStateRemote (0.00s)
=== CONT  TestDiffersFrom
[terragrunt] 2019/02/03 23:49:26 Backend  has not changed.
[terragrunt] 2019/02/03 23:49:26 Backend s3 has not changed.
[terragrunt] 2019/02/03 23:49:26 Backend type has changed from s3 to atlas
[terragrunt] 2019/02/03 23:49:26 Backend s3 has not changed.
[terragrunt] 2019/02/03 23:49:26 Backend config has changed from map[bucket:foo key:bar region:us-east-1] to map[bucket:different key:bar region:us-east-1]
[terragrunt] 2019/02/03 23:49:26 Backend config has changed from map[region:us-east-1 bucket:foo key:bar] to map[bucket:foo key:different region:us-east-1]
[terragrunt] 2019/02/03 23:49:26 Backend config has changed from map[bucket:foo key:bar region:us-east-1] to map[key:bar region:different bucket:foo]
[terragrunt] 2019/02/03 23:49:26 Backend config has changed from map[something:true] to map[something:%!s(bool=false)]
--- PASS: TestDiffersFrom (0.00s)
=== CONT  TestParseTerraformStateEmpty
--- PASS: TestParseTerraformStateEmpty (0.00s)
=== PAUSE TestConfigValuesEqual/unequal-wrong-backend
=== RUN   TestConfigValuesEqual/unequal-values
=== PAUSE TestConfigValuesEqual/unequal-values
=== RUN   TestConfigValuesEqual/unequal-non-empty-config-nil
=== PAUSE TestConfigValuesEqual/unequal-non-empty-config-nil
=== RUN   TestConfigValuesEqual/unequal-general-bool-handling
=== PAUSE TestConfigValuesEqual/unequal-general-bool-handling
=== CONT  TestConfigValuesEqual/equal-both-empty
=== PAUSE TestGetAwsSessionConfig/no-values
=== RUN   TestGetAwsSessionConfig/extra-values
=== PAUSE TestGetAwsSessionConfig/extra-values
=== CONT  TestGetAwsSessionConfig/all-values
=== CONT  TestConfigValuesEqual/unequal-general-bool-handling
[terragrunt] 2019/02/03 23:49:26 Backend config has changed from map[something:%!s(bool=false)] to map[something:%!s(bool=true)]
=== CONT  TestConfigValuesEqual/unequal-non-empty-config-nil
=== CONT  TestConfigValuesEqual/unequal-values
[terragrunt] 2019/02/03 23:49:26 Backend config has changed from map[foo:different] to map[foo:bar]
=== CONT  TestConfigValuesEqual/equal-multiple-keys
=== CONT  TestConfigValuesEqual/equal-one-key
=== CONT  TestConfigValuesEqual/equal-empty-and-nil-backend-config
--- PASS: TestParseTerraformStateInvalid (0.00s)
=== CONT  TestConfigValuesEqual/unequal-wrong-backend
=== CONT  TestConfigValuesEqual/equal-empty-and-nil
[terragrunt] 2019/02/03 23:49:26 Backend type has changed from s3 to wrong
=== RUN   TestForcePathStyleClientSession/path-style-true
=== CONT  TestConfigValuesEqual/equal-encrypt-bool-handling
=== CONT  TestGetAwsSessionConfig/extra-values
=== CONT  TestConfigValuesEqual/equal-ignore-dynamodb-tags
=== CONT  TestConfigValuesEqual/equal-ignore-s3-tags
=== CONT  TestConfigValuesEqual/equal-general-bool-handling
--- PASS: TestConfigValuesEqual (0.00s)
    --- PASS: TestConfigValuesEqual/equal-both-empty (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-general-bool-handling (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-non-empty-config-nil (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-values (0.00s)
    --- PASS: TestConfigValuesEqual/equal-one-key (0.00s)
    --- PASS: TestConfigValuesEqual/equal-multiple-keys (0.00s)
    --- PASS: TestConfigValuesEqual/equal-empty-and-nil-backend-config (0.00s)
    --- PASS: TestConfigValuesEqual/equal-empty-and-nil (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-wrong-backend (0.00s)
    --- PASS: TestConfigValuesEqual/equal-encrypt-bool-handling (0.00s)
    --- PASS: TestConfigValuesEqual/equal-ignore-dynamodb-tags (0.00s)
    --- PASS: TestConfigValuesEqual/equal-ignore-s3-tags (0.00s)
    --- PASS: TestConfigValuesEqual/equal-general-bool-handling (0.00s)
=== PAUSE TestForcePathStyleClientSession/path-style-true
=== RUN   TestForcePathStyleClientSession/path-style-false
=== PAUSE TestForcePathStyleClientSession/path-style-false
=== RUN   TestForcePathStyleClientSession/path-style-non-existent
=== PAUSE TestForcePathStyleClientSession/path-style-non-existent
=== CONT  TestForcePathStyleClientSession/path-style-true
=== CONT  TestGetAwsSessionConfig/no-values
--- PASS: TestGetAwsSessionConfig (0.00s)
    --- PASS: TestGetAwsSessionConfig/all-values (0.00s)
    --- PASS: TestGetAwsSessionConfig/extra-values (0.00s)
    --- PASS: TestGetAwsSessionConfig/no-values (0.00s)
=== CONT  TestForcePathStyleClientSession/path-style-non-existent
=== CONT  TestForcePathStyleClientSession/path-style-false
--- PASS: TestForcePathStyleClientSession (0.00s)
    --- PASS: TestForcePathStyleClientSession/path-style-true (0.00s)
    --- PASS: TestForcePathStyleClientSession/path-style-non-existent (0.00s)
    --- PASS: TestForcePathStyleClientSession/path-style-false (0.00s)
PASS
ok      _/root/go-project/terragrunt/remote     0.009s

OK, code changes and tests look great!
If you can update the README accordingly, this is good to merge. Thanks!

@brikis98 Perfect - will update the README accordingly today. Thank you / Спасибо!

I'll retest it as well today in the evening - before coming back here and letting you know the status.

[root@localhost ~]# cat /usr/local/bin/re-go.sh
#!/usr/bin/env bash

rm -rf /root/go-project/terragrunt/
cp -r /root/shares/GitHub/Xtigyro/terragrunt/ /root/go-project/
cd /root/go-project/terragrunt/remote/
go test -v -parallel 128

[root@localhost ~]# re-go.sh
=== RUN   TestConfigValuesEqual
=== PAUSE TestConfigValuesEqual
=== RUN   TestForcePathStyleClientSession
=== PAUSE TestForcePathStyleClientSession
=== RUN   TestGetAwsSessionConfig
=== PAUSE TestGetAwsSessionConfig
=== RUN   TestToTerraformInitArgs
=== PAUSE TestToTerraformInitArgs
=== RUN   TestToTerraformInitArgsUnknownBackend
=== PAUSE TestToTerraformInitArgsUnknownBackend
=== RUN   TestToTerraformInitArgsNoBackendConfigs
=== PAUSE TestToTerraformInitArgsNoBackendConfigs
=== RUN   TestDiffersFrom
=== PAUSE TestDiffersFrom
=== RUN   TestParseTerraformStateLocal
=== PAUSE TestParseTerraformStateLocal
=== RUN   TestParseTerraformStateRemote
=== PAUSE TestParseTerraformStateRemote
=== RUN   TestParseTerraformStateRemoteFull
=== PAUSE TestParseTerraformStateRemoteFull
=== RUN   TestParseTerraformStateEmpty
=== PAUSE TestParseTerraformStateEmpty
=== RUN   TestParseTerraformStateInvalid
=== PAUSE TestParseTerraformStateInvalid
=== CONT  TestConfigValuesEqual
=== CONT  TestParseTerraformStateLocal
--- PASS: TestParseTerraformStateLocal (0.00s)
=== RUN   TestConfigValuesEqual/equal-both-empty
=== PAUSE TestConfigValuesEqual/equal-both-empty
=== CONT  TestDiffersFrom
=== RUN   TestConfigValuesEqual/equal-empty-and-nil
=== PAUSE TestConfigValuesEqual/equal-empty-and-nil
=== RUN   TestConfigValuesEqual/equal-empty-and-nil-backend-config
=== PAUSE TestConfigValuesEqual/equal-empty-and-nil-backend-config
=== RUN   TestConfigValuesEqual/equal-one-key
=== PAUSE TestConfigValuesEqual/equal-one-key
=== RUN   TestConfigValuesEqual/equal-multiple-keys
[terragrunt] 2019/02/04 23:32:58 Backend  has not changed.
=== PAUSE TestConfigValuesEqual/equal-multiple-keys
=== RUN   TestConfigValuesEqual/equal-encrypt-bool-handling
[terragrunt] 2019/02/04 23:32:58 Backend s3 has not changed.
=== PAUSE TestConfigValuesEqual/equal-encrypt-bool-handling
[terragrunt] 2019/02/04 23:32:58 Backend type has changed from s3 to atlas
=== RUN   TestConfigValuesEqual/equal-general-bool-handling
=== PAUSE TestConfigValuesEqual/equal-general-bool-handling
[terragrunt] 2019/02/04 23:32:58 Backend s3 has not changed.
=== RUN   TestConfigValuesEqual/equal-ignore-s3-tags
=== PAUSE TestConfigValuesEqual/equal-ignore-s3-tags
=== RUN   TestConfigValuesEqual/equal-ignore-dynamodb-tags
[terragrunt] 2019/02/04 23:32:58 Backend config has changed from map[bucket:foo key:bar region:us-east-1] to map[bucket:different key:bar region:us-east-1]
=== PAUSE TestConfigValuesEqual/equal-ignore-dynamodb-tags
=== RUN   TestConfigValuesEqual/unequal-wrong-backend
[terragrunt] 2019/02/04 23:32:58 Backend config has changed from map[bucket:foo key:bar region:us-east-1] to map[bucket:foo key:different region:us-east-1]
=== PAUSE TestConfigValuesEqual/unequal-wrong-backend
=== RUN   TestConfigValuesEqual/unequal-values
=== PAUSE TestConfigValuesEqual/unequal-values
[terragrunt] 2019/02/04 23:32:58 Backend config has changed from map[bucket:foo key:bar region:us-east-1] to map[bucket:foo key:bar region:different]
=== RUN   TestConfigValuesEqual/unequal-non-empty-config-nil
=== PAUSE TestConfigValuesEqual/unequal-non-empty-config-nil
[terragrunt] 2019/02/04 23:32:58 Backend config has changed from map[something:true] to map[something:%!s(bool=false)]
=== RUN   TestConfigValuesEqual/unequal-general-bool-handling
=== PAUSE TestConfigValuesEqual/unequal-general-bool-handling
=== CONT  TestToTerraformInitArgsNoBackendConfigs
--- PASS: TestDiffersFrom (0.00s)
=== CONT  TestToTerraformInitArgs
--- PASS: TestToTerraformInitArgsNoBackendConfigs (0.00s)
=== CONT  TestToTerraformInitArgsUnknownBackend
--- PASS: TestToTerraformInitArgsUnknownBackend (0.00s)
=== CONT  TestConfigValuesEqual/equal-ignore-dynamodb-tags
=== CONT  TestConfigValuesEqual/equal-ignore-s3-tags
=== CONT  TestConfigValuesEqual/equal-general-bool-handling
=== CONT  TestConfigValuesEqual/equal-encrypt-bool-handling
=== CONT  TestConfigValuesEqual/equal-one-key
=== CONT  TestParseTerraformStateEmpty
--- PASS: TestParseTerraformStateEmpty (0.00s)
--- PASS: TestToTerraformInitArgs (0.00s)
=== CONT  TestParseTerraformStateInvalid
--- PASS: TestParseTerraformStateInvalid (0.00s)
=== CONT  TestParseTerraformStateRemoteFull
--- PASS: TestParseTerraformStateRemoteFull (0.00s)
=== CONT  TestParseTerraformStateRemote
--- PASS: TestParseTerraformStateRemote (0.00s)
=== CONT  TestConfigValuesEqual/equal-both-empty
=== CONT  TestGetAwsSessionConfig
=== RUN   TestGetAwsSessionConfig/all-values
=== PAUSE TestGetAwsSessionConfig/all-values
=== RUN   TestGetAwsSessionConfig/no-values
=== PAUSE TestGetAwsSessionConfig/no-values
=== RUN   TestGetAwsSessionConfig/extra-values
=== PAUSE TestGetAwsSessionConfig/extra-values
=== CONT  TestGetAwsSessionConfig/all-values
=== CONT  TestConfigValuesEqual/unequal-general-bool-handling
[terragrunt] 2019/02/04 23:32:58 Backend config has changed from map[something:%!s(bool=false)] to map[something:%!s(bool=true)]
=== CONT  TestConfigValuesEqual/unequal-non-empty-config-nil
=== CONT  TestConfigValuesEqual/unequal-values
[terragrunt] 2019/02/04 23:32:58 Backend config has changed from map[foo:different] to map[foo:bar]
=== CONT  TestConfigValuesEqual/unequal-wrong-backend
[terragrunt] 2019/02/04 23:32:58 Backend type has changed from s3 to wrong
=== CONT  TestForcePathStyleClientSession
=== RUN   TestForcePathStyleClientSession/path-style-true
=== PAUSE TestForcePathStyleClientSession/path-style-true
=== RUN   TestForcePathStyleClientSession/path-style-false
=== PAUSE TestForcePathStyleClientSession/path-style-false
=== RUN   TestForcePathStyleClientSession/path-style-non-existent
=== PAUSE TestForcePathStyleClientSession/path-style-non-existent
=== CONT  TestForcePathStyleClientSession/path-style-true
=== CONT  TestGetAwsSessionConfig/extra-values
=== CONT  TestGetAwsSessionConfig/no-values
--- PASS: TestGetAwsSessionConfig (0.00s)
    --- PASS: TestGetAwsSessionConfig/all-values (0.00s)
    --- PASS: TestGetAwsSessionConfig/extra-values (0.00s)
    --- PASS: TestGetAwsSessionConfig/no-values (0.00s)
=== CONT  TestConfigValuesEqual/equal-multiple-keys
=== CONT  TestConfigValuesEqual/equal-empty-and-nil-backend-config
=== CONT  TestConfigValuesEqual/equal-empty-and-nil
--- PASS: TestConfigValuesEqual (0.00s)
    --- PASS: TestConfigValuesEqual/equal-ignore-s3-tags (0.00s)
    --- PASS: TestConfigValuesEqual/equal-ignore-dynamodb-tags (0.00s)
    --- PASS: TestConfigValuesEqual/equal-general-bool-handling (0.00s)
    --- PASS: TestConfigValuesEqual/equal-encrypt-bool-handling (0.00s)
    --- PASS: TestConfigValuesEqual/equal-one-key (0.00s)
    --- PASS: TestConfigValuesEqual/equal-both-empty (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-general-bool-handling (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-non-empty-config-nil (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-values (0.00s)
    --- PASS: TestConfigValuesEqual/unequal-wrong-backend (0.00s)
    --- PASS: TestConfigValuesEqual/equal-multiple-keys (0.00s)
    --- PASS: TestConfigValuesEqual/equal-empty-and-nil-backend-config (0.00s)
    --- PASS: TestConfigValuesEqual/equal-empty-and-nil (0.00s)
=== CONT  TestForcePathStyleClientSession/path-style-non-existent
=== CONT  TestForcePathStyleClientSession/path-style-false
--- PASS: TestForcePathStyleClientSession (0.00s)
    --- PASS: TestForcePathStyleClientSession/path-style-true (0.00s)
    --- PASS: TestForcePathStyleClientSession/path-style-non-existent (0.00s)
    --- PASS: TestForcePathStyleClientSession/path-style-false (0.00s)
PASS
ok      _/root/go-project/terragrunt/remote     0.014s

@brikis98 Tests - still OK. README.md - updated.