feat: (Catalog) Assets for simple rag application

[yussufsh]

Added two new directories as per #636
This may change in the future, but we are defining the specs for implementing Architectures and Services APIs.

Note: OpenShift runtime specs are not tested yet, just divided based on Bob's suggestion. We need to determine how to deploy charts for each service there.

[yussufsh]

assets/
├── architectures/              # NEW: Architecture definitions
│   └── rag/
│       └── metadata.yaml       # Lists services, no templates
│
├── services/                   # NEW: Reusable service definitions
│   ├── chat/                   # Deployable service
│   │   ├── metadata.yaml       # Service info + dependencies
│   │   ├── podman/
│   │   │   ├── metadata.yaml   # Runtime config
│   │   │   ├── values.yaml     # Default values
│   │   │   ├── steps/          # Post-deployment guidance
│   │   │   │   ├── info.md
│   │   │   │   ├── next.md
│   │   │   │   └── vars_file.yaml
│   │   │   └── templates/      # Pod templates
│   │   │       └── chat-bot.yaml.tmpl
│   │   └── openshift/
│   │       └── ...
│   │
│   ├── digitization/           # Deployable service
│   ├── summarization/          # Deployable service
│   ├── opensearch/             # Infrastructure service
│   ├── instruct/               # Infrastructure service (AI model)
│   ├── embedding/              # Infrastructure service (AI model)
│   └── reranker/               # Infrastructure service (AI model)
│
└── applications/               # LEGACY: Existing monolithic apps
    └── rag/                    # Kept for backward compatibility

[mkumatag]

OpenShift runtime specs are not tested yet, just divided based on Bob's suggestion. We need to determine how to deploy charts for each service there.

how about podman runtime? I'm wondering if we can test with podman which is an low hanging thing see how that works with this new prototype?

[yussufsh]

OpenShift runtime specs are not tested yet, just divided based on Bob's suggestion. We need to determine how to deploy charts for each service there.

how about podman runtime? I'm wondering if we can test with podman which is an low hanging thing see how that works with this new prototype?

I have started working on the code and verified that the image, model and template commands are working fine.. Trying deployment but wanted to start putting the artifacts for review.
Refer: main...yussufsh:project-ai-services:reuse

[mkumatag]

I have started working on the code and verified that the image, model and template commands are working fine.. Trying deployment but wanted to start putting the artifacts for review.

cool, let us try with a bare minimal services just for a PoC and see this goes..

[yussufsh]

I have started working on the code and verified that the image, model and template commands are working fine.. Trying deployment but wanted to start putting the artifacts for review.

cool, let us try with a bare minimal services just for a PoC and see this goes..

@mkumatag I have done deployments using architecture and individual services by reusing most of the existing code.
Here are the logs for rag-dev and summarize service.

Draft code can be referred from (https://github.com/yussufsh/project-ai-services/tree/apis_reuse)

Tested application create, delete(no change), template, image, model flow. The info sub-command is pending and should work with validating the info.md file and small code change.

[yussufsh]

I have updated the specs to remove podTemplateExecutions from runtime metadata.
@mkumatag @mayuka-c @Shubhamag12 ptal.

[mkumatag]

and also explore how can we use same service instruct with different variants like cpu, spyre etc... pushing as a param to the each service

[yussufsh]

and also explore how can we use same service instruct with different variants like cpu, spyre etc... pushing as a param to the each service

This will require little more work since we need to propagate the values from bottom to top service. ie. chat service should know the value of instruct cpu param.
Planning to implement it in the coming PRs.

[mayuka-c]

I have updated the specs to remove podTemplateExecutions from runtime metadata. @mkumatag @mayuka-c @Shubhamag12 ptal.

Just a query, now without podTemplateExecutions, within a service lets say digitization has multiple pods like digitize-service and postgres, then you end up deploying both concurrently right?

I hope that is fine

[yussufsh]

I have updated the specs to remove podTemplateExecutions from runtime metadata. @mkumatag @mayuka-c @Shubhamag12 ptal.

Just a query, now without podTemplateExecutions, within a service lets say digitization has multiple pods like digitize-service and postgres, then you end up deploying both concurrently right?

I hope that is fine

We should have some reconciliation logic. eg: if digitization needs a DB connection to start, it should wait for it in a loop. If not, the whole service will run only when all the pods are up.
Otherwise, reintroducing layers makes sense @mkumatag ?

[mkumatag]

Just a query, now without podTemplateExecutions, within a service lets say digitization has multiple pods like digitize-service and postgres, then you end up deploying both concurrently right?

I hope that is fine

ideally we need to find a way to control them placing the pods or wait in pod for the DB or have some enough restart counts set etc. how we do it in the openshift like env, this podTemplateExecutions will just add an extra complexity and which may not be required is what my opinion.. will revisit this later if needed :) for now may be not!

[mayuka-c]

Just a query,
We do have seperate services like summarize and summarization?. Also same thing for digitize?
Any reason for this?

[mkumatag]

IMO: let us merge the bare minimal things and increment things based on the learning otherwise we will just sit on these proposals, PRs forever :)

[yussufsh]

Just a query, We do have seperate services like summarize and summarization?. Also same thing for digitize? Any reason for this?

Ah good eyes... I see two dirs. The name was changed during implementation, not deleted afterward. Will fix this.

[mayuka-c]

LGTM

Merging this based on another approval. Resolved all the comments.

[mkumatag]

We can think of moving this from assets/services/ directory toassets/vdb/ as well, later.

Please don't depend on the directory conventions, let us add any required details into the spec and use them