After starting a WIP for the Declarative Index Config GRPC, I ran across a few possible ways to improve the spec.
Simplify property format
I propose that we change the property format to be the following:
type property struct {
Type string `json:"type"`
Value json.RawMessage `json:"value"`
}
This would make it possible to parse a bundle generically in a single pass, and the value field would only need to be parsed further if a particular component needs information about a certain property.
This would change the examples currently in the EP in the following ways:
property.name is renamed to property.type.
The old property.type is removed. It should be included in the new property.type field (e.g. name: "olm.gvk", type: "required" becomes type: "olm.gvk.required").
property.replaces is moved into the property.value data for the olm.channel property type.
property.values is removed. property.value can be any valid JSON and its particular schema is dictated by property.type.
Rename olm.package to olm.package.provided and add example for olm.package.required property.
We need a new property type to encode required packages. This type would be slightly different than the olm.package.provided type because olm.package.provided uses a semver version field, and this type would need a semver version range field.
I added an example of this property in the EP in the example bundle containing a required API.
For backwards compatibility reasons, we will continue to serve properties and dependencies by their old names in the GRPC API.
File parsing concerns
I made the examples consistent to show that each config file is expected to be a stream of "schema":"olm.package" and "schema":"olm.bundle" JSON documents, with no commas between them, and no root list of these objects. This will make parsing fairly straightforward and make it easy for users and tools to concatenate new items to existing config files. For example:
After starting a WIP for the Declarative Index Config GRPC, I ran across a few possible ways to improve the spec.
Simplify property format
I propose that we change the property format to be the following:
This would make it possible to parse a bundle generically in a single pass, and the
value
field would only need to be parsed further if a particular component needs information about a certain property.This would change the examples currently in the EP in the following ways:
property.name
is renamed toproperty.type
.property.type
is removed. It should be included in the newproperty.type
field (e.g.name: "olm.gvk", type: "required"
becomestype: "olm.gvk.required"
).property.replaces
is moved into theproperty.value
data for theolm.channel
property type.property.values
is removed.property.value
can be any valid JSON and its particular schema is dictated byproperty.type
.Rename
olm.package
toolm.package.provided
and add example forolm.package.required
property.We need a new property type to encode required packages. This type would be slightly different than the
olm.package.provided
type becauseolm.package.provided
uses a semver version field, and this type would need a semver version range field.I added an example of this property in the EP in the example bundle containing a required API.
For backwards compatibility reasons, we will continue to serve properties and dependencies by their old names in the GRPC API.
File parsing concerns
I made the examples consistent to show that each config file is expected to be a stream of "schema":"olm.package" and "schema":"olm.bundle" JSON documents, with no commas between them, and no root list of these objects. This will make parsing fairly straightforward and make it easy for users and tools to concatenate new items to existing config files. For example:
Signed-off-by: Joe Lanford joe.lanford@gmail.com