[WiP] #634 Logging

[HadesArchitect]

Fixes #634

[HadesArchitect]

Work in Progress

[millerjp]

@mhmdkrmabd @HadesArchitect how we doing on this? Do we want to pull this into the next major release (right click)?

[HadesArchitect]

It looks good and will be finalized tomorrow, but I'm worried about proper testing. With no autotests and a huge changeset, we'll need to test everything manually.

[HadesArchitect]

loaded event is never fired on my side, not sure why. Will investigate tomorrow.

[HadesArchitect]

With more debug added, I see why the app is never loaded. Reason is, pty:cqlsh:initialize:finished is never fired because cqlsh fails to run.

It brings two questions:

• Why does it fail?
• How do we detect an issue like that so we write something meaningful to user and in log?

@mhmdkrmabd @digiserg, wdyt?

19:24:29.371 › Renderer is loaded
19:24:29.585 › EVENT pty:cqlsh:initialize
19:24:29.586 › Initializing CQLSH...
19:24:29.585 › Getting the key for encryption or decryption... type private
19:24:29.603 › PTY instance returned data [2945] Failed to load Python shared library '/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python': dlopen: dlopen(/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python, 0x000A): tried: '/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python' (no such file), '/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python' (no such file)
...
19:24:31.647 › Waiting initialization... Loaded: true Initialized: false
19:24:32.550 › Waiting initialization... Loaded: true Initialized: false
19:24:33.456 › Waiting initialization... Loaded: true Initialized: false
19:24:34.363 › Waiting initialization... Loaded: true Initialized: false

Much later, after I manually exit the workbench:

...
19:25:57.638 › PTY instance exited! exitcode: 0 signal: 9

Some log output is omitted for clarity

[HadesArchitect]

Manual call for cqlsh gives the same error:

aleks@aleksmacbookcable axonops-workbench % ./main/bin/cqlsh/cqlsh 
[3428] Failed to load Python shared library '/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python': dlopen: dlopen(/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python, 0x000A): tried: '/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python' (no such file), '/Users/aleks/axonops-workbench/main/bin/cqlsh/_internal/Python' (no such file)
aleks@aleksmacbookcable axonops-workbench % echo $?
255

The cqlsh file was downloaded as described in instructions

[mhmdkrmabd]

@HadesArchitect well based on the log it seems the building process of cqlsh wasn't successful, a Python shared library is missing, and the workbench - and this is only happening on macOS - is running an initialization process to grant privileges regarding the access of OS keychain and other permissions. The workbench would show notification to users about missing binaries, but in our case it's seems to be corrupted.

Did you build the binaries from your side? If so you please try those instead:
https://github.com/axonops/axonops-workbench-cqlsh/releases/tag/0.14.3

P.S: Saw the new comment. Let us test the darwin version of the binaries in our side to make sure it's not a common issue

[HadesArchitect]

Thanks @mhmdkrmabd I'll try those tomorrow

[digiserg]

Use this script to download the binaries:

          CQLSH_BUILD_VERSION="0.14.3"
          CQLSH_GITHUB_URL='https://github.com/axonops/axonops-workbench-cqlsh/releases/download'

          mkdir -p main/bin
          for binary in cqlsh keys_generator; do
            curl -fL ${CQLSH_GITHUB_URL}/${CQLSH_BUILD_VERSION}/${binary}-$(uname -s)-$(uname -m).tar | tar xf - -C main/bin
            mv main/bin/${binary}-$(uname -s)-$(uname -m) main/bin/${binary}
            mv main/bin/${binary}/${binary}-$(uname -s)-$(uname -m) main/bin/${binary}/${binary}
          done

[HadesArchitect]

Thanks, @digiserg. This script works. I see it brings more than just two files; I'll update the documentation accordingly.

The first question is answered, the second one is still to do: "How do we detect an issue like that so we write something meaningful to user and in log?" I'd extend check of these dependencies: not only check the presence of the files, but maybe call them and check exit code.