Ewen Cheslack-Postava

@criccomini This is my fault. Ironically, we wish there were *more* contributions back to this repo to improve test framework generally (rather than, e.g., hacking around things in tests, which...

> A1: Previously, I expect something like @cluster(nodes_spec={'storage':1, 'server':3}). Base on your suggest, I think we can reuse cluster_spec by adding ClusterSpec.from_dict() method, so that we can do @cluster(cluster_spec=ClusterSpec.from_dict({'storage':3, 'server':1}))....

@whynick1 Yeah, so re: A4, my point was more of a tagging/matching approach. We rely a *ton* today on the vagrant cluster type, but really that's a detail (and increasingly...

Yeah, this approach seems like it works well. I suspect longer term we'll end up with some sort of mix because within a suite of tests it might be handy...

> @ewencp Based on comment, I propose a more user-friendly pattern. > > ``` > STORAGE_NODE = NodeSpec(LINUX, MachineType(cpu=1, disk=100G)) > cluster_spec = ClusterSpec.from_nodes(STORAGE_NODE.with_num_nodes(3)) > s = StorageService(cluster_spec) > ```...

@hachikuji Do we need to be careful about how we group these too under the resources? The current set of APIs under /consumers only support operations for consumers on the...

@hachikuji Yeah, that's exactly what I was getting at. In retrospect, I probably would have preferred the cluster-wide version to be `/consumers` and the instances on the proxy to be...

@joewood If you're referring to the ability to list all the consumers in the cluster, it hasn't been implemented yet. It'd probably fall under the admin API. There's a new...

@idarlington `topic+partition+offset` should be unique within a Kafka cluster -- that is how you uniquely identify a topic which is why the connector uses that. You could have conflicting IDs...

Interesting that the offset does not seem to be correct. I'm looking at the code where that ID is generated and it's definitely using the Kafka offset for the last...