feat: implement replication validation #22581
Conversation
| } | ||
|
|
||
| func TestValidateReplication_Invalid(t *testing.T) { | ||
| l := launcher.RunAndSetupNewLauncherOrFail(ctx, t, func(o *launcher.InfluxdOpts) { |
There was a problem hiding this comment.
Would these two tests run faster if they were the same test (since we don't have to setup / tear down the server)
There was a problem hiding this comment.
Probably, though it's not as slow as it could be since they're using the inmem metadata store instead of a real boltDB.
| noopReq := client.PostWrite(ctx). | ||
| Org(config.RemoteOrgID.String()). | ||
| Bucket(config.RemoteBucketID.String()). | ||
| Body([]byte{}) |
There was a problem hiding this comment.
Have we checked this also doesn't error in cloud? Should we maybe add a cloud unit test that this works? It is and odd kind of request to attempt to write with no data, I can see us rejecting or otherwise flagging that it is weird.
There was a problem hiding this comment.
I've checked (it used to error, but I changed the behavior as part of an EAR last year). Agreed it would be good to have a regression test to make sure things don't revert.
Ideally we could instead have/use some sort of "can I?" API where you submit a resource/action and get back a yes/no.
There was a problem hiding this comment.
I think I prefer this kind of check (where we actually do the thing) vs a 'can I' API which might drift from the actual checks on the 'real' API. I just want to make sure it works.
|
Note your CI is failing |
Unrelated to this PR (but potentially a bug / missing feature in OSS). A new test was added to the e2e suite in influxdata/ui#2748 |
Closes #22295
To validate a replication, we send an empty payload to the
/api/v2/writeof the remote server.