The big takeaways:
1. We want the schema to be external so other languages can utilize them.
2. JSON-Schema seems fine, but AVRO has traction in the Big Data world and
should be considered.
3. The challenge of have text-file based schema's is how to make them available
for CI and deployments. Packaging problems. There is no simple pip install for
text files. Talked about the possibility of making them available by the
service API itself or exposing their location via a Service Catalog entry.
4. There are a lot of other services that need a solution to this problem.
Monasca needs to define a message bus schema. Nova Objects has its own for RPC
calls. It would be nice to solve this problem once.
5. The CADF group is very open to making changes to the spec to accommodate our
needs. Regardless, we need a way to transform existing notifications to
whatever the new format is. So, we not only need schema definition grammar, but
we will need a transformation grammar out of the gate for backwards
6. Like Nova Objects, it would be nice to make a single "smart" schema object
that can read a schema file and "become" that object with proper setters and
getters (and validation, version up-conversion/down-conversion, etc)
7. If we can nail down the schema grammar, the transformation grammar and
perhaps the schema object in Kilo we can start to promote it for adoption in
8. People should be freed up to work on this around Kilo-2 (new year)
Lots of other details in the etherpad.
It would be good to arrange a meeting soon to discuss the schema grammar again.
And how to distribute the schemas in test and prod env's. Perhaps come up with
some concrete recommendations.
OpenStack-dev mailing list