Sammy Kerata Oina 722b463b6a NOISSUE - Use a single listener for logs and events (#82)
* add handler

Signed-off-by: SammyOina <sammyoina@gmail.com>

* Refactor gRPC and Protobuf integration for manager service

- Shifted Protobuf message definitions to a separate package `pkg/manager`.
- Updated references throughout the codebase to import and use the new package for gRPC service definitions.
- Enhanced AgentLog message with additional fields `level` and `timestamp`.
- Removed direct dependencies on old Protobuf-generated types in favor of the new package.
- Deleted obsolete Protobuf-generated files as they are now superseded by the new `pkg/manager`.
- Streamlined event publishing and gRPC handling in the manager service to use the updated Protobuf messages.

This refactoring improves modularity by centralizing Protobuf message definitions and decouples internal representation from the gRPC interface, aligning with best practices for microservice architecture. Additionally, the enriched logging structure paves the way for more detailed and fine-grained log analysis.

Signed-off-by: SammyOina <sammyoina@gmail.com>

* Refactor vsock event/log handling and config

Streamlined event and log services in the manager by moving vsock listening functions out of `managerService` initialization and into dedicated `RetrieveAgentEventsLogs` methods. This change decouples the manager service creation from the actual start of log listening, adding clarity and flexibility in service management. Also moved logging middleware invocation outside of network handling loops to avoid unnecessary overhead.

Additionally, the agent's vsock port configuration is now dynamically passed to the `New` function in the `events` package instead of relying on a hardcoded constant, allowing for greater configurability and testability.

Finally, updated message structures for event and log sending to conform with the `ClientStreamMessage` definitions. These modifications should improve parsing and handling consistency and prepare our system for future enhancements related to inter-process communication.

Signed-off-by: SammyOina <sammyoina@gmail.com>

* fix linting errors

Signed-off-by: SammyOina <sammyoina@gmail.com>

* correct path to generated files

Signed-off-by: SammyOina <sammyoina@gmail.com>

* fix comments

Signed-off-by: SammyOina <sammyoina@gmail.com>

* remove uneccessary comments

Signed-off-by: SammyOina <sammyoina@gmail.com>

---------

Signed-off-by: SammyOina <sammyoina@gmail.com>
2024-02-15 17:02:05 +01:00
2024-02-07 16:16:27 +01:00
2024-01-09 19:56:31 +01:00
2023-03-27 13:56:05 +02:00
2024-01-25 15:29:16 +01:00

Cocos AI

Cocos AI (Confdential Computing System for AI/ML) is a platform for secure multiparty computation (SMPC) based on the Confidential Computing and Trusted Execution Environments (TEEs).

With Cocos AI it becomes possible to run AI/ML workloads on combined datasets from multiple organizations while guaranteeing the privacy and security of the data and the algorithms. Data is always encrypted, protected by hardware secure enclaves (Trusted Execution Environments), attested via secure remote attestation protocols, and invisible to cloud processors or any other 3rd party to which computation is offloaded.

Usage

The quickest way to start using Cocos is via the CLI. The latest version can be downloaded from the official releases page.

It can also be built and used from the project's root directory:

make cli
./build/cocos-cli version

Additional details on using the CLI can be found in the CLI documentation.

Documentation

Official documentation is hosted at [Cocos official docs page][docs]. Documentation is auto-generated, checkout the instructions on official docs repository.

License

Cocos AI is a proprietary product created by Ultraviolet company.

S
Description
Cocos AI - Confidential Computing System for AI
Readme 14 MiB
Languages
Go 95.4%
Shell 2.2%
Makefile 1.7%
Python 0.4%
Rust 0.3%