Lab demo fails with hostname mismatch

[planetf1]

Jupyter notebooks will fail to communicate with egeria servers which are not on localhost with the following error:

Checking OMAG Server Platform availability...
Exception: HTTPSConnectionPool(host='lab-core', port=9443): Max retries exceeded with url: /open-metadata/platform-services/users/garygeeke/server-platform/origin (Caused by SSLError(CertificateError("hostname 'lab-core' doesn't match 'localhost'")))
    Core Platform is down - start it before proceeding
Exception: HTTPSConnectionPool(host='lab-datalake', port=9443): Max retries exceeded with url: /open-metadata/platform-services/users/garygeeke/server-platform/origin (Caused by SSLError(CertificateError("hostname 'lab-datalake' doesn't match 'localhost'")))
    Data Lake Platform is down - start it before proceeding
Exception: HTTPSConnectionPool(host='lab-dev', port=9443): Max retries exceeded with url: /open-metadata/platform-services/users/garygeeke/server-platform/origin (Caused by SSLError(CertificateError("hostname 'lab-dev' doesn't match 'localhost'")))
    Dev Platform is down - start it before proceeding
Done.

This occurs despite the correct truststore being in place.

This is because the certificate we (the Jupyter server) receive should be unique to the host, and contain the DNS hostname (in this case of the egeria platforms).

To fix this requires that we dynamically generate certs as part of the deployment - or require each/every egeria platform to have a unique cert.

There is no longer seemingly any way in python 3.10 using the requests module to turn off just the hostname verification.

Until we have revisited the whole area of cert deployment, we will need to change the notebooks to explicitly disable certificate checking

[planetf1]

The 'best' approach is probably to switch to using a custom context for requests.

However this really requires a little refactoring to establish the context at the beginning of each notebook, and also to check that the persistent connections/context don't cause other issues.

Due to this in the short term I am making an explicit change to set 'verify=False' on all requests module calls. I'd hoped to avoid this, but at this time it seems the pragmatic approach until we can properly resolve deployment of certificates & potentially cleaner structuring of the python library code