Repo Architecture

[rayzhou2017]

The repo component consists of three parts: repo database, repo storage and repo service. The user of repo communicates through repo service which is the micro service of OpenPitrix. The repo service manages the lifecycle of repos such as create a repo, update a repo etc. The repo table stores the metedata of each repo. Please check the database design. The repos can be from multiple sites. Actually repo storage is not part of the repo component. We can use any repo on the internet such as Helm repo https://kubernetes-charts.storage.googleapis.com.

New diagram:

link

[rayzhou2017]

Example: create a repo via UI
OpenPitrix operator navigates to the repo management. Click 'Create Repo', input name, description, url, credential to access the repo site if required, etc. The system will check to see if the url is valid and its accessibility. Once passed the check, the system will populate the repo info into database.

[rayzhou2017]

1. Operator can configure public repos for all end users to use.
2. Developer can create her/his own repos to use by herself/himself. She/he also can set the visibility of the repos to other users to use.
3. In other words, OpenPitrix must support various kinds of marketplaces, such as public marketplace, private marketplace, customised marketplace.

[Hevienz]

When OpenPitrix is being installed, Operator will get a web page to create a public repo, And this repo is used for all the user.

[Hevienz]

When an user is logining in the system, she will access these pages to serve herself:

A user can access theses repo that which is public or which is created by herself or which label is matched with user repo selector.

And the structure in database is just like this:

[Hevienz]

User can manage the repo which is owned by himself and he can attach labels to the repo, then other user can access the repo if his user repo selector is matched with the label attached to that repo.

So the user's table structure need to have a many-to-many relationship that related with user repo selector, and the ER graph for user is shown as below.

[zheng1]

Operator/Developer create repo

1. select runtime qingcloud/kubernetes
2. input repo URL
3. select repo mode rw/ro, at the first phase, only qingstor URL support rw mode
4. input credential if necessary
5. submit form, repo service validate the URL and mode.
6. set repo labels

Operator push sync repo task to queue(only helm repo can be sync), indexer service will pop task from queue.

1. get index from repo
2. insert app if not exists
3. insert app_version if not exists

Operator/Developer push sync repo task to queue(only helm repo can be sync), indexer service will pop task from queue.

1. get index from repo
2. insert app if not exists
3. insert app_version if not exists