suggestions for the cluster-spec repository

[bxy4543]

suggestions for the cluster-spec repository

1. The warehouse name is cluster-spec, but the warehouse contains not only the cluster spec structure, but also structures such as plugin, config, and cluster status.
2. I found that the cluster spec structure is too simple, we need to optimize it to meet more scenarios.
3. The cluster status structure should record the status of the cluster deployed by sealer, but I found that the status structure is empty, we should record all relevant status in the cluster status, such as config, plugin, and the base image of the cluster , application mirroring, etc.
4. Our api version is not standardized, I found that there are v1, v1beta1, v2, in fact a correct version should be v_alpine-=>v_beta-=>v_
5. Use the correct GroupVersion:
   The group is cluster.sealer.cool in the [definition](

   cluster-spec/v2/groupversion_info.go

   Line 29 in d9211fb

   GroupVersion = schema.GroupVersion{Group: "cluster.sealer.cool", Version: "v2"}

   ) but sealer.cloud is used in the Clusterfile.

root@iZj6c5z9rk0weftpz32jeoZ:~# cat /root/.sealer/my-cluster/Clusterfile
apiVersion: sealer.cloud/v2
kind: Cluster

[allencloud]

@bxy4543 Good proposal. For your first point, my opinion is that:

• Clusterfile is a reserved and first-class citizen of sealer. Then we should keep the Cluster_types.go in this repo.
• plugin, config and image definition may not be the first-class citizen of sealer. We may say that ClusterImage is the first-class citizen, but it is an inner concept of sealer, and we do not have to expose image spec to developers. So, I suggest that we locate image, config, plugin spec back to the sealer main repo.

For your second point, I have discussed that with @VinceCui . My opinion is that:

• Yes, Cluster Spec is some kind of simple.
• We should clarify the definition of Cluster. From our discussion, I proposed that we should define ClusterSpec into three parts:
  • only the infra part which could be regarded as the static part of a distributed application, including Hosts, Connecting Credentials. This layer is for users to provision basic infrastructure, and then ClusterImage could be deployed on them.
  • the Kubernetes dynamic part, including ClusterImage name, env, and CMD and so on. If someone provides a k8s definition cluster spec, user could deploy application part on k8s. This part is layered by k8s and application.
  • The Application Part of Cluster.

After the definition, we have layered architecture of ClusterImage, and the scalability of ClusterImage could be improved and it could meet more scenarios, such as Heterogeneous k8s installation.

Third point, we could add more info into status.

Good catch of your fourth point of versioning and fifth point.

@sealerio/sealer-maintainers