Toni Tauro
Toni Tauro
Same issue here. ``` brig client version: ``v0.4.1+68f8766 [build: 2019-03-31T00:10:39+01:00]`` brig server version: ``v0.4.1+68f8766+68f8766fd9fe8929e8b3fc6cefca01454f380a5b`` IPFS Version: ``0.4.23+6ce9a355f`` ``` even deleted the whole .brig and .ipfs folder on both sides, re-initialized...
The problem seems not to happen if I let brig start up ipfs and not start ipfs standalone beforehand. Can you guys verify that @ivanhertanto @chasingegg ?
> 3. is there anything special I should keep in mind? Especially @toastal and @eyenx. Only error handling comes to mind. And @jtdaugherty already mentioned it. Thrnks for looking into...
Hi @song-jiang That is the Pod IP. But it is reachable. somehow calico networking on the node is failing, and that makes the readinessprobe fail of course.
this I cannot check as SSH is not working on theu node at that time. but kubectl exec works and the Pod is reachable. As mentioned above this happens for...
We managed to get a local Admin Account so we could access the node during that timeframe without SSH. Curl to the Pod gives back a timeout. So you suggest...
I am aware of that
Yes, here you go. This happens, for me with KOPANO when a recurring event is moved out of the timeframe it would usually be: ``` BEGIN:VCALENDAR VERSION:2.0 PRODID:-//Kopano//8.7.19//EN CALSCALE:GREGORIAN METHOD:REQUEST...