neongeckocom / neon-diana-utils Goto Github PK

Objective

Support deployment of packages to Kubernetes

Initial Implementation

• Initial PoC conversion of deployed API server to K8s
• Update and add util methods to diana entry point to generate K8s configs
• Refactoring of config to ConfigMap/Secrets instead of nfs shares
• Implement and document or automate proxy config for k8s

Objective

Add a default page to return when the root backend domain is accessed

Initial Implementation Requirements

• static page with links to DIANA repository and neon.ai website (others?)
• Add default ingress route for / to return static webpage

Other Considerations

No response

Objective

Add HANA frontend configuration to CLI.

Initial Implementation Requirements

• Add hana configuration to CLI flow

Other Considerations

No response

Objective

Add a unified web interface for managing a Hub deployment serving multiple clients. This would ideally be a standalone container in a new repository.

Initial Implementation Requirements

• Configuration UI for creating and updating deployments (equivalent to current CLI process)
• UI to monitor/explore running services
• Method for configuring networking for local access to HTTP services
• (optional) method for creating Node boot disks
• (optional) method for auto-updating Helm charts and Diana configs

Other Considerations

This may be split into a few separate projects

Objective

Add (optional) whisper STT to the backend deployments

Initial Implementation Requirements

• Whisper STT container with gradio interface

Other Considerations

• Consider replacing default nemo with whisper (or run both?)

Objective

Add documentation for ingress-nginx Proxy config and routing requirements for MQ.

Initial Implementation Requirements

• Document cases where proxy config is necessary or not
• Add note about MQ requirements with proxy headers

Other Considerations

• Default use proxy?
• Default to not use external MQ connections?

Objective

Currently, updates are performed either manually or by re-configuring Helm charts from scratch. A better method would update existing configurations in-place.

Initial Implementation Requirements

• Method to update RabbitMQ configuration, adding new users and vhosts as necessary
• Method to update yaml configurations (diana.yaml, neon.yaml, chatbots.yaml)
• Method to update chart dependencies in Chart.yaml

Other Considerations

An alternate (maybe easier?) way to look at this would be to load default values from an existing deployment while configuring new charts from scratch.

Automate configuration of RabbitMQ and MQ Services on a new system

Objective

Currently, the neon_speech container will not run without an internet connection. All of the other services load without one, but since neon_speech pulls down a model from HuggingFace on init, the container consistently fails.

Initial Implementation Requirements

Most likely path forward is either to build an image with the model baked in (seems pretty large) or to set the cache directory as a PVC, allowing you to run offline as long as you are online long enough to get the model into a persistent cache.

Other Considerations

No response

Objective

Currently, many services interact with each other, so viewing synchronized logs is sometimes necessary. Additionally, we have no documented tools for viewing container logs in k8s (k9s is not really a log viewer).

Initial Implementation Requirements

• Service or workflow to view multiple container logs in real-time
• Method for viewing multiple container logs from a specific time range

Other Considerations

• @NeonKirill suggested using https://develop.sentry.dev/self-hosted/
• I have heard of but not deeply researched Graylog
• Any solution will ideally work in k8s and Docker deployments

Objective

Define a method for provisioning a device as a Diana server with minimal manual setup. This will also require some UI for setting configuration after installation.

Initial Implementation Requirements

• Installable image or simple script for performing a basic setup/configuration
• Instructions for configuration or #66 completed for user-provided config

Other Considerations

• This could be a debos image with services running as system services rather than containers
• Could this use some tool like ansible or terraform?

Objective

Currently, RabbitMQ isn't restarted on upgrade so configuration isn't automatically updated.

Initial Implementation Requirements

• Add something to the RabbitMQ deployment spec to force restarting when a new diana-backend chart is applied

Other Considerations

No response