I've asked for it a while ago, but will ask again since the subject came back up. :) If ironic could target k8s crds for storage, it would be significantly easier to deploy an under cloud. Between k8s api, the k8s cluster api and ironic's api, a truly self hosting k8s could be possible. Thanks, Kevin ________________________________________ From: Jay Pipes [jaypipes@gmail.com] Sent: Tuesday, December 04, 2018 4:52 AM To: openstack-discuss@lists.openstack.org Subject: Re: [all] Etcd as DLM 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.