Sheng Yang

I believe it would need Harvester QA team members to collaborate with the Rancher team to write those tests. Without defining the requirement, it would be hard for the Rancher...

There are a few complications regarding restoring a VM into a new Harvester cluster. We will investigate to understand the effort first.

We shouldn't need to wait for this change. Today Longhorn UI knows if a volume cannot be scheduled according to the conditions of the object. We can just use those...

@joshimoo I remember that condition also indicates we cannot create more replicas with one node. Do you remember how did we tell the two cases apart? Depends on if the...

I am fine with using the annotation. Though we need to follow `camel-camel` for the keys, e.g. it should be `vm.harvesterhci.io/volume-status` instead of `volumeStatus`.

Set the milestone to v0.3.0 for now. If https://github.com/longhorn/longhorn/issues/2285 cannot be completed for v1.2.0, then we need to push it out.

Due to the large level of effort, we won't be able to make this into v1.1.0. Move it to v1.2.0.

Yeah, H1 2023 is the planned date for v1.2.0

The same volume would always store the data in the same node. And where the data was stored was determined by where is the pod scheduled. You can modify the...

As I said, Kubernetes decides where to put the pod first, then storage follows, not the other way around. The pod was scheduled to the k3s-master, so the storage must...