Unable to get consumer_app.py Example running

[InRiPa]

I'm trying to get a working example running using this library. Unfortunately, I'm really struggling with it.

What I'm trying to do:

• Using AHF core components on a separate IP address
• Use provider_app.py as Provider
• Use consumer_app.py as Consumer

What I did so far:

1. Created a custom config to provide services (see #17)
2. Created needed certificates and got the provider_app.py successfully registered

Now, I tried to get the consumer running.

1. I added the custom config
2. If the consumer is not creted in the service_registry, the library breaks with an exception in core_service_responses.py since the response doesn't contain the key service_orchestration_response['response'] Maybe something like the following would help (but also needs to be handled by the following logic.):

    """ Handle erroneous orchestration response """
    if "errorCode" in service_orchestration_response.keys():
        print("ERROR: Orchestration returned an error -\n Code: {0} | Type: {1} | Msg: {2}".format(
            service_orchestration_response['errorCode'],
            service_orchestration_response['exceptionType'],
            service_orchestration_response['errorMessage'],
            )
        )
        # return SomeCheckableReturnValue

3. Continuing with a already registered consumer and a valid certificate, the code breaks with an exception in consume_service in httpconsumer.py. For the hello-arrowhead service, there is no "cert" key in kwargs.

For handling this, maybe something like if "cert" in kwargs.keys(): could cover the error.

But my main question here is about what went wrong? The current example in the repository uses HTTP-INSECURE-JSON, what makes me believe that certificates for the service consumption is ignored. Is this a libray bug or did I messed something up during the configuration?

I tried to skip the https setting with the above mentioned statement., which resulted in following error on the provider side:

Started Arrowhead ArrowheadSystem
Traceback (most recent call last):
  File "src/gevent/greenlet.py", line 854, in gevent._gevent_cgreenlet.Greenlet.run
  File "/path/to/client-library-python/.venv/lib/python3.8/site-packages/gevent/baseserver.py", line 34, in _handle_and_close_when_done
    return handle(*args_tuple)
  File "/path/to/client-library-python/.venv/lib/python3.8/site-packages/gevent/server.py", line 233, in wrap_socket_and_handle
    with _closing_socket(self.wrap_socket(client_socket, **self.ssl_args)) as ssl_socket:
  File "/path/to/client-library-python/.venv/lib/python3.8/site-packages/gevent/_ssl3.py", line 797, in wrap_socket
    return SSLSocket(sock=sock, keyfile=keyfile, certfile=certfile,
  File "/path/to/client-library-python/.venv/lib/python3.8/site-packages/gevent/_ssl3.py", line 312, in __init__
    raise x
  File "/path/to/client-library-python/.venv/lib/python3.8/site-packages/gevent/_ssl3.py", line 308, in __init__
    self.do_handshake()
  File "/path/to/client-library-python/.venv/lib/python3.8/site-packages/gevent/_ssl3.py", line 667, in do_handshake
    self._sslobj.do_handshake()
ssl.SSLError: [SSL: HTTP_REQUEST] http request (_ssl.c:1124)
2020-11-30T12:58:47Z <Greenlet at 0x7fe7b5ff0d00: _handle_and_close_when_done(<bound method StreamServer.wrap_socket_and_handle , <bound method StreamServer.do_close of <WSGIServer, (<gevent._socket3.socket [closed] at 0x7fe7b4962e0)> failed with SSLError

[ajoino]

Thanks for putting the library to the test, it helps a lot.

Regarding your points:

1. I'm not sure how configuration is best done but I have some ideas, will discuss that in the pull request.
2. Crashing when the orchestration response is empty is a known bug and I have plans to implement something similar to what you suggested, it just hasn't seemed very important yet.
3. If I understand you correctly, I think it's a bug in the provider_app.py example. The interface description should be HTTP-SECURE-JSON when the client is given a certfile and keyfile, and HTTP-INSECURE-JSON when it is not. Though the major fault here is that the user gives the interface description, even though the protocol and security parts can be inferred from the kind of provider and access policy respectively. I think I will change this in future revisions so that only the last part is given when creating the service.

If I sound unsure it's because I do not sure answers. Even though I'm writing this library I haven't used it enough myself to know what causes all errors. I'm sorry that it has been a struggle so far, I have some plans to make the minimum working example easier, e.g. provide a pre-configured local cloud, but I'm currently working on getting token security up and running. I will try to have the next update done by the end of the week. This update will not change the API much but there are a lot of changes under the hood, like error handling of various kinds.

[InRiPa]

Hi,

thanks a lot for your help!

My main point is, that I need a definite verification, if I'm using the library wrong or if it is an error on library side. Could you reproduce my scenario (e.g. getting the demo example working with ssl and using an external AHF IP address)? If it works for you, I know, that I messed something up.

Even though I'm writing this library I haven't used it enough myself to know what causes all errors.

I'm not sure, if I understand this correctly. Is this library actively maintained or on stale? Thing is, I will have students working with Arrowhead and wanted them to use the python library. That's why I'm trying to figure out if it is currently usable/working.

[ajoino]

I'm not sure, if I understand this correctly. Is this library actively maintained or on stale? Thing is, I will have students working with Arrowhead and wanted them to use the python library. That's why I'm trying to figure out if it is currently usable/working.

The library is under active development, but the way I am using it and testing it is not enough to find all the bugs and bad design decisions, that's what I meant.

For example, connecting to core systems running on a different IP address is something I haven't tried but I'm working under the assumption that it would work the same. That is what you want me to test right, running the provider and consumer on one system and the core systems on another? If so, I'll try to do that tonight.

[ajoino]

Okay, tried to recreate your situation by doing the following:

• Pulled the Development branch from arrowhead-f.
• Started the core system dockers on my laptop on 192.168.50.195 in insecure mode.
• Changed _default_address to 192.168.50.195 in arrowhead_client.config.
• Changed the address in the provider_app.py example to 192.168.50.7.
• Commented out the keyfile and certfile lines in provider_app.py (to make it run in insecure mode).

When I ran provider_app.py given those changes I managed to connect to the core systems, no issues.

I didn't use secure mode because setting up the certificates would be more work than I'm willing to up in tonight. So try running the core systems in insecure mode and see if it works. If it does, double check that the certificates are all in order and if they aren't come back and I will investigate this further. And please tell me if I misunderstood your problem.

Once again, thanks for putting the library to the test!

[ajoino]

I just realized my previous reply did not answer any of your questions.

This is most likely a bug with the provider_app.py, since it registers with the interface HTTP-INSECURE-JSON despite being run in secure mode with the CERTIFICATE access policy. So what happens is that the INSECURE interface is registered in the service registry, and when the consumer asks the orchestrator for an orchestration rule it gives the consumer the wrong interface. And when the consumer tries to consume the hello-arrowhead service it gets to this line (line 66 in client_core.py)

if consumed_service.interface.secure == 'SECURE':
    # Add certificate files if service is secure
    kwargs['cert'] = self.cert

and the certificate files will not be added to the request and the provider will be upset and give an SSL error.

So I think that changing the interface of the provider in provider_app.py to HTTP-SECURE-JSON should solve all your issues. Please tell me if it doesn't.

[InRiPa]

Thanks a lot! I got the provider_app.py, consumer_app.py with SSL connecting against a remote ahf server running now.