Change Details

Since the move to magnum we are not actually using HA proxy in a significant manner. As it stands, until we have load balancing in openstack T326436, we will have a single control node. Which if it goes down we redeploy, not a simple and quick process that is used for upgrades as well as a potential recovery https://wikitech.wikimedia.org/wiki/PAWS/Admin#Deployment The effect of which is that while we still filter all the traffic through haproxy, we do not need to, and haproxy becomes a point of failure, along with acme chief that provides its cert (which has caused failures in the past T308383). We can cut out this and the ip heartbeat setup and, I believe, simplify to a plain web proxy setup by changing: hub.paws.wmcloud.org to hub-paws.wmcloud.org and public.paws.wmcloud.org to public-paws.wmcloud.org Maybe we could even convince someone to allow us to leave the hub.paws there (I don't believe we currently allow a . subdomain as a web proxy)

PAWS is in a position now that it could be updated to look much like any other cloud VPS project. Since the move to Magnum it no longer has a manually deployed kubernetes cluster, it uses Trove rather than a manually install DB. There are two things that it uses that are not cloud service in flavor, those are nfs, and its haproxy setup. I believe there is work going into making a cloud storage solution, so nfs will be ignored for this task. On the ingress side of things paws has a fairly complex setup and uses a floating IP, putting it outside the realm of how we would like to see projects use our services. This could be simplified by using a web proxy instead of a floating ip with associated dns entries, and an haproxy/acme-chief setup that manages and terminates tls. Rather this could all be collapsed into a web proxy pointed to a magnum cluster member. This would have a user facing change of: hub.paws.wmcloud.org would become: hub-paws.wmcloud.org and public.paws.wmcloud.org would become: public-paws.wmcloud.org This would be advertised long in advance, both to cloud announce and as a banner on paws itself. After which a VM could be setup to direct anyone who arrives from the old domains to the new domains for a time. We get some additional bonus improvements, the acme-chief/haproxy setup has failed in the past (T308383 is one such instance), removing them would prevent that. Additionally we would simplify the structure of paws lowering the bar to entry for anyone who might be interested in working on it. After doing this we have something of a flagship project that we can point to as an example of how one might want to be using cloud VPS. Giving us a clear example of a project that is using our services that doesn't feel like a toy project.

PAWS is in a position now that it could be updated to look much like any other cloud VPS project. Since the move to mMagnum we are not actually using HA proxy in a significant manner.it no longer has a manually deployed kubernetes cluster, As it stands,it uses Trove rather than a manually install DB. until we have load balancing in openstack T326436There are two things that it uses that are not cloud service in flavor, we will have a single control node.those are nfs, Which if it goes down we redeploy,and its haproxy setup. not a simple and quick process that is used for upgrades as well as a potential recovery https://wikitech.wikimedia.org/wiki/PAWS/Admin#DeploymentI believe there is work going into making a cloud storage solution, so nfs will be ignored for this task. The effect of which is that while we still filter all the traffic through haproxy,On the ingress side of things paws has a fairly complex setup and uses a floating IP, putting it outside the realm of how we would like to see projects use our services. we do not need toThis could be simplified by using a web proxy instead of a floating ip with associated dns entries, and an haproxy becomes a point of failure,/acme-chief setup that manages and terminates tls. along with acme chief that provides its cert (which has caused failures in the past T308383)Rather this could all be collapsed into a web proxy pointed to a magnum cluster member. We can cut out this and the ip heartbeat setup and, I believe, simplify to a plain web proxy setup byThis would have a user facing changing:e of: hub.paws.wmcloud.org towould become: hub-paws.wmcloud.org and public.paws.wmcloud.org towould become: public-paws.wmcloud.org Maybe we could even convince someone to allow us to leave the hub.paws there (I don't believe we currently allow a This would be advertised long in advance, both to cloud announce and as a banner on paws itself. After which a VM could be setup to direct anyone who arrives from the old domains to the new domains for a time. We get some additional bonus improvements, the acme-chief/haproxy setup has failed in the past (T308383 is one such instance), removing them would prevent that. Additionally we would simplify the structure of paws lowering the bar to entry for anyone who might be interested in working on it. After doing this we have something of a flagship project that we can point to as an example of how one might want to be using cloud VPS. subdomain as a webGiving us a clear example of a project that is using our services that doesn't feel like a toy proxy)ject.