Open Stack

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 at gmail.com]
Sent: Tuesday, December 04, 2018 4:52 AM
To: openstack-discuss at 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.