Microservices Sub-team

What is the microservices subteam opinion on using AAI as a DBaaS to serve multiple different microservices?    Fundamentally, what is the decomposition pattern and what is the direction on database consistency?  Will each mS own its own DBs and provide APIs/services or will AAI and all its clients have to change based on changes in a mS way of populating and exposing data?

In my opinion (others can correct) 

What is the microservices subteam opinion on using AAI as a DBaaS to serve multiple different microservices?

This may require some kind of data change notification mechanism as well to keep the micorservices in sync and act upon the data. This approach is being followed in Opendaylight - they have config and operational data stored centrally (MD-SAL). There was a proposal from Alex in the similar lines to support model driven micro services. I personally feel this is a good approach. But this might have some scalability constraints depending on the way it is being implemented. There may be requirements for managing entropy, support distributed locking, sharding, consistency checks etc. 

What is the decomposition pattern and what is the direction on database consistency?Will each mS own its own DBs and provide APIs/services or will AAI and all its clients have to change based on changes in a mS way of populating and exposing data?

I guess the current pattern in ONAP is first one (each mS own its own DBs and provide APIs/services) and what you suggested above is the second one. I think both approaches have tradeoffs. First approach will be favorable if  the architecture principle prefers freedom of choice and independent development of components, but will have complexity unless the APIs are consistent and well-formed. The second approach is favorable from a management point of view, as the S3P and other characteristics can be managed centrally and MS can be developed as stateless entities. This might also be favorable to drive a model driven approach.