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

Reply via email to