🍀 Proposal: New Plugin Support: zentao(禅道)

[daniel-hutao]

What would you like to add? Why is this needed?

Some tips:

• zentao website: https://www.zentao.net
• support the deployment(crate/update/delete/...) with zentao(open source version)

Please give a design before start coding.

/cc @devstream-io/pmc

[xavier-hou]

Wanna try.

[daniel-hutao]

/assign @HXCGIT Happy coding!
Call me any time if you need.

[KeHaohaoke]

Hello, I have studied the deployment of zentao and the integration of zento, github and gitlab. Can we discuss the design of requirements? @HXCGIT

[xavier-hou]

Hello, I have studied the deployment of zentao and the integration of zento, github and gitlab. Can we discuss the design of requirements? @HXCGIT

Sure, that's great！

[xavier-hou]

For the integration of Zentao, at first we can just consider its deployment.

There are various methods for deploying Zentao, including online platform, one-click installation package and source code. My thinking is that I would prefer to deploy Zentao on company's intranet environment, and would prefer an open source version. Either one-click installation or source code installation would be fine, but for the time being, I'll consider the one-click installation package for convenience. Of course, this is all just a temporary idea, and we can actually provide options in the configuration file to support different deployment types.

If using the one-click installation package to deploy Zentao, the whole process is very simple

1. download the resource package
2. extract the resource package to a specific location
3. start the program

My thoughts on the implementation of Zentao deployment are as follows

Options

• location: This field should indicate the location where Zentao will be deployed. It can be an IP address or a DNS address that can be resolved, because under normal circumstances, operation staff will not deploy the service system on their own local machine, but the default value can be localhost. If our configuration allows it to deploy Zentao on a remote machine, we should add other credential fields to obtain remote login and remote execution permissions accordingly.
• version: Zentao has many versions, and they have some different features, so I think there should be an option to select the Zentao version. Besides, the deployment method mentioned above could also have an option, such as "kind".

Validate,Create,Delete

• Nothing special

Read and Update

This is a point that confuses me. In my opinion, the output of a successful create should be the status of Zentao. The status of the service (availability) should be stored in the state.
The first problem is: how to determine the status of the service, there are two services, apache httpd and mysql in Zentao, and Zentao also provides zbox status command. We can also determine the availability of the service by the existence of the directory, port status, or even by api probe, but when Zentao is deployed on a remote machine, this may have some problems. For example, how to confirm if its mysql service is down.
The second question is what kind of logic that update should have. The simplest consideration is to uninstall Zentao and reinstall it if the service goes down. This seems unacceptable to me, since deleting an existing service could result in a large amount of data loss. So the question is, how to execute update after a state change, I don't have a clear idea yet.

In general, I would like to get your advice on the following two aspects

1. Should we support deployment on remote machines
2. What should be done in Update

Could you give me some advice? @daniel-hutao @IronCore864 @KeHaohaoke

[xavier-hou]

I've also considered integrating api operations. If we also consider supporting configuration of project operations, similar to trello, I would wonder why operations staff choose to use configuration files rather than web visualization platforms.

[KeHaohaoke]

The official zentao provides docker, and we can install and deploy k8s or helm according to it. @HXCGIT

[KeHaohaoke]

We can use k8s apply to deploy Zen Buddhism first. The advantage is that we can rely on k8s' own copy management, state management and so on to ensure the running state of Zen Buddhism. A simple yaml for deployment looks like this.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: zentao-pvc
  namespace: zentao
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: zentao-mysql-pvc
  namespace: zentao
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: zentao
  name: zentao-client
  namespace: zentao
spec:
  ports:
  - port: 80
    targetPort: 80
    name: zentao
  selector:
    app: zentao
  type: NodePort
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: zentao-pvc
  namespace: zentao
spec:
  storageClassName:  storageclass-default
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /www/zentaopms/
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: zentao-mysql-pvc
  namespace: zentao
spec:
  storageClassName: storageclass-default
  accessModes:
    - ReadWriteOnce
  capacity:
    storage: 1Gi
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /var/lib/mysql/
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: zentao
  namespace: zentao
  labels:
    app: zentao
spec:
  selector:
    matchLabels:
      app: zentao
  replicas: 1
  template:
    metadata:
      labels:
        app: zentao
    spec:
      containers:
      - name: zentao
        image: easysoft/zentao:latest
        resources:
          requests:
            memory: "1Gi"
            cpu: "1000m"
          limits:
            memory: "2Gi"
            cpu: "2000m"
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: '123456'
          #mysql密码
        ports:
        - name: zentao
          containerPort: 80
        - name: mysql
          containerPort: 3306
      volumes:
        - name: zentao-pvc
          persistentVolumeClaim:
            claimName: zentao-pvc
        - name: zentao-mysql-pvc
          persistentVolumeClaim:
            claimName: zentao-mysql-pvc

The development environment may be minikube/kind, and we need to create pv manually, which should be taken into account and the user should be prompted in the document.

It is available to let users initialize manually, because each user's initialization choices may be different, and there is a participatory process for users to initialize themselves.

After the deployment of Zendao is completed, before initialization, if you look at docker/k8s logs, you will see logs that prompt MySQL to access password errors. This is normal, because initialization has not been performed yet.

[IronCore864]

@HXCGIT thanks for the investigation. Very detailed discussion!

According to the official doc here, I'd guess that most users would choose either the cloud-based version or the Linux one-command install. I personally don't think we should support the latter version because it doesn't seem too "cloud-native," so let's forget about this choice for now.

I propose we do a k8s go-client or helm for it. Creating a helm chart might not be the worst idea since there isn't one yet. We could contribute to Zentao. We need to make it production-ready, for example, whether to create ingress, multiple pods, configure where the DB is, support different types of PVC, etc.

What do you think @HXCGIT ?

If the helm way is too much effort, we can maybe use k8s go-client for deployments and services and pvcs. I think as long as we don't os.exec kubectl, it's fine.

[xavier-hou]

@IronCore864 @KeHaohaoke That's a great idea. I know a little bit about client-go, so I think I can start with client-go, and I will submit a proposal later. As for helm, I will try it after I finish the client-go deployment.

[daniel-hutao]

closed by #670