Introducing NebulaSchema

[haoxins]

Hi,
I submitted a discussion about the schema management of Nebula last year.
See vesoft-inc/nebula#5794.

From now on, some progressions and changes are happening.

I already introduced ApplyEdge & ApplyTag in the Nebula Go client.
See vesoft-inc/nebula-go#317 and vesoft-inc/nebula-go#319.

So I want to move to the next step by introducing a new CRD called NebulaSchema or NebulaMigration?
(I'm not sure what is the ideal name.)

The draft CR but not the CRD will look like

apiVersion: apps.nebula-graph.io/v1alpha1
kind: NebulaSchema
metadata:
  name: test_01
spec:
  localNebula: false
  remoteConfig:
  # The config for the Nebula that deploys out of the same K8s cluster
    spaceName: test_space
    clusterHost: the_host
    clusterPort: 8888
    user: the_user_name
    pass: the_password
  localConfig:
  # The config for the Nebula that deploys in the same K8s cluster.
  # Maybe we can refer to the NebulaCluster by name (and namespace)
  # and read the extra information from the ConfigMap or Secrets.
  tags:
    - name: user
      fields:
      - name: name
        type: string
      - name: age
        type: int
  edges:
    - name: friend
      fields:
      - created_at
        type: timestamp

I opened this issue is make sure whether this idea is accepted or not for the operator.
If so, we can talk about the more details of the CRD and implementations.

[wey-gu]

Nice idea!
This seems to be a one-direction binding. or do we need to reconcile/watch all schemas as well?

[haoxins]

This seems to be a one-direction binding. or do we need to reconcile/watch all schemas as well?

Follow the K8s operator pattern, every time the NebulaSchema changes, apply the Nebula space to the latest NebulaSchema.
This is also the desired behavior of the operator's end users.

So, need to reconcile/watch

[haoxins]

So that I can start the first PR to proposal the CRD?