Support for ttl, row policies and etc propagation when cluster scale up

[kingboung]

Context

When cluster scale up, operator only helps to create database and tables.

Desired behavior

Also help propagate ttl, row policies and others necessarry. If not, I need to do it manually however I always forget it

[UnamedRus]

For row policies, i think it's better to look into user storage in ZooKeeper.

https://kb.altinity.com/altinity-kb-integrations/altinity-cloud/altinity-cloud-access-management/

<yandex>
  <user_directories replace="replace">
    <users_xml>
      <path>/etc/clickhouse-server/users.xml</path>
    </users_xml>
    <replicated>
      <zookeeper_path>/clickhouse/access/</zookeeper_path>
    </replicated>
  </user_directories>
</yandex>

[kingboung]

For row policies, i think it's better to look into user storage in ZooKeeper.

https://kb.altinity.com/altinity-kb-integrations/altinity-cloud/altinity-cloud-access-management/

<yandex>
  <user_directories replace="replace">
    <users_xml>
      <path>/etc/clickhouse-server/users.xml</path>
    </users_xml>
    <replicated>
      <zookeeper_path>/clickhouse/access/</zookeeper_path>
    </replicated>
  </user_directories>
</yandex>

The operator's account has already set access_management=1

[kingboung]

How can I do this? Or it will be new requirement?

[Slach]

@kingboung you should create kind: ClickHouseInstallation custom resource and look to kubectl explain chi and kubectl explain chi.spec for details about how to define spec.configuration.files