depa.tech doesn't work

[think-nice-things]

Hi,

I installed patzilla as from pip (0.169.3).
The data source ops works nicely but I didn't manage to use depa.tech.
I've aquired a depa.tech account.

The relevant config entries look like this:

[ip_naviator]
datasources = ops, depatisnet, depatech

# [datasource:depatech]                                                                                                                                                                                                                                                                                                                                  
api_uri      = {depatech_api_uri}                                                                                                                                                            
api_username = {depatech_api_username}                                                                                                                                                       
api_password = {depatech_api_password}     

where I used the credentials as supplied by depa.tech.

Still depa.tech doesn't appear and for example in the web interface I don't get the depa.tech button.

Anything I'm missing?

[amotl]

Dear @think-nice-things,

thank you for writing in.

Introduction

I installed patzilla as from pip (0.169.3).

Wow, did it work well? We are currently working on a refresh which will be converged into 0.170.0 soon and had quite a bunch of things to resolve.

I've aquired a depa.tech account.

Sweet. @herrkrueger and @mtcberlin will like it.

Problem report

I didn't manage to use depa.tech.

Bummer. We believe it works well on the hosted instance at https://patzilla.ip-tools.io/ ¹.

Let's try to make it work on your end as well. When depa.tech is successfully enabled, you should be able to spot those lines in the log:

2022-04-27 14:24:05,517 INFO     [patzilla.access.depatech.clientpool     ][MainThread] Using depa.tech API at https://api.depa.tech
2022-04-27 14:24:05,517 INFO     [patzilla.access.depatech.clientpool     ][MainThread] Creating upstream client pool for depa.tech

Investigation

If this is not the case, there might be some configuration flaw.

The relevant config entries look like this:

# [datasource:depatech]

That could already be the culprit. Section headers of .ini configuration files should not be prefixed with # .

Let us know if that helps already.

With kind regards,
Andreas.

Footnotes

1. We will be happy to provide you an account on the hosted instance of PatZilla we are operating. Let us know if you are interested about it. ↩

[amotl]

Another detail we just spotted within the configuration snippet you shared with us:

[ip_naviator]
datasources = ops, depatisnet, depatech

There is a typo here, it should be [ip_navigator] - one g is missing.

[think-nice-things]

thanks for your rapid reponse.
No unfortunatly everything is correct in my config, seems that I was just sloppy in my orignal post.
So the config reads in fact

[ip_navigator]
datasources = ops, depatisnet, depatech

[datasource:depatech]                                                                                                                                                                                                                                                                                                                                  
api_uri      = {depatech_api_uri}                                                                                                                                                            
api_username = {depatech_api_username}                                                                                                                                                       
api_password = {depatech_api_password}     

still not working.

How do I enable logging (e.g. to stdout / stderr)?

[amotl]

Hi again,

your configuration snippet looks reasonable, assuming that you replaced all the right-hand values {depatech_*} correctly.

How do I enable logging (e.g. to stdout / stderr)?

You don't see anything on stderr? How are you starting PatZilla?

With kind regards,
Andreas.

[think-nice-things]

pserve patzilla.ini

and I'm seeing

Starting server in PID 1187.
Serving on http://localhost:6543

The interface only shows these buttons:

I even installed patzilla in two totally different environments (1. ubuntu on windows wsl behind a firewall and with proxy and 2. debian linux w/o firewall) and depa.tech doesn't work on neither of them.

[amotl]

Thanks for those insights. We will have to dig deeper.

On my machine, I receive those kinds of log messages when PatZilla is starting up ¹:

2022-04-27 14:24:04,832 INFO     [patzilla.navigator.settings             ][MainThread] Root configuration file:       /path/to/patzilla/patzilla/config/development-local.ini
2022-04-27 14:24:04,832 INFO     [patzilla.util.config                    ][MainThread] Requested configuration files: /path/to/patzilla/patzilla/config/development-local.ini
2022-04-27 14:24:04,835 INFO     [patzilla.util.config                    ][MainThread] Effective configuration files: /path/to/patzilla/patzilla/config/development-local.ini
2022-04-27 14:24:05,357 INFO     [patzilla.access                         ][MainThread] Enabling data sources: ops, depatisnet, ificlaims, depatech, allpat
2022-04-27 14:24:05,495 INFO     [patzilla.access.epo.ops.client          ][MainThread] Creating upstream client pool for EPO/OPS
2022-04-27 14:24:05,513 INFO     [patzilla.access.ificlaims.clientpool    ][MainThread] Using IFI CLAIMS API at https://cdws21.ificlaims.com
2022-04-27 14:24:05,513 INFO     [patzilla.access.ificlaims.clientpool    ][MainThread] Creating upstream client pool for IFI CLAIMS
2022-04-27 14:24:05,517 INFO     [patzilla.access.depatech.clientpool     ][MainThread] Using depa.tech API at https://api.depa.tech
2022-04-27 14:24:05,517 INFO     [patzilla.access.depatech.clientpool     ][MainThread] Creating upstream client pool for depa.tech
2022-04-27 14:24:06,894 INFO     [patzilla                                ][MainThread] Application is ready to serve requests. Enjoy your research.
Starting server in PID 68128.
Serving on http://0.0.0.0:6543

It looks like the logging subsystem is not configured correctly on your end.

a) Your patzilla.ini has been created with patzilla make-config development?
b) Maybe you can share your full configuration file, without personal access credentials and tokens?

Footnotes

1. My environment is slightly different. a) I am working within a development sandbox. b) I am working on the development branch. However, only some messages might slightly deviate and not too much is special with the development sandbox. Logging to stderr should work in general without further ado. ↩

[amotl]

Hi again,

we tried to reproduce the problem but ran into another one, see #52. However, we can confirm that a) logging to stderr and b) activating the depa.tech data source seem to work out of the box with the recipe shared at #52.

With kind regards,
Andreas.

[amotl]

Hi again,

thanks for your hint at #52 (comment)

but yet depatech not working

We can confirm the situation. While the system pretends to bring up the data source, both on the backend/middleware and the frontend side, ....

in fact, it doesn't. Apologies!

We should soon release a new version of PatZilla which will hopefully improve the situation. In the meanwhile, can we humbly ask you if you would feel capable enough to work with the development version and a corresponding sandbox setup?

If so, you can use the latest progress from the more-tests branch ¹. On this matter, there is also a detailed and updated installation document ². Please let us know if you need further guidance.

With kind regards,
Andreas.

Footnotes

1. https://github.com/ip-tools/patzilla/tree/more-tests ↩

2. https://github.com/ip-tools/patzilla/blob/more-tests/docs/install/sandbox.rst ↩

[amotl]

Dear @think-nice-things,

How do I enable logging (e.g. to stdout / stderr)?

You don't see anything on stderr? How are you starting PatZilla?

While working on #49, we discovered the reason why stdout/stderr might have been silent on your end. It will be fixed with d619020. Thank you!

With kind regards,
Andreas.