The goal of this spec is to introduce objects into cinder. An object is used to bundle data with methods that can operate on them. By implementing this spec, we would be able to pass rich objects over RPC and decouple the database schema implementation from SQLAlchemy, enabling support for NoSQL databases. Database schema independence is the biggest gain with this proposal.
There are a few problems that exists today in cinder:
There is an approved proposal to put nova.objects into oslo as oslo.versionedobjects (https://review.openstack.org/#/c/127532/), which would abstract versionable internal objects for use with RPC. The plan is to adopt oslo.versionedobjects and abstract volumes, snapshots, backups, consistency groups, and quotas.
Since it will take some time before versionedobjects goes into the oslo library, the plan is to sync up with dansmith to get an early version of it for cinder and transition to oslo.versionedobjects when it is ready.
The proposed changes are:
The work will be done incrementally in stages, as follows.
The goal is to have oslo.versionedobjects code base in by the end of kilo-2, and the abstraction of a few cinder internals, e.g. volume snapshots and backups, by that time also.
Cinder could continue to be tightly tied to SQLAlchemy, limiting support to only SQL databases. Also, the existing implementation of sending ids over RPC can be left as-is.
There are proposals for state machine/state enforcement and RPC versioning, which would help with rolling upgrades and improve the stability of cinder. However, you would still take an additional database hit when the volume, snapshot, backup, or consistency group ids are used to query the SQLAlchemy objects.
None. Cinder objects provides an abstraction layer in cinder, allowing for database schema independence. These objects are a replacement for SQLAlchemy objects that are being used to represent service, volume, volume type, snapshot, quota, backup, consistency group and consistency group snapshot throughout cinder internals.
Unknown. There might be a minor hit in performance since SQLAlchemy objects are abstracted into cinder objects.
Today, direct database calls are made to create, read, update, and delete volumes, volume types, snapshots, quotas, backups, consistency groups and consistency group snapshots, and others. With the switch to an object model, these calls will be made against the appropriate object methods. It will take some time to convert cinder internals over to the object model, so the existing convention of direct database calls should be accepted until all object models are in place.
By introducing objects, we are not changing the end user facing API or functionality of cinder. We are passing objects over RPC instead of ids. Given this, no new tempest tests will be created. However, relevant unit tests will be created to test the new object code base.