Not working at all

[DjinNO]

Helm values:

global:
  veleroNamespace: velero

uiIngress:
  enabled: true
  ingressClassName: nginx
  metadata:
    annotations: []
  spec:
    tls:
    - hosts:
      - velero-ui.domain.com
      secretName: velero-ui-tls

Result: Unable to login, login button not working

Error in web ui:

❯ velero version Client: Version: v1.14.0 Git commit: none Server: Version: v1.14.0

velero ui: Helm release 0.1.12

[davideserio]

Can you add these lines in your values-override.yaml?

uiNp:
  enabled: false

Let me know whether the installation was successful or not.

[DjinNO]

Can you add these lines in your values-override.yaml?

uiNp:
  enabled: false

Let me know whether the installation was successful or not.

I'm already tried it (because I don't need NodePort) and had same issue

[davideserio]

Can you share the whole values-override.yaml file? Remove any sensitive information

[DjinNO]

global:
  veleroNamespace: velero

uiNp:
  enabled: false

uiIngress:
  enabled: true
  ingressClassName: nginx
  metadata:
    annotations: []
  spec:
    tls:
    - hosts:
      - velero-ui.domain.com
      secretName: velero-ui-tls

I have nothing else, only this config

[davideserio]

This configuration is working. Can you verify the data in the config map velero-ui-config? If the url in NEXT_PUBLIC_VELERO_API_URL_1 and NEXT_PUBLIC_VELERO_API_WS_1 are correct, try restarting the velero-ui deployment.

[DjinNO]

data:
  NEXT_PUBLIC_REFRESH_DATATABLE_AFTER: "1500"
  NEXT_PUBLIC_REFRESH_RECENT: "5000"
  NEXT_PUBLIC_VELERO_API_NAME_1: <cluster-name>
  NEXT_PUBLIC_VELERO_API_URL_1: http://:30001/api
  NEXT_PUBLIC_VELERO_API_WS_1: ws://:30001

Of Course I tried to install velero-ui multiple times I'm using port-forward to access UI

[davideserio]

The configmap is wrong. I tried the your values-override.yaml and it works. Can you try to install from scratch and verify the contents of the configmap? It is important to disable uiNp if it is not used

uiNp:
  enabled: false

[DjinNO]

From scratch:

My vaules:

global:
  veleroNamespace: velero

uiNp:
  enabled: false

uiIngress:
  enabled: true
  ingressClassName: nginx
  metadata:
    annotations: []
  spec:
    tls:
    - hosts:
      - velero-ui.domain.com
      secretName: velero-ui-tls

Configmap:

❯ k get configmaps  -o yaml velero-ui-config
apiVersion: v1
data:
  NEXT_PUBLIC_REFRESH_DATATABLE_AFTER: "1500"
  NEXT_PUBLIC_REFRESH_RECENT: "5000"
  NEXT_PUBLIC_VELERO_API_NAME_1: <cluster-name>
  NEXT_PUBLIC_VELERO_API_URL_1: https://velero-ui.domain.com/api
  NEXT_PUBLIC_VELERO_API_WS_1: wss://velero-ui.domain.com

The same problem. I also tried to set global.clusterName: velero

logs from api pod: k logs vui-api-79d6cb648d-q4tt9 | grep -i error | c

INFO      [Env creation] key: SECURITY_TOKEN_KEY value:                          validation:ERROR NOT A VALID SECRET KEY
INFO      [Env creation] key: SECURITY_REFRESH_TOKEN_KEY value:                          validation:ERROR NOT A VALID SECRET KEY
(trapped) error reading bcrypt version
AttributeError: module 'bcrypt' has no attribute '__about__'
ERROR:    2024-07-16 09:42:51.291 [helper.velero_client] ./velero-client/dl/velero-v1.12.2-linux-amd64.tar.gz is not a valid tarball file.
ERROR:    2024-07-16 09:42:51.291 [helper.velero_client] Init velero client failed.
ERROR:    2024-07-16 09:42:51.292 [helper.velero_client] E=Error extract velero, F=/app/helpers/velero_client.py, L=245
ERROR:    2024-07-16 09:42:51.292 [helper.velero_client] an forced exit code(100) is called
ERROR:    2024-07-16 09:42:51.329 [helper.velero_client] ./velero-client/dl/velero-v1.12.2-linux-amd64.tar.gz is not a valid tarball file.
ERROR:    2024-07-16 09:42:51.329 [helper.velero_client] Init velero client failed.
ERROR:    2024-07-16 09:42:51.330 [helper.velero_client] E=Error extract velero, F=/app/helpers/velero_client.py, L=245
ERROR:    2024-07-16 09:42:51.330 [helper.velero_client] an forced exit code(100) is called
ERROR:    2024-07-16 09:42:51.412 [helper.velero_client] Init velero client failed.
ERROR:    2024-07-16 09:42:51.413 [helper.velero_client] E=Compressed file ended before the end-of-stream marker was reached, F=/usr/local/lib/python3.10/gzip.py, L=507
ERROR:    2024-07-16 09:42:51.413 [helper.velero_client] an forced exit code(100) is called

[davideserio]

Now the config map has the correct syntax, but you should correctly configure the url velero-ui.domain.com . It also verifies that the velero api can connect to the Internet to download the velero client.

[DjinNO]

Now the config map has the correct syntax, but you should correctly configure the url velero-ui.domain.com . It also verifies that the velero api can connect to the Internet to download the velero client.

What if I wouldn't like to expose velero ui? It's very strange approach

[DjinNO]

global:
  veleroNamespace: velero
  clusterName: velero

uiNp:
  enabled: true

uiIngress:
  enabled: false

This configuration doesn't work either :(

[davideserio]

Installing via Helm allows you to configure access to the UI using either NodePort or Ingress. That said, I don't see anything unusual or strange about this approach.

As stated in the example file, if you use NodePort, you must also configure the ip, apiPort, and uiPort. If you use Ingress, you need to use a valid domain. This domain does not necessarily have to be exposed on the internet; you can also use internal resolution domains.

[DjinNO]

So, why my config doesn't work? velero-ui.domain.com - valid domain

[davideserio]

The configuration will work if the domain "velero-ui.domain.com" is correctly resolved within your internal network when traffic is directed towards the Kubernetes Ingress. This issue is not related to the specific application (Velero UI) but rather to the structure and setup of the network where Kubernetes is installed. If you are testing on k8s local solutions, it might be better to use NodePort instead of Ingress. NodePort exposes the service on a static port on the node's IP address, which can simplify access during development and testing on local environments.

[DjinNO]

The configuration will work if the domain "velero-ui.domain.com" is correctly resolved within your internal network when traffic is directed towards the Kubernetes Ingress. This issue is not related to the specific application (Velero UI) but rather to the structure and setup of the network where Kubernetes is installed. If you are testing on k8s local solutions, it might be better to use NodePort instead of Ingress. NodePort exposes the service on a static port on the node's IP address, which can simplify access during development and testing on local environments.

Why should it resolve itself? This is a very strange approach. I can't recall any product that requires this, especially in a Kubernetes environment.

[davideserio]

The project consists of several modules: UI, API, and Watchdog. The UI communicates with the API (which is a separate project also used by other projects) that is exposed at velero-ui-domain.com/api. If this domain is unreachable, the UI cannot communicate with the API. So to solve the problem you either use a valid domain or nodeport with all the configuration parameters.

[DjinNO]

The project consists of several modules: UI, API, and Watchdog. The UI communicates with the API (which is a separate project also used by other projects) that is exposed at velero-ui-domain.com/api. If this domain is unreachable, the UI cannot communicate with the API. So to solve the problem you either use a valid domain or nodeport with all the configuration parameters.

Why I can not use k8s Service?

[davideserio]

You can use whichever method you prefer. The Helm chart is configured to support installation via ingress or node port. If these options don't meet your requirements, feel free to modify the configuration as needed.

[DjinNO]

Why does the service need to resolve itself through the ingress? It can do this through Service, but it doesn't work.

What if I want to use something other than an ingress controller, like an istio gateway? The Service resource should be configured separately from the ingress as they are two different entities.

If I were able to run your project, I would gladly make a pull request with corrections to the Helm chart, but for now, your project is completely non-functional and you do not provide a clear answer as to why it needs a domain name inside a private network when there is a k8s Service.

[davideserio]

As mentioned earlier, from a technical standpoint it's crucial that the Next.js frontend effectively communicates with the FastAPI backend. If the frontend in the browser cannot reach the API endpoints, the application will not function correctly. The frontend interacts directly with the backend API through HTTP requests (such as GET, POST, etc.).

It's imperative that these API endpoints are accessible from the client's browser. This requires proper exposure and configuration of the API endpoints to ensure that requests from the frontend can reach them and receive valid responses.

If you're deploying with a domain, ensure it resolves to ingresses that route requests to the API. Alternatively, if using NodePort, ensure the APIs are exposed and reachable from client browsers.

[ithesadson]

Installing via Helm allows you to configure access to the UI using either NodePort or Ingress. That said, I don't see anything unusual or strange about this approach.

As stated in the example file, if you use NodePort, you must also configure the ip, apiPort, and uiPort. If you use Ingress, you need to use a valid domain. This domain does not necessarily have to be exposed on the internet; you can also use internal resolution domains.

"I disagree with this idea. Users may optionally want to disable both NodePort and Ingress and define their own Ingress via Rancher, for example. I believe users should have the option to disable both as needed."