You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently one needs to have a config file, e.g. ragna.toml, to serve Ragna (ragna ui and ragna api). Meaning, users will have to either run the interactive wizard to create one (ragna init) or copy and paste an example from our documentation. That is sub-optimal user experience, because extra steps are required (see #180).
However, this is only an issue for serving locally. When using docker, we have solved this by providing a default configuration. We do this, because it involves even more steps to be able to use a user created configuration inside a docker container.
We could bring the same UX from the docker image to local deployment as well. Meaning
We do provide a default config if -c / --config is not supplied.
We use all builtin source storages and assistants by default.
Since in most cases users will not have satisfied the requirements of all components, we change the default to --ignore-unavailable-components.
Point 2. and 3. is exactly what we already do for docker:
One valid question here is what has changed between now and #180, which asked for roughly the same but was closed. The reasoning was that it is hard to explain how to satisfy the extra requirements, e.g. setting environment variables. With the introduction of --ignore-unavailable-components we are slightly better now by printing some minimal information during startup:
f"Ignoring {component.display_name()}, because it is not available."
)
One solution here would be to just preface every startup with the equivalent of ragna check before the API or UI is started. With that the user should have enough information even when they haven't explicitly created the configuration themselves.
Thoughts?
The text was updated successfully, but these errors were encountered:
Currently one needs to have a config file, e.g.
ragna.toml
, to serve Ragna (ragna ui
andragna api
). Meaning, users will have to either run the interactive wizard to create one (ragna init
) or copy and paste an example from our documentation. That is sub-optimal user experience, because extra steps are required (see #180).However, this is only an issue for serving locally. When using docker, we have solved this by providing a default configuration. We do this, because it involves even more steps to be able to use a user created configuration inside a docker container.
We could bring the same UX from the docker image to local deployment as well. Meaning
-c
/--config
is not supplied.--ignore-unavailable-components
.Point 2. and 3. is exactly what we already do for docker:
ragna/ragna-docker.toml
Lines 4 to 28 in 55f7fc5
ragna/Dockerfile
Lines 32 to 33 in 55f7fc5
One valid question here is what has changed between now and #180, which asked for roughly the same but was closed. The reasoning was that it is hard to explain how to satisfy the extra requirements, e.g. setting environment variables. With the introduction of
--ignore-unavailable-components
we are slightly better now by printing some minimal information during startup:ragna/ragna/deploy/_api/core.py
Lines 43 to 46 in 55f7fc5
One solution here would be to just preface every startup with the equivalent of
ragna check
before the API or UI is started. With that the user should have enough information even when they haven't explicitly created the configuration themselves.Thoughts?
The text was updated successfully, but these errors were encountered: