about different schema for our service and ovn

[gujun4990]

Description

Our service uses libovsdb to access the OVN Northbound (NB) and Southbound (SB) databases. The data models were generated by modelgen based on the OVN 21.09 schema. After upgrading OVN from 21.09 to 24.09, the service fails to update the requested_chassis column in the Port_Binding table of the SB database.

E1013 11:15:28.883641   10125 cache.go:935] "during libovsdb cache populate2" err="column: requested_chassis not found in table: Port_Binding" logger="libovsdb.cache" db="sbdb" database="OVN_Southbound"
E1013 11:15:28.883712   10125 client.go:1178] "error updating cache, DB schema may be newer than client!" err="column: requested_chassis not found in table: Port_Binding" logger="libovsdb" db="sbdb" database="OVN_Southbound"

Analysis

The issue occurs because the requested_chassis column does not exist in the 21.09 schema but was introduced in 24.09. Consequently, when libovsdb attempts to parse updates involving the requested_chassis column, it cannot find the corresponding field in the generated model, leading to an error.

// updateOrModifyModel updates info about a model with a given row containing
// the change. The change row itself can be interpreted as an update or a
// modify. If the change is an update and a modify row is provided, it will be
// filled with the modify data.
func updateOrModifyModel(dbModel model.DatabaseModel, table string, info *mapper.Info, changeRow, modifyRow *ovsdb.Row, isModify bool) (bool, error) {
	schema := dbModel.Schema.Table(table)
	var changed bool

	for column, updateOvs := range *changeRow {
		colSchema := schema.Column(column)
		if colSchema == nil {
			// ignore columns we don't know about in our schema
			continue
		}

		currentNative, err := info.FieldByColumn(column) // This will return the failure
		if err != nil {
			return false, err
		}
...
}

[halfcrazy]

Could you update your schema to match the current ovn version? #373

[gujun4990]

I checked the Kube-OVN project: modelgen.sh. It uses the OVN schema version 25.03. When the OVN version changes, Kube-OVN need to be rebuilt to adapt to the new schema — and our service follows the same pattern.

So, it raises a question: should libovsdb support scenarios where a service using it remains unchanged even after OVN is upgraded?

[halfcrazy]

I checked the Kube-OVN project: modelgen.sh. It uses the OVN schema version 25.03. When the OVN version changes, Kube-OVN need to be rebuilt to adapt to the new schema — and our service follows the same pattern.

So, it raises a question: should libovsdb support scenarios where a service using it remains unchanged even after OVN is upgraded?

From #129 (comment) i think in your case the update2/3 should update the cache successfully and ignore the unknown field.

We tried to avoid this because it would make it difficult for us if the schema of that table changes in a non-backwards-compatible way. How would we handle that case?

I think we're just going to have to have a minimum viable struct for the _Server table - e.g just the fields we need.
There is less chance of a schema change breaking us that way. Even if we did get broken by a schema change, we could probably map from version -> a different struct as we're only interested in a handful of fields. Not perfect, but good enough. At least it's not the entire vswitchd schema

[gujun4990]

As mentioned above, the following code will return an error when libovsdb parses update information:

// updateOrModifyModel updates info about a model with a given row containing
// the change. The change row itself can be interpreted as an update or a
// modify. If the change is an update and a modify row is provided, it will be
// filled with the modify data.
func updateOrModifyModel(dbModel model.DatabaseModel, table string, info *mapper.Info, changeRow, modifyRow *ovsdb.Row, isModify bool) (bool, error) {
	schema := dbModel.Schema.Table(table)
	var changed bool

	for column, updateOvs := range *changeRow {
		colSchema := schema.Column(column)
		if colSchema == nil {
			// ignore columns we don't know about in our schema
			continue
		}

		currentNative, err := info.FieldByColumn(column) // This will return the failure
		if err != nil {
			return false, err
		}
...
}

The currentNative, err := info.FieldByColumn(column) code will return a error. The error occurs because the info is generated based on the OVN 21.09, in which the Port_Binding table does not include the requested_chassis column.

• info from db.metadata

AddRowUpdate2
 |- info, err := dbModel.NewModelInfo(new)
  |- meta, ok := db.metadata[reflect.TypeOf(obj)]

• db.metadata

NewDatabaseModel
 |- metadata, errs = generateModelInfo(schema, client.types)
 |- dbModel.metadata = metadata

The client.types are generated from the OVN 21.09 schema, so the resulting info and metadata structures are also based on OVN 21.09. As a result, when libovsdb processes updates containing the requested_chassis column (introduced in later OVN versions), it fails because the column does not exist in the older schema definitions.

[halfcrazy]

Yes, this could be a bug in libovsdb.

[halfcrazy]

After some digging, I think the issue is caused by dbModel.Schema; the dbModel.Schema is set using the server-side data, not the modelgen generated local schema .

// tryEndpoint connects to a single database endpoint. Returns the
// server ID (if clustered) on success, or an error.
func (o *ovsdbClient) tryEndpoint(ctx context.Context, u *url.URL) (string, error) {
...
		// load and validate the schema
		schema, err := o.getSchema(ctx, dbName)
...
		db.model, errors = model.NewDatabaseModel(schema, db.model.Client())
}


func updateOrModifyModel(dbModel model.DatabaseModel, table string, info *mapper.Info, changeRow, modifyRow *ovsdb.Row, isModify bool) (bool, error) {
	schema := dbModel.Schema.Table(table) // ------------> here
	var changed bool

	for column, updateOvs := range *changeRow {
		colSchema := schema.Column(column)
		if colSchema == nil {
			// ignore columns we don't know about in our schema
			continue
		}
}

However, if we fix this update cache case, the issue still exists in the create, update, and mutate scenarios. I think the best way to solve this is to use the same schema update client-side Go code.

[gujun4990]

Right. However, from an overall perspective, it is worth considering whether libovsdb needs to handle situations where the database schema differs between versions.

[dave-tucker]

See #235 and a potential fix via #257 - I can try and find some time to pick that back up if it solves the issue for you.