Feature specification: https://docs.google.com/document/d/1jLOQRP6ffRJl2oo7QIALguKai5A3bH_eHpn9530r094/edit#heading=h.wlc81gyew8l

1. Application management

• create application (workloads/traits auto-rendering) kubevela/kubevela#680 @majian159 @zzxwill

  • Implement API for generating OpenAPI schema for definition @zzxwill
  • create application @zzxwill
    • validate inputed parameters of workload/traits by their type
    • Dashboard: Display selected workload type or trait should show in the dropdown kubevela/kubevela#1069
    • [Dashboard] "新增" in workload type settings should be in English #76
  • Application creation OpenAPI based on new Application object @zzxwill

• list all applications @majian159 @zzxwill

• application operations

  • docker logs for application

2. Capabilities

• Workload

• list WorkloadDefinitions @sunny0826 @zzxwill

  • Add "description" field for each workload from ListWorkloads API @zzxwill
  • [Dashboard] Refine Dashboard Capabilities: Add descriptions for all workloads as traits @zzxwill
  • [Dashboard] Refine Dashboard Capabilities: details could not clearly show all parameters and their type @sunny0826

• get details of WorkloadDefinition @sunny0826

• Trait

• list TraitDefinitions @sunny0826 @zzxwill

  • [Dashboard] Refine Dashboard Capabilities: add column title, Applies to and Operations @sunny0826
  • [Dashboard] Refine Dashboard Capabilities: unnecessary apiversion information @sunny0826

• get TraitDefinition @sunny0826

3. Logo and appearance

• [Dashboard]update logo kubevela/kubevela#1043

Show the application and all its components and traits in elegant topology.

We are trying to rewrite the APIServer based on the new design.

Why rewrite?

• The users who want to adopt this can't accept an APIServer that stores data in local environment or relies on k8s APIServer directly. Instead, all the data should be stored in a DB like MySQL.
• The previous code is tightly coupled with the Vela repo and refactoring work might be time-consuming.
• We have a tight schedule to work out a PoC quickly.
• I don't think anyone has adopted the old APIServer yet.

As a starting point, we will implement the Catalog API first. That includes:

• /catalogs/<catalog> for CRUD of catalog resources
• /catalogs/<catalog>/sync to scan the catalog repo and store necessary information in DB.
• /catalogs/<catalog>/packages and its child APIs for package resources. This might depends on the sync API.

Future plan with KubeVela repo:

• We will merge this back to the main repo after the PoC is done.
• The old APIServer will be deprecated.
• The CLI will be rewritten as well.
• The Dashboard is reusable but might need a little tweak to adopt the new API.

validate inputed parameters of workload/traits by their type.

• list
• put
• del
• get

Similar to this

As part of the UX improvement roadmap, we got some user feedback to support the following scenarios:

• Users want to define base application template and add patches based on environment. For example, in dev environment users would use ephemeral disk, while in prod environment use persistent volumes.
• Users want to define environments as the shared-bases for applications. For example, applications might need shared definitions, secrets, health checks, network gateways, etc.

To support the above scenarios, we will add the following concepts:

• AppTemplate that defines the template base as well as the env-based patches:

  name: example-app-template
  
  base: # the base template
    components:
      - name: backend
        settings:
          cmd:
            - /bin/myservice
        traits:
          - name: logging
            properties:
              rotate: 1d
  patch: # kustomize-style overlay patch to base template based on env matching
    - envs:
        - dev # the name of the Environment
      components:
        - name: backend
          settings:
            image: dev/myimage
          traits:
            - name: scaler
              properties:
                replicas: 1
    - envs:
        - prod-beijing
        - prod-shenzhen
      components:
        - name: backend
          settings:
            image: production/myimage
          traits:
            - name: scaler
              properties:
                replicas: 10

• Environment that defines a shared-base for applications:

  name: prod
  
  clusters:  # deploy to the following clusters
    - prod-cluster
  
  secrets: # The secrets that will be created for applications if not existed.
    - name: redis
      data:
        url: redis-url
        password: redis-password
  
  definitions: # The definitions that will be created for applications if not existed.
    - type: Component
      name: function
      source:
        git: catalog-url
        path: pacakge/function
    - type: Trait
      name: logging
      source:
        git: catalog-url
        path: package/logging

  Note: we will define a definition catalog/package format: https://github.com/hongchaodeng/catalog-example

With the above concepts, the user story goes as:

• The operations/admin team sets up environments first
• The developer users prepare app templates and individual patches for each environment that will have apps to deploy to.
• Users choose a template, then choose an environment, and deploy!
  • velacp will render the final Application based on the template and env
  • velacp will prepare the necessary secrets, definitions in the environment for the applications
  • The Application can use any of the definitions, secrets in this env.

Applicaton deployment workflow:

Env -> Controller -> (Secrets + Definitions)
AppTemplate -> velacp -> Application -> Controller

Notes:

• AppTemplate will be implemented in velacp. Environment will be implemented as a CRD.

Application

detail

• provide application logs function to see logs of pods kubevela/kubevela#263
• provide application exec function to login a container kubevela/kubevela#264

create

• refine creation UX @hanxie-crypto

Component

• design and implement components operations
• [API] implement component operations related API
  • api for vela comp run kubevela/kubevela#271
  • api for vela comp ls kubevela/kubevela#272
  • api for vela comp show kubevela/kubevela#273
  • api for vela comp status kubevela/kubevela#274
  • api for vela comp delete kubevela/kubevela#275

Workloads/Traits

• [API] List more parameters and catalog them for core workloads and traits kubevela/kubevela#265 @zzxwill

Also need label indexing

grpc provides an easy way to build services. More specifically, it makes building client tools easier and generates OpenAPI/swagger definitions automatically. For exposing RESTful endpoints, there is a grpc-gateway to do that.

Use gin to create API services.
Note that we should keep in mind at the beginning to have swagger doc for each API: https://github.com/swaggo/gin-swagger

1. unit-test
2. e2e-test
3. code static check
4. code format check

for both Golang and the frontend code.

See this modules.yaml example.

For Vela 1.0 we will support:

• native module, aka raw k8s yaml, in both url and relative path cases.
• helm remote repo

For now the installation will be handled on the server side. After Vela 1.0 we will migrate to CLM and implement the full set of features in the controller component.

when will velacp release the version?
I did not find restapi

Describe the bug

If we type in a non-root path, the page will throw an json error:

I think it's caused by api-server, server should carry all routes except "/api" to dashboard

Features include canary rollout, approval gate, traffic shifting, metrics analysis, gradual steps.

We should have a cache interface to cache data from the underlying datastore (e.g. MySQL database)

Currently the ORM tool like gorm needs adding custom tags for better integration. But protobuf doesn't support custom tags as discussed in this issue.

The above is the main reason. Additionally, mongodb has great golang client and easy to bootstrap experience.

MySQL is known to be better when data volume is large and query is complicated. We don't have that requirements anyway.

• add velacp dockerfile and ui dockerfile
• add official docker image with gitlab ci

I can help if needed

The workflow:

• create app template with parameters
• create app from app template, prompt to input parameters

In the application creation page,

• select workload type or trait should show from the dropdown, like task
• A button "新增" will display, it should be in English

We used from-render to rendering the form. The button is auto-generated by the form-render.

We should have a unique datastore interface for data access layer.
An example:

type DataStore interface {
	// Find finds the documents matched given criteria.
	Find(ctx context.Context, kind string, opts ListOptions) (Iterator, error)
	// Get gets one document specified with ID, and unmarshal it to typed struct.
	// If the document can not be found in datastore, ErrNotFound will be returned.
	Get(ctx context.Context, kind, id string, entity interface{}) error
	// Create saves a new entity to the datastore.
	// If an entity with the same ID is already existing, ErrAlreadyExists will be returned.
	Create(ctx context.Context, kind, id string, entity interface{}) error
	// Put saves the entity into the datastore with a given id and kind.
	// Put does not check the existence of the entity with same ID.
	Put(ctx context.Context, kind, id string, entity interface{}) error
	// Update updates an existing entity in the datastore.
	// If updating entity was not found in the datastore, ErrNotFound will be returned.
	Update(ctx context.Context, kind, id string, factory Factory, updater Updater) error
	// Close closes datastore resources held by the client.
	Close() error
}

What's the background? KubeVela controller provides the engine to encapsulate resources, deploy applications, and handle some of basic application operations (health, logs, rollout). But on top of that users still need to go a few manual steps to setup the platform and deploy applications.

What's the proposal? Since v1.0 is released, the API is stable. For the next steps, we are going to improve user experience with KubeVela. There is still some gap between what the platform provides and how people use it. We need automate as many steps to fill the gap as possible.

The baseline is that we assume users should use dashboard as much as possible. On top of that, it should provide end-to-end solutions to deploy and operate users' applications.

How do we define an end-to-end solution? It means automation and ease of use. Automation means if a step could be automated, we should handle it in dashboard/backend. Ease of use means if users need to manually do something, e.g. install a package, they should only need to click a button instead of typing kubectl apply -f ...

Here's a list of items to do for current roadmap:

• Cluster management
  • Install KubeVela and necessary dependencies
  • List comp/trait definitions
• Application deployment
  • Step-by-step walkthrough the deployment config
  • Provide forms and documentation for parameters in the UI
• Application operation
  • logs
  • metrics
  • health
  • trace
  • route
• Revision/Traffic management + Progressive rollout
  • ✅ Bonus: The UI could provide approval gate button for canary check
• Multi-cluster rollout
• Environment managment
  • Application template should be provided as well to render based on environment
• Capability catalog
• Application catalog

Now the application CRUD is finished, we need to show an application page when user clicks an app:

This is related to the "application operation" section in https://github.com/oam-dev/kubevela/issues/1495 . A few points I can think of to show in application page:

• metadata
• health
• replica
• logs menu
• metrics menu

Any idea is welcome! Please share your thoughts and ideas on what to show up in the application page.