Project archived - https://www.mediawiki.org/wiki/Phabricator/Project_management#Archiving_a_project

Should it be archived then?

@Aklapper all done. I think we can retire the tag.

This task was left open by mistake; we've had a multi-dc setup for years now.

7 years later no one is working on this and I doubt it will ever be. Declining the task as a consequence.

This has been solved years ago.

This has been implemented years ago.

@Joe: Thanks in advance!

@Aklapper yes it used to be used for the system we built that is the base for both the DNS discovery system and dynamic configuration for things like pybal or mediawiki.

@Joe: Do you know, by any chance? (Or have some link handy?)

Pretty sure it's T95662 and service discovery as in https://platform9.com/blog/kubernetes-service-discovery-principles-in-practice/ but @Joe will be able to confirm.

Change 602047 merged by Giuseppe Lavagetto:
[operations/puppet@production] profile::conftool::client: only use root on cumin*, puppetmasters

My tests went fine:

• mwdebug* servers got the datacenter-appropriate pool-$dc-testserver user
• the deployment servers got the conftool user instead

Change 602047 had a related patch set uploaded (by Giuseppe Lavagetto; owner: Giuseppe Lavagetto):
[operations/puppet@production] profile::conftool::client: only use root on cumin*, puppetmasters

Change 598415 merged by Giuseppe Lavagetto:
[operations/puppet@production] profile::conftool::client: allow overriding the user root can access

Change 597806 merged by Giuseppe Lavagetto:
[operations/puppet@production] profile::etcd::tlsproxy: add additional users for pools

Change 597805 merged by Giuseppe Lavagetto:
[operations/puppet@production] profile::etcd::tlsproxy: refresh code for modern puppet

The deploy strategy is simply adding the new users to etcd, move most hosts to use conftool as the root user immediately, and then progressively move them to the new users system on the long run.

Change 598415 had a related patch set uploaded (by Giuseppe Lavagetto; owner: Giuseppe Lavagetto):
[operations/puppet@production] profile::conftool::client: allow overriding the user root can access

+1 as the above schema of auth reflects mostly my old comment/proposal. What's the deploy strategy?

Change 597806 had a related patch set uploaded (by Giuseppe Lavagetto; owner: Giuseppe Lavagetto):
[operations/puppet@production] profile::etcd::tlsproxy: add additional users for pools

Change 597805 had a related patch set uploaded (by Giuseppe Lavagetto; owner: Giuseppe Lavagetto):
[operations/puppet@production] profile::etcd::tlsproxy: refresh code for modern puppet

These permissions LGTM.

RBAC without roles isn't really Role Based Access Control, but I digress.

I think I will try to implement the following RBAC schema:

Per @Volans recommendation, adding a use case here:

Change 564994 abandoned by Giuseppe Lavagetto:
This is a test, please disregard.

Indeed! we're doing more than this!

@Joe can this be considered done already with dbctl?

In T97972#5353056, @Volans wrote:

In T97972#5352851, @Joe wrote:

IIRC we already have an account specialized for accessing only mwconfig, we could expand on the concept.

Not in etcd, we only have a root user (see v2/auth/users) and root and guest roles (see v2/auth/roles). The guest role having access to eventlogging objects, but I don't see them, so maybe relic from the past of setup in anticipation of something that never happened.