New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Repo Architecture #96

Closed
rayzhou2017 opened this Issue Jan 5, 2018 · 6 comments

Comments

Projects
3 participants
@rayzhou2017
Copy link
Contributor

rayzhou2017 commented Jan 5, 2018

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.

screen shot 2018-01-05 at 2 12 54 pm

New diagram:
repo
link

@rayzhou2017 rayzhou2017 added the design label Jan 5, 2018

@rayzhou2017

This comment has been minimized.

Copy link
Contributor Author

rayzhou2017 commented Jan 5, 2018

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 rayzhou2017 added the repo label Jan 8, 2018

@rayzhou2017 rayzhou2017 changed the title repo architecture Repo Architecture Jan 17, 2018

@rayzhou2017

This comment has been minimized.

Copy link
Contributor Author

rayzhou2017 commented Jan 17, 2018

  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

This comment has been minimized.

Copy link
Contributor

Hevienz commented Jan 23, 2018

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.
image

@Hevienz

This comment has been minimized.

Copy link
Contributor

Hevienz commented Jan 23, 2018

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

image

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:

image

@Hevienz

This comment has been minimized.

Copy link
Contributor

Hevienz commented Jan 24, 2018

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.

image

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.

image

@zheng1

This comment has been minimized.

Copy link
Member

zheng1 commented Jan 25, 2018

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

@zheng1 zheng1 added this to In progress in Repo Jan 29, 2018

@zheng1 zheng1 closed this Aug 23, 2018

Repo automation moved this from In progress to Done Aug 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment