vault api call failed make onyxia unavailable

[alexisdondon]

If vault is non reachable or the auth/cors is failing, we would like to have the secrets part of the ui only to be degraded but we would want to be able to launch a service at least with no secret injection.

The application should work even in degraded mode.

[fcomte]

Yes this is a very important improvement. But it's not very easy how to handle this kind of scenario. Some important information are inside Vault like the password of all services..

[garronej]

I mean, we can fallback to local storage. I's already possible to use onyxia without vault using the mock.

we could falback to that if vault seems to be down.

[fcomte]

I am not sure we should fallback to local storage. I guess steps to improve are :

1. be resilient at application startup time to failed vault request ( they are only use to get dark mode or not , the current project which not very important )
2. when starting a new service we should perhaps leave all blank
3. making charts compliant with blank password for example ..and the chart fall back to a default creation password.

[alexisdondon]

Hi, i understand that:

• every services in NOTES.txt helm chart // readme in the ui should reflect the username password to use in order to retrieve for a running service the username password to be used.
  • then in a degraded mode this feature is enough without storage to reflect the username/password to be used.
• at a start of a service and especially a focus on "interactive services catalog" i would like to launch this kind of service even if vault is down.
• if vault is up then all should work as today.
• if vault is unreacheable and the main password not known we could:
  • option 1 :leave blank and the chart could handle this (previous proposition)
  • option 2: generate a password with no storage by the ui (the same as previous option but the logic is the ui instead of the helm chart)
  • option 3: leave blank and let the user put the password but we need a kind of validation (when one click on launch the ui should check that password is not empty and warn the user) or error handling in the api reflect by the ui.

The quickest is option1 and 2 with the benefits to put some kind of rules on the password. The option that let the user more aware of this degraded mode is the option3, with more work to enforce validation and rules.

[garronej]

Hi @alexisdondon,

even if vault is down [...] if vault is unreachable

Incorporating distinct code to handle a situation where Vault is offline introduces an additional layer of complexity into the system. As I understand it, we're dealing with two potential scenarios here: either you don't have Vault integrated with Onyxia, or you do and it's presumed to be consistently operational.

Could you provide more context to your situation? It would be particularly helpful to understand why your Vault isn't perpetually accessible.

[alexisdondon]

The service could be down for maintenance or network problem and thinking about an application that should work in degraded situation i prefer that onyxia user can launch interactive service or other service, without injecting vault parameter instead of doing nothing because of the onyxia ui behavior.