Stan

Results 18 comments of Stan

> actually the External-Provisioner is responsible for removing the annotation if the provision met errors Ah, that makes sense - thanks! I learned today that the `external-provisioner` isn't actually part...

Here's a current snapshot of the node's resources: ``` $ k describe node ip-10-4-16-2.us-west-2.compute.internal ............ Allocated resources: (Total limits may be over 100 percent, i.e., overcommitted.) Resource Requests Limits --------...

could you please elaborate?

fyi, I've just downgraded to version `0.11.2` and it works just fine. The following versions are broken for me: - `lnav-0.12.2` - `lnav-0.12.1` Looks like something is broken in `lnav-0.12.1`

@tstack, so I did install `lnav` inside a fresh, clean jail on my FreeBSD (`make -C /usr/ports/sysutils/lnav install clean`), and I can confirm it's not crashing inside the clean system....

So, FYI, this is the environment where it **works** ``` $ ldd /usr/local/bin/lnav /usr/local/bin/lnav: libreadline.so.8 => /usr/local/lib/libreadline.so.8 (0x30a8a56f3000) libncursesw.so.9 => /lib/libncursesw.so.9 (0x30a8a68ab000) libtinfow.so.9 => /lib/libtinfow.so.9 (0x30a8a61b7000) libsqlite3.so.0 => /usr/local/lib/libsqlite3.so.0 (0x30a8a74ab000)...

I just did the port build with the patches and can confirm it works! Thanks @tstack!

Just upgraded to 2.33.5 LTS, but I'm still seeing the same issue: ``` Failed to deploy a stack: compose up operation failed: Error response from daemon: linux spec capabilities: Unknown...