I got the following error message:
An HTTP Client raised and unhandled exception: name 'FEATURE_OCSP_MODE' is not defined.
However, I cannot find any reference on the internet about this FEATURE_OCSP_MODE. I was calling describe_addresses() of boto3 using Pythan 3.8. The code was working until yesterday (8/24/2020).
I have just faced the same problem and the root cause was the snowflake-connector-python version as mentioned by Ben Campbell. In version v2.3.0 they accidentally removed the 'FEATURE_OCSP_MODE' constant but in version v2.3.1 they added it back.
The solution is to use snowflake-connector-python==2.3.1 or a newer one.
I rolled back to boto3==1.14.46 and snowflake-connector-python==2.2.10 as I was getting errors in both within Airflow 1.10.10 on Python 3.6.
This did the trick.
Related
As per document (https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/composing_a_customized_rhel_system_image/managing-repositories_composing-a-customized-rhel-system-image) tried to override the system repository with custom base url . But blueprint depsolve is showing error as below
##composer-cli blueprints depsolve Test1-blueprint
2022-06-09 08:06:58,841: Test1-blueprint: This system does not have any valid subscriptions. Subscribe it before specifying rhsm: true in sources.
And with next service restart osbuild-composer does not start
ERROR: Info Error: Get "http://localhost/api/v1/projects/source/info/appstream": dial unix /run/weldr/api.socket: connect: connection refused
Am I missing something here ?
Having all manner of issues with this myself. A trawl of my /var/log/messages file, and it looks like, for me at least, osbuild-composer is failing to start due to the non existence of /etc/osbuild-composer/osbuild-composer.toml. Actual error is permission denied, but it doesnt exist..
This is on RHEL 8.5, and just updated to 8.6 this morning, and same problem
/edit Ive removed everything, and reverted to using the lorax backend, as per chapter 2.2 in the doc linked (same one I was following). My 'composer-cli compose types' command now at least works. Fingers crossed..
I am currently having troubles with connecting my function trigger to an IoT-Hub, overnight it broke somehow.
Function version 4.
Node.js version 14 LTS.
First I got an error saying I have to use web.jobs version 4.3.0, I changed the host.json to include this
Then it has started giving me a runtime error which I don't know how to fix, the error:
I defined connection string in the portal which has the format
"Endpoint=sb//{iothub-ns-"somename"-"somenumber".servicebus.windows.net/}; SharedAccessKeyName={NameOfAccessKey};SharedAccessKey={TheKey};EntityPath={Name};
Lastly I tried removing the EntityPath which removed the error but then nothing came to the function anymore
Edit:
I got it fixed by changing function version to 3 and reverting the original Host.json to be "version": "[2.*, 3.0.0)".
I have no idea how the runtime version got changed, even when I made new functions they would also get this error. It is probably just something I have done within my workspace that is causing this.
while defining the connection string give the entity path as even hub compatible name
Endpoint=sb://<Event hub-compatible endpoint>.servicebus.windows.net/;EntityPath=<Event Hub compatible name>;SharedAccessKeyName=<keyName>;SharedAccessKey=<key>"
It's an open bug, reported here - https://github.com/Azure/azure-functions-core-tools/issues/3034
I can confirm the 3-replica cluster of h2o inside K3s is correctly deployed, as executing in the Python3 interpreter h2o.init(ip="x.x.x.x") works as expected. I followed the instructions noted here: https://www.h2o.ai/blog/running-h2o-cluster-on-a-kubernetes-cluster/
Nevertheless, I had to modify the service.yaml and comment out the line which says clusterIP: None, as K3s was complaining about something related to its inability to set the clusterIP to None. But even though, I can certify it is working correctly, and I am able to use an external IP to connect to the cluster.
If I try to load the dataset using the h2o cluster inside the K3s cluster using the exact same steps as described here http://docs.h2o.ai/h2o/latest-stable/h2o-docs/automl.html, this is the output that I get:
>>> train = h2o.import_file("https://s3.amazonaws.com/erin-data/higgs/higgs_train_10k.csv")
...
h2o.exceptions.H2OResponseError: Server error java.lang.IllegalArgumentException:
Error: Key not loaded: Key<Frame> https://s3.amazonaws.com/erin-data/higgs/higgs_train_10k.csv
Request: POST /3/ParseSetup
data: {'check_header': '0', 'source_frames': '["https://s3.amazonaws.com/erin-data/higgs/higgs_train_10k.csv"]'}
The same error occurs if I use the h2o.upoad_file("x.csv") method.
There is a clue about what may be happening here: Key not loaded: Key<Frame> while POSTing source frame through ParseSetup in H2O API call but I am not using curl, and I can not find any parameter that could help me overcome this issue: http://docs.h2o.ai/h2o/latest-stable/h2o-py/docs/h2o.html?highlight=import_file#h2o.import_file
I need to use the Python client inside the same K3s cluster due to different technical reasons, so I am not able to kick off nor Flow nor Firebug to know what may be happening.
I can confirm it is working correctly when I simply issue a h2o.init(), using the local Java instance.
UPDATE 1:
I have tried in different K3s clusters without success. I changed the service.yaml to a NodePort, and now this is the error traceback:
>>> train = h2o.import_file("https://s3.amazonaws.com/erin-data/higgs/higgs_train_10k.csv")
...
h2o.exceptions.H2OResponseError: Server error java.lang.IllegalArgumentException:
Error: Job is missing
Request: GET /3/Jobs/$03010a2a016132d4ffffffff$_a2366be93ec99a78d7bc161de8c54d67
UPDATE 2:
I have tried using different services (NodePort, LoadBalancer, ClusterIP) and none of them work. I also have tried using Minikube with the official image, and with a custom image made by me, without success. I suspect this is something related to either h2o itself, or the clustering between pods. I will keep digging and let's think there will be some gold in it.
UPDATE 3:
I also found out that the post about running H2O in Docker is really outdated https://www.h2o.ai/blog/h2o-docker/ nor is working the Dockerfile present at GitHub (I changed it to uncomment the ENTRYPOINT section without success): https://github.com/h2oai/h2o-3/blob/master/Dockerfile
Even though, I tried with the custom image I built for h2o-k8s and it is working seamlessly in pure Docker. I am wondering why it is still not working in K8s...
UPDATE 4:
I have tried modifying the environment variable called H2O_KUBERNETES_SERVICE_DNS without success.
In the meantime, the cluster started to be unavailable, that is, the readinessProbe's would not successfully complete. No matter what I change now, it does not work.
I spinned up a K3d cluster in local to see what happened, and surprisingly, the readinessProbe's were not failing, using v3.30.0.6. But now I started testing it with R instead of Python. I am glad I tried, because I may have pinpointed what was wrong. There is a version mismatch between the client and the server. So I updated accordingly the image to v3.30.0.1.
But now again, the readinessProbe is not working in my k3d cluster, so I am unable to test it.
It seems it is working now. R client version 3.30.0.1 with server version 3.30.0.1. Also tried with Python version 3.30.0.7 and server version 3.30.0.7 and it started working. Marvelous. The problem was caused by a version mismatch between the client and the server, as the python client was updated to 3.30.0.7 while the latest server for docker was 3.30.0.6.
I am using nodejs(0.12) and express (3.1.0).
My server keeps on running perfectly for some times but after some times, it start giving 400 (bad requests) and keep it giving 400 for next all requests
message: "Error: Bad Request
at SendStream.error (/var/www/storehippo/node_modules/express/node_modules/send/lib/send.js:145:16)
at SendStream.pipe (/var/www/storehippo/node_modules/express/node_modules/send/lib/send.js:298:31)
at Object.static (/var/www/storehippo/node_modules/express/node_modules/connect/lib/middleware/static.js:83:8)
at Object.handle (eval at eval at wrapHandle (/var/www/storehippo/node_modules/newrelic/lib/instrumentation/connect.js:1:0))
at /var/www/storehippo/node_modules/express/node_modules/connect/lib/proto.js:199:15
at /var/www/storehippo/node_modules/newrelic/lib/transaction/tracer/index.js:157:28
at Object.<anonymous> (/var/www/storehippo/dist/dist_17-09-2016_10:20:03/app/index.js:252:5)
at Object.handle (eval at eval at wrapHandle (/var/www/storehippo/node_modules/newrelic/lib/instrumentation/connect.js:1:0))
at /var/www/storehippo/node_modules/express/node_modules/connect/lib/proto.js:199:15
at /var/www/storehippo/node_modules/newrelic/lib/transaction/tracer/index.js:157:28"
For fixing it, I have to restart my server and not able to find root cause of it.
How to find root cause and resolve it ?
First, you are using Node 0.12 - currently the LTS version (recommended for all uses) is 4.5.0 and the Current version is 6.6.0 (6.x will become LTS next month). You may consider upgrading Node because you are using a very outdated version. The maintainence period of 0.12 will end in few months and then it will no longer get any updates, see: https://github.com/nodejs/LTS#lts_schedule
The Express module you use is also very outdated. The latest 3.x is I think 3.21.2 and the current version of Express is 4.14.0.
Now, if you want to find the problem then you should probably start from looking at the line 252 of /var/www/storehippo/dist/dist_17-09-2016_10:20:03/app/index.js because that seems to be the only line of your own code in that stack trace. The other lines seem to be all external modules, but it's also possible that the problem lies with one of those modules.
There may be a lot of reasons why your server behaves fine and then starts to misbehave - you may have some memory leak, some resources that are not freed and get exhausted after some time, you may change some state in your application that causes other requests to fail, etc.
Unfortunately you didn't include any info that would make it possible to help you with finding the problem.
While connecting to Cassandra 1.2.1 using Data-stax Java driver version 1.0.2, I am getting the error:
Exception in thread "main" java.lang.IllegalArgumentException: populate_io_cache_on_flush is not a column defined in this metadata
at com.datastax.driver.core.ColumnDefinitions.getIdx(ColumnDefinitions.java:268)
at com.datastax.driver.core.Row.isNull(Row.java:84)
at com.datastax.driver.core.TableMetadata$Options.<init>(TableMetadata.java:440)
at com.datastax.driver.core.TableMetadata.build(TableMetadata.java:107)
at com.datastax.driver.core.Metadata.buildTableMetadata(Metadata.java:124)
at com.datastax.driver.core.Metadata.rebuildSchema(Metadata.java:88)
at com.datastax.driver.core.ControlConnection.refreshSchema(ControlConnection.java:265)
at com.datastax.driver.core.ControlConnection.tryConnect(ControlConnection.java:220)
at below line:
cluster = Cluster.builder().addContactPoint("localhost").build();
I tried deleted folder \var\lib\cassandra and then restart the cassandra server too which means there is no previous data. The server starts without any error but I am still getting the above error when I am trying to connect to it.
Ohk. Just discovered that it went away when I use latest version of Cassandra(1.2.8). So it might be because of version incompatibility.