Johannes Hölzel

I believe, that the twitter post and the "you are not online, you cant use lens" screen confirm that, with the new version, a lens ID is in fact required.

there is no way around this, there are 3 evals that i dont think are replaceable

I would also be interested in this feature. It would be very interesting for staging and feature deployments where one does not want to create an entire cluster for testing,

+1 I seem to be running into the same issue with gitlab private repos Some variations i tried for gitlab - ssh://git@://// - ssh://git@://.git// - ssh://git@://.git/ - ssh://@//.git/ - https:////.git//...

it still doesnt work on V 0.59.1 , the smiley key reads as space even though its hyperkey + space 

i can confirm this to be the case with a digitialocean bucket too but i suspect its not the storage but my conf: ``` apiVersion: v1 kind: ConfigMap metadata: name:...

Is this not a typical henn and egg problem? In order to be HA you will need that load balancer anyway. The whole premise of a node dying is that...

Yes you are right that i don't *need* a load balancer, but I am more interested in how you are going to implement failure? As far as I understand we...

I mean i get the point for initial seeding, but would i not need my load-balancer anyways so that kubectl and api requests in general are spread out across all...

So in short, the external load balancer is only needed for external request from anything that uses a kubeconfig and therefore should not be a requirement for an HA k3s...