Closed usersink closed 1 year ago
Having manually built and run the image, I'm presented with this:
/usr/local/bin/jina executor --uses config.yml index
╭───────────────────────┬──────────────────────────────────╮
│ Argument │ Value │
├───────────────────────┼──────────────────────────────────┤
│ allow-concurrent │ False │
│ cli │ executor │
│ compression │ None │
│ connection-list │ None │
│ disable-auto-volume │ False │
│ docker-kwargs │ None │
│ entrypoint │ None │
│ env │ None │
│ env-from-secret │ None │
│ exit-on-exceptions │ [] │
│ extra-search-paths │ [] │
│ floating │ False │
│ force-network-mode │ AUTO │
│ force-update │ False │
│ gpus │ None │
│ grpc-channel-options │ None │
│ grpc-server-options │ None │
│ host │ ['0.0.0.0'] │
│ install-requirements │ False │
│ k8s-namespace │ None │
│ log-config │ default │
│ metrics │ False │
│ metrics-exporter-host │ None │
│ metrics-exporter-port │ None │
│ monitoring │ False │
│ name │ None │
│ native │ False │
│ no-reduce │ False │
│ noblock-on-start │ False │
│ output-array-type │ None │
│ pod-role │ WORKER │
│ polling │ ANY │
│ port │ [57350] │
│ port-monitoring │ [55345] │
│ prefer-platform │ None │
│ protocol │ [<ProtocolType.GRPC: 0>] │
│ py-modules │ None │
│ quiet │ False │
│ quiet-error │ False │
│ reload │ False │
│ replicas │ 1 │
│ retries │ -1 │
│ runtime-cls │ WorkerRuntime │
│ shard-id │ 0 │
│ shards │ 1 │
│ timeout-ctrl │ 60 │
│ timeout-ready │ 600000 │
│ timeout-send │ None │
│ traces-exporter-host │ None │
│ traces-exporter-port │ None │
│ tracing │ False │
│ uses │ config.yml │
│ uses-after-address │ None │
│ uses-before-address │ None │
│ uses-dynamic-batching │ None │
│ uses-metas │ None │
│ uses-requests │ None │
│ uses-with │ None │
│ volumes │ None │
│ workspace │ None │
│ workspace-id │ *0000000000000000000000000000000 │
╰───────────────────────┴──────────────────────────────────╯
CRITI… @15 can not load the executor from config.yml [04/26/23 14:45:41]
ERROR Pod@15 ImportError('can not import module from [04/26/23 14:45:41]
/workspace/microservice.py') during 'WorkerRuntime'
initialization
add "--quiet-error" to suppress the exception
details
Traceback (most recent call last):
File
"/usr/local/lib/python3.9/site-packages/jina/importe…
line 128, in _path_import
spec.loader.exec_module(module)
File "<frozen importlib._bootstrap_external>", line
850, in exec_module
File "<frozen importlib._bootstrap>", line 228, in
_call_with_frames_removed
File "/workspace/microservice.py", line 6, in
<module>
import scrapy
ModuleNotFoundError: No module named 'scrapy'
The above exception was the direct cause of the
following exception:
Traceback (most recent call last):
File
"/usr/local/lib/python3.9/site-packages/jina/orchest…
line 89, in run
runtime = AsyncNewLoopRuntime(
File
"/usr/local/lib/python3.9/site-packages/jina/serve/r…
line 81, in __init__
self._loop.run_until_complete(self.async_setup())
File
"/usr/local/lib/python3.9/asyncio/base_events.py",
line 647, in run_until_complete
return future.result()
File
"/usr/local/lib/python3.9/site-packages/jina/serve/r…
line 255, in async_setup
self.server = self._get_server()
File
"/usr/local/lib/python3.9/site-packages/jina/serve/r…
line 181, in _get_server
return GRPCServer(
File
"/usr/local/lib/python3.9/site-packages/jina/serve/r…
line 30, in __init__
super().__init__(**kwargs)
File
"/usr/local/lib/python3.9/site-packages/jina/serve/r…
line 54, in __init__
self._request_handler = req_handler or
self._get_request_handler()
File
"/usr/local/lib/python3.9/site-packages/jina/serve/r…
line 79, in _get_request_handler
return self.req_handler_cls(
File
"/usr/local/lib/python3.9/site-packages/jina/serve/r…
line 127, in __init__
self._load_executor(
File
"/usr/local/lib/python3.9/site-packages/jina/serve/r…
line 324, in _load_executor
self._executor: BaseExecutor =
BaseExecutor.load_config(
File
"/usr/local/lib/python3.9/site-packages/jina/jaml/__…
line 742, in load_config
load_py_modules(
File
"/usr/local/lib/python3.9/site-packages/jina/jaml/he…
line 285, in load_py_modules
PathImporter.add_modules(*mod)
File
"/usr/local/lib/python3.9/site-packages/jina/importe…
line 161, in add_modules
_path_import(complete_path(m))
File
"/usr/local/lib/python3.9/site-packages/jina/importe…
line 130, in _path_import
raise ImportError(f'can not import module from
{absolute_path}') from ex
ImportError: can not import module from
/workspace/microservice.py
Traceback (most recent call last):
File "/usr/local/bin/jina", line 8, in <module>
sys.exit(main())
File "/usr/local/lib/python3.9/site-packages/jina_cli/__init__.py", line 143, in main
getattr(api, args.cli.replace('-', '_'))(args)
File "/usr/local/lib/python3.9/site-packages/jina_cli/api.py", line 82, in executor
return pod(args)
File "/usr/local/lib/python3.9/site-packages/jina_cli/api.py", line 34, in pod
with PodFactory.build_pod(args) as p:
File "/usr/local/lib/python3.9/site-packages/jina/orchestrate/pods/__init__.py", line 194, in __enter__
return self.start()
File "/usr/local/lib/python3.9/site-packages/jina/orchestrate/pods/__init__.py", line 361, in start
self.wait_start_success()
File "/usr/local/lib/python3.9/site-packages/jina/orchestrate/pods/__init__.py", line 255, in wait_start_success
self._check_failed_to_start()
File "/usr/local/lib/python3.9/site-packages/jina/orchestrate/pods/__init__.py", line 240, in _check_failed_to_start
raise RuntimeFailToStart
jina.excepts.RuntimeFailToStart
The microservice doesn't feature a folder named 'workspace' but the same error message appears even when I build and run the image in a home folder named as such. Using 3.5 model, if it makes a difference.
The problem here is that scrapy
is not properly installed in the Dockerfile
Thanks for the quick reply!
Should I assume the missing package is a consequence of using model 3.5?
The docker message was indeed a permissions issue, and it was easy enough to resolve. With a fresh install of the Docker Engine, the root account had ownership of /var/run/docker.sock, rather than my user account. :disappointed:
To fix:
sudo ls -la /var/run/docker.sock
sudo chown [username]:docker /var/run/docker.sock
Source: https://phoenixnap.com/kb/cannot-connect-to-the-docker-daemon-error
Thanks for the quick reply!
Should I assume the missing package is a consequence of using model 3.5?
The docker message was indeed a permissions issue, and it was easy enough to resolve. With a fresh install of the Docker Engine, the root account had ownership of /var/run/docker.sock, rather than my user account. 😞
To fix:
- Check ownership for the Docker Unix socket:
sudo ls -la /var/run/docker.sock
- If necessary, grant the user ownership with:
sudo chown [username]:docker /var/run/docker.sock
Source: https://phoenixnap.com/kb/cannot-connect-to-the-docker-daemon-error
This I am not sure I can answer, @joschkabraun or @florian-hoenicke may be more fit to answer that. For now you may be able to edit it urself
Should I assume the missing package is a consequence of using model 3.5?
Yes that can be. GPT-4 is much more powerful. But we are improving our package currently to not allow passing of such scenarios. For now I can only suggest to rerun the execution with all the improvements which happened in the meantime.
Thanks for the update.
I love the premise of gptdeploy, and I'm grateful that you've released it, but I'd go as far as to say it's not quite usable with 3.5. I'm yet to get anything running in 6 or 7 attempts now, as there are issues with EVERY build.
Here's another:
gptdeploy run --path /home/x/microservice/d2
Run a jina flow locally
Traceback (most recent call last):
File "/home/x/.local/bin/gptdeploy", line 8, in <module>
sys.exit(main())
File "/home/x/.local/lib/python3.10/site-packages/click/core.py", line 1128, in __call__
return self.main(*args, **kwargs)
File "/home/x/.local/lib/python3.10/site-packages/click/core.py", line 1053, in main
rv = self.invoke(ctx)
File "/home/x/.local/lib/python3.10/site-packages/click/core.py", line 1659, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "/home/x/.local/lib/python3.10/site-packages/click/core.py", line 1395, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "/home/x/.local/lib/python3.10/site-packages/click/core.py", line 754, in invoke
return __callback(*args, **kwargs)
File "/home/x/.local/lib/python3.10/site-packages/src/cli.py", line 39, in wrapper
return func(*args, **kwargs)
File "/home/x/.local/lib/python3.10/site-packages/src/cli.py", line 84, in run
Runner().run(path)
File "/home/x/.local/lib/python3.10/site-packages/src/options/run/runner.py", line 10, in run
run_locally(executor_name, latest_version_path)
File "/home/x/.local/lib/python3.10/site-packages/src/apis/jina_cloud.py", line 203, in run_locally
flow = Flow.load_config(full_flow_path)
File "/home/x/.local/lib/python3.10/site-packages/jina/jaml/__init__.py", line 695, in load_config
stream, s_path = parse_config_source(
File "/home/x/.local/lib/python3.10/site-packages/jina/jaml/helper.py", line 191, in parse_config_source
PathImporter.add_modules(module_name)
File "/home/x/.local/lib/python3.10/site-packages/jina/importer.py", line 161, in add_modules
_path_import(complete_path(m))
File "/home/x/.local/lib/python3.10/site-packages/jina/jaml/helper.py", line 229, in complete_path
raise FileNotFoundError(f'can not find {path}')
FileNotFoundError: can not find /home/x/microservice/d2/D2DiagramCreatorExecutor8168214/1_"GPT-3 5 Turbo API"_"Diagrams"/v8/flow
I've now tried a few versions of Docker 20 and 23 and can't seem to launch microservices, due to this error:
Confirmed Docker daemon running
GPTDeploy disagrees
Installing locally fails, as you said it would.
Any ideas what may be causing this? I couldn't find any mention of it before now, and I'd really like to try out my shiny new microservice :) Any pointers would be greatly appreciated. Thanks!