WIP: integration: add v2v3 emulation

[yudai]

from #9626.

Run existing integration tests for v2 api (TestV2) on v2v3 emulation to improve the compatibility between them.

[yudai]

Currently tests are broken due to v2v3 emulation doesn't work properly for member list.

[yudai]

Are member API supposed to be supported by v2v3 emulation? Or it just supports basic KV operations...?

[heyitsanthony]

@yudai the kv operations are the most tested; it still doesn't cover all membership operations. I left stubs for membership calls (see v2v3/cluster.go) with the intent that it would make v3 calls, convert to v2 structures, then let v2http handle the http response.

[yudai]

@heyitsanthony thanks for the pointer. I found that the methods of the api.Cluster interface don't have error in their return values, since the native v2 API uses internal values. However, if we use clientv3, it can cause errors. I'm wondering if we can change the interface (can breaking backward compatibility) to add error to return values.

TestV2Set is working now anyway. To make TestV2CreateUpdate, we need TTL support, which currently explicitly marked as errUnsupported for some reason. Is this just a stub?

[yudai]

Another potential issue I found is that stms used in store.go can be broken.

		for p := path.Dir(nodePath); !isRoot(p); p = path.Dir(p) {
			pp := s.mkPath(p)
			if stm.Rev(pp) > 0 {
				ecode = v2error.EcodeNotDir
				return nil
			}
			if stm.Rev(pp+"/") == 0 {
				dirs = append(dirs, pp+"/")
			}
		}
		for _, d := range dirs {
			stm.Put(d, "")
		}

If I understand correctly, in this code (from store.go), stm.Rev() is executed by a separate Tx from the main Tx for Put() operations. Therefore if there are other operations happen between the stm.Rev and the commit of the main Tx, it can cause inconsistency.
This these comp operations should be in a single Tx (STM doesn't have Comp() though)?

[heyitsanthony]

@yudai

wondering if we can change the interface (can breaking backward compatibility) to add error to return values.

I don't think adding error returns will break much. A lot of those old interfaces should be internal. Worst case, there can be some adapter to get the old behavior back.

if there are other operations happen between the stm.Rev and the commit of the main Tx, it can cause inconsistency.

For every key the txn is writing, the applier calls stm.Rev, which should insert the key into the readset (https://github.com/coreos/etcd/blob/master/clientv3/concurrency/stm.go#L291). If there's a change to any of those keys before the txn commits, STM will have a read conflict, throw away the puts, and retry. Is that not happening or is there some inconsistency it's missing?

we need TTL support, which currently explicitly marked as errUnsupported for some reason. Is this just a stub?

The TTL's are a stub too. A correct/efficient implementation needs some thought.

[yudai]

@heyitsanthony Thank you for the reference. I overlooked that readset and now I understand the behavior.

It's taking time more than I expected when I started this work. I'll make tests pass one by one anyway.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.