Ok, these keyspaces have been removed from production, dev, and deployment-prep. Out of an abundance of caution, I will leave this open until Friday, and close after cleaning up the snapshots.

In T248018#6000114, @Pchelolo wrote:

LGTM. Beta cluster has one as well

In T248018#5999449, @Pchelolo wrote:

This has been deployed, so we can drop those key spaces!

In T239856#5966749, @Pchelolo wrote:

Is there anything left to do/review here?

In T243544#5947739, @hnowlan wrote:

I've overhauled things and moved stuff to a more Debian-compliant layout here: https://github.com/nosmo/cpp-driver/tree/debian/debian
Still not sure if this is up to snuff though, needs some testing.

In T137419#5935635, @Aklapper wrote:

In T137419#4395956, @Eevans wrote:

This is actually something we should be following up on with upstream more aggressively.

@Eevans: Hi, do you plan to do this? Asking as you you have been task assignee for a while now.

Yeah, it's ready to be closed, but AFAIK, we're supposed to wait for the PM (@CCicalese_WMF) to close it after moving it to Done on the workboard.

I believe this is pending https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/574034 (T224712).

I don't think this is sessionstore, (at least, it's not the timeout issue with Cassandra that we saw before).

In T244508#5866291, @Dzahn wrote:

@Eevans You should have +2 on the mw-config repo now. Probably after logging out and back in.

This is complete.

I believe we have consensus around de-deploying restrouter from k8s, @WDoranWMF can you confirm?

In T244178#5846225, @Pchelolo wrote:

All these steps should be done after Cassandra is bootstrapped. See T219404 for the ticket where fresh deploy was done the previous time.

In T243544#5842056, @hnowlan wrote:

Interestingly there is already a packaging script in the repo for the driver, we can either reuse or adapt this - there doesn't seem to be much custom stuff in it https://github.com/datastax/cpp-driver/blob/master/packaging/build_deb.sh

Kask has been updated with higher (default) Cassandra timeouts, and deployment-prep has been updated. I'm going to close this, feel free to re-open if this happens again.

The default timeouts in the Cassandra Go driver, both Timeout and ConnectTimeout are 600ms. This seems quite low, by comparison the Java and NodeJS drivers both use 12s and 5s respectively. I propose we make these values configurable in Kask (with defaults of 12s and 5s).

It looks like Cassandra queries from Kask have been intermittently timing out. Both Kask and Cassandra are co-located on the same VM, and it is pretty resource constrained, but AFAIK it has been working OK to this point; We can probably begin with a restart and go from there

TTBMK, everything here is done.

Done.

Done.

In T242461#5798385, @Eevans wrote:

In T242461#5797481, @akosiaris wrote:

In T242461#5793618, @Pchelolo wrote:

Since (long-term) we aim to replace all of this, is abandoning it entirely an option?

Is it possible to take it out for now until we either prioritize it again or drop it entirely?

You mean undeploy? Sure we can undeploy it. The only caveat being that redeploying it will take some time as we will need to create the necessary resources again (LVS entries, DNS, kubernetes namespaces etc).

We're running CI for RESTBase in both RESTBase and RESTRouter modes, so it will be in mostly deployable state if we want to put it back online, however maintaining an unused production deployment seems like a waste.

Indeed.

A lot has changed since we began this migration, including https://www.mediawiki.org/wiki/Core_Platform_Team/Decisions_Architecture_Research_Documentation/Services_Architecture_Recommendations_(2019), which is expected be a lengthly process, but will ultimately result in REST{Router,Base}-less world. I guess the question we should be asking is: Is this still something we should do in the meantime (and schedule and resource to complete), or should we cut bait, undeploy from k8s, and leave things as they are?
@WDoranWMF ?

In T242461#5797481, @akosiaris wrote:

In T242461#5793618, @Pchelolo wrote:

Since (long-term) we aim to replace all of this, is abandoning it entirely an option?

Is it possible to take it out for now until we either prioritize it again or drop it entirely?

You mean undeploy? Sure we can undeploy it. The only caveat being that redeploying it will take some time as we will need to create the necessary resources again (LVS entries, DNS, kubernetes namespaces etc).

We're running CI for RESTBase in both RESTBase and RESTRouter modes, so it will be in mostly deployable state if we want to put it back online, however maintaining an unused production deployment seems like a waste.

Indeed.

It's not clear to me what the status of this is. Do we need to deploy the latest code here? Since (long-term) we aim to replace all of this, is abandoning it entirely an option?

The tables have been dropped in all 3 environments. The only thing remaining is to clear the snapshots (and actually reclaim the space). Out of an abundance of caution, I'll sit on this for a couple days and close the ticket once complete.

OK, here is what I propose applying; Review appreciated!