Open Stack

On 12/03/2018 06:53 PM, Julia Kreger wrote:
> I would like to slightly interrupt this train of thought for an 
> unscheduled vision of the future!
> 
> What if we could allow a component to store data in etcd3's key value 
> store like how we presently use oslo_db/sqlalchemy?
> 
> While I personally hope to have etcd3 as a DLM for ironic one day, 
> review bandwidth permitting, it occurs to me that etcd3 could be 
> leveraged for more than just DLM. If we have a common vision to enable 
> data storage, I suspect it might help provide overall guidance as to how 
> we want to interact with the service moving forward.

Considering Ironic doesn't have a database schema that really uses the 
relational database properly, I think this is an excellent idea. [1]

Ironic's database schema is mostly a bunch of giant JSON BLOB fields 
that are (ab)used by callers to add unstructured data pointing at a 
node's UUID. Which is pretty much what a KVS like etcd was made for, so 
I say, go for it.

Best,
-jay

[1] The same can be said for quite a few tables in Nova's cell DB, 
namely compute_nodes, instance_info_caches, instance_metadata, 
instance_system_metadata, instance_extra, instance_actions, 
instance_action_events and pci_devices. And Nova's API DB has the 
aggregate_metadata, flavor_extra_specs, request_specs, build_requests 
and key_pairs tables, all of which are good candidates for 
non-relational storage.