DBRE approved then

Looks like we need to remove patroni-ci-v17-10-db-gprd.c.gitlab-production.internal from the inventory as we're not creating one with that address

Looks like we need to remove this line

@rhenchen.gitlab Could you show the updated inventory for the switchover playbook/make an MR so I can validate we're not going to miss one of them?

I assume we're not removing node 102 because it's a backup node? What about 02?

+ Cluster: gprd-patroni-ci-v17 (7531379063423388960) -----+---------------+---------+-----------+----+-----------+---------------------+
| Member                                                  | Host          | Role    | State     | TL | Lag in MB | Tags                |
+---------------------------------------------------------+---------------+---------+-----------+----+-----------+---------------------+
| patroni-ci-v17-02-db-gprd.c.gitlab-production.internal  | 10.220.38.102 | Replica | streaming |  3 |       154 | nofailover: true    |
|                                                         |               |         |           |    |           | noloadbalance: true |
+---------------------------------------------------------+---------------+---------+-----------+----+-----------+---------------------+
| patroni-ci-v17-101-db-gprd.c.gitlab-production.internal | 10.220.38.201 | Replica | streaming |  3 |       665 |                     |
+---------------------------------------------------------+---------------+---------+-----------+----+-----------+---------------------+
| patroni-ci-v17-102-db-gprd.c.gitlab-production.internal | 10.220.38.202 | Replica | streaming |  3 |       642 | nofailover: true    |
|                                                         |               |         |           |    |           | noloadbalance: true |

David Leach (fad61256) at 19 Mar 04:02

Haha yeah, you're right. I used glean to find them and thought it was the login issue we hard relating to configuring the legacy cell before configuring topology service, I'll remove it

There is some development happening around centralised security logging here: https://gitlab.com/gitlab-com/gl-security/security-operations/security-logging/security-logging/-/work_items/650 where security will manage an elastic cluster for it related MR at present however, it's just the tenant/cell local opensearch that is available.

Cells also has tenant/cell based logging via opensearch

There's definitely a reasonable amount of dashboards available to cells, given it uses the same stack I assume they're the same as dedicated single tenant dashboards

David Leach (a72e5a9f) at 19 Mar 00:44

Hi @atevans,

I agree it's super important to get claiming done before we move users to a new cell and applies to groups/username and organization too. We've not implemented the cron yet: !227043 (merged) nor have we enabled claiming feature flags yet.

@atevans, I assume we'd want to claim this to maintain uniqueness across the cluster, ie. Because a device should be associated with a single user we don't want to allow them to assign the same device to another user?

The primary driver behind these unique index constraints is to ensure that users/orgs can be moved at will between cells without their being a conflict. If you also need the credential_xid to be unique across the cluster to prevent a device being used between two different users then we should claim it, if not scoping down to organisations makes sense.

But it feels like I might be missing some context from the discussion so let me know if this doesn't make sense

David Leach (1c8b8682) at 18 Mar 22:45

@sangwoo_han_gitlab This feels like something that opencode + duo or claude code could come up with a quick POC for, for you to iterate on 😄

Thanks for the update!

David Leach (c0858045) at 18 Mar 20:55

David Leach (da295904) at 18 Mar 20:50

@atevans, @adil.farrukh Topology service is available, preference is for groupauthentication to complete. As far as backfilling goes, that should happen automatically once claiming work is complete

If it's going to be removed before we need it then it is inconsequential and yes, it should be with source code based on that issue.

I'll update it