TPA issueshttps://gitlab.torproject.org/groups/tpo/tpa/-/issues2023-11-23T21:08:17Zhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/31969deploy a puppet dashboard2023-11-23T21:08:17Zanarcatdeploy a puppet dashboardit would be useful to have a way to browse reports and facts in the cluster. there's a lot of information in the PuppetDB that's only visible when you inspect the database, and it would help to have a way to browse this and diagnose issu...it would be useful to have a way to browse reports and facts in the cluster. there's a lot of information in the PuppetDB that's only visible when you inspect the database, and it would help to have a way to browse this and diagnose issues with puppet.https://gitlab.torproject.org/tpo/tpa/team/-/issues/30273improve inventory of hardware resources2023-11-09T15:38:05Zanarcatimprove inventory of hardware resourcesWe currently have a few hosting providers and locations where we have "stuff":
* virtual machines
* colocated servers
* raspberri pi under desk
* routers
* "cloud" things (like AWS)
* test machines
* etc
TPO machines are current...We currently have a few hosting providers and locations where we have "stuff":
* virtual machines
* colocated servers
* raspberri pi under desk
* routers
* "cloud" things (like AWS)
* test machines
* etc
TPO machines are currently documented in LDAP. But they are also in Puppet. And there's a spreadsheet (which we want to replace with something else, probably a grafana dashboard, in legacy/trac#29816). And there are many things (like AWS) which are not really tracked formally anywhere that I am aware of.
So this project is about establishing a clearer process to keep such an inventory. It should at least cover the following, TPO-managed infrastructure:
* physical servers
* virtual machines on those physical servers *or* on other cloud providers
Ideally, we would also have a unified view of this for all machines paid for by TPI, regardless of the team.
Each machine should have documentation on:
* remote console access or control panel
* cost
* location
* responsible team
* purpose
* age and lifecycle (see parent legacy/trac#29304)
The last bit is of course related to another problem, which is lifecycle management (see parent ticket legacy/trac#29304).
A lot of that stuff is currently in LDAP and maybe it should just be added there. But I wonder if it would be useful to create another system (which might eventually supersede LDAP) that would be more flexible. If that process would happen at all, we would first need to thoroughly document how hosts are integrated into LDAP and so on, of course.cleanup and publish the sysadmin codebasehttps://gitlab.torproject.org/tpo/tpa/team/-/issues/29304Manage the lifecycle of systems2022-12-20T19:25:37ZJens KubiezielManage the lifecycle of systemsDuring the sysadmin meeting in Brussels we discussed our infrastructure. Systems are managed by service admins/owners. They sometimes disappear or services become irrelevant. This means we have systems without proper owner which are rott...During the sysadmin meeting in Brussels we discussed our infrastructure. Systems are managed by service admins/owners. They sometimes disappear or services become irrelevant. This means we have systems without proper owner which are rotting over time.
To better handle such systems we decided that systems like `$host.torproject.org` should have an expiration date which is initially one or two years in the future. When the expiration date is near the service owner receives an email informing about the possible shutdown and the means to prevent it (write an email answer to tpa). If the mail is answered the expiration date will be prolonged. If not, the system will be deactivated. The deactivation can easily be revoked. However after some more time without any feedback the host will be decommissioned.
This ticket is to track the several steps for implementing this new policy.