Creating a Keyspace with >1 parts does not update VSchema

[henders]

The deploy/example.yml has 2 parts in the keyspace it's creating but the VSchema is just created as an empty { }.

I think this is causing problems as I was seeing errors complaining that tables I created in that keyspace weren't sharded. I think during instantiation of the keyspace it should detect parts > 1 and update the schema with the minimum:

{
  "sharded": true
}

[enisoc]

That's an interesting idea. So far the operator doesn't touch VSchema at all. Vitess fills in the empty VSchema upon creating any new keyspace.

It would be feasible to have the operator help manage VSchema, but we'd need to think through how it will interact with day-2 operations. For example, usually people manage their VSchema from some source of truth like git and push it into Vitess. If the operator changes the VSchema directly in Vitess topology, it may become inconsistent with the user's intended source of truth.

Another example is that we may not always be able to assume we know what the user wants. For example, even if parts: 1 they may want sharded: true so that Vitess sends all queries through the sharded execution planner to make sure all queries are compatible with sharding before they reshard. Similarly, if we see a partitioning with parts: 2 it may be that those shards are not active yet at the Vitess level. Perhaps the active partitioning is still an unsharded one.

[henders]

Ah, fair points. It would definitely reduce flexibility and possibly break clusters upon updates if it did this. Maybe I should close this in favor of the Operator allowing an initial VSchema to be set, but that puts the responsibility on the deployer?

[enisoc]

I'm not sure how most people manage the lifecycle of VSchema in the wild. I've been assuming people would do something similar to whatever they do for regular schema, and regular schema to me feels more like it belongs to the data plane rather than the control plane.

In general, I think of the operator as being suitable only for passing control plane signals to Vitess. It doesn't seem right for the operator to be directly involved in the data plane. The operator should only make sure that the data plane is available.