Considering this has since been scoped as being just the Cassandra cluster, I believe we can call it complete.

In T219831#5135390, @JBennett wrote:

@Eevans @Clarakosi This one is a bit out of our wheelhouse and something we can provide only a cursory review of. I'd like to propose the following: The Security team can perform a basic security review of this but I would recommend a secondary review by our 3rd party partners at BishopFox. That said, the 2nd review would incur some cost but I'm not sure how much. Do you have any budget available for something like that??

Production environment {{done}}

Dev environment {{done}}

I cannot speak to the keyspaces being dropped, but the statements LGTM!

Done.

In T221528#5127730, @mobrovac wrote:

Here are the creation statements for dev and production:

[ ... ]

Please review.

Details on test methodology, and some initial results are forthcoming, but to elaborate on comments made elsewhere:

Applied to the dev cluster; Done

This has been applied to the production cluster

In T221031#5113112, @Pchelolo wrote:

LGTM!

Let's first execute in deployment-prep and follow into production after we merge/deploy https://github.com/wikimedia/restbase/pull/1117 in beta to verify all good and correct?

Deployment-prep:

Production/staging DDL here

In T215533#5107326, @BPirkle wrote:

I have, on my local development wiki, a working KaskBagOStuff (naming suggestions welcome) that communicates with the development instance at deployment-sessionstore01.deployment-prep.eqiad.wmflabs (via some tricky port forwarding) and successfully allows basic session management for happy login and logout.

Out of curiosity, what is it that prevents you from using RESTBagOStuff?

RESTBagOStuff is hard-coded to use PUT, while the API uses POST. Also, RESTBagOStuff is hard-coded to use PHP serialization for the value data, which I'm guessing nobody is in favor of. (Well, Joe wanted "json storing base64-encoded serialized php"... <grin>)

I rearranged things a bit so that RESTBagOStuff and KaskBagOStuff share almost all their code, except overrides for the essential differences, so there's not really going to be a lot of new code for this, mostly just some shuffling.

I think most of these are probably best addressed by someone familiar with session management in MediaWiki, but...

In T219560#5102752, @gerritbot wrote:

Change 502890 merged by Dzahn:
[operations/puppet@production] sessionstore: add super_username,super_password to Hiera

https://gerrit.wikimedia.org/r/502890

In T219560#5088509, @Dzahn wrote:

@Eevans I did both, the private repo part just doesn't show up on ticket.

@Dzahn I think this was just for labs/private.git, could you do the same for production as well? Thanks!

In T219883#5078192, @daniel wrote:

In T219883#5078122, @Eevans wrote:

Could fixures be decoupled from the test specification? The former would seem to require a great deal more flexibility than the later; Would it be easier to implement them as code, rather than define a DSL to cover every possibility?

I was thinking of using XML dumps to define fixtures, or simply SQL dumps. But XML dumps can't create user accounts, and SQL dumps won't for for extensions that need extra fixtures.

In T219883#5077944, @daniel wrote:

I discussed re-using service-checker with Marko, and it may be an option for CI, but could be a bit cumbersome locally. Our conclusion was that the functionality is trivial enough to make re-implementing the best choice.

@daniel Are you aware of service-checker? It is invoked by Icinga and uses the x-amples stanza to monitor endpoint availability. We need this capability in Kask (session storage), but I've been reluctant to implement an OpenAPI/Swagger specification, just to have a data-structure to hang an x-amples off of. The alternative was to define an alternative structure, and then teach [[ https://github.com/wikimedia/operations-software-service-checker | service-checker ]] to use it.

We are well past the design at this point (targeting deployment for Q4 2019); Closing as resolved.

Automatic schema migrations. In a large cluster, it's been proven that automatic schema migrations do not work - the process takes a long time and needs to be closely monitored, so it has to be performed by a Cassandra DBA. Quite a bit of code and tests in restbase-mod-table-* packages is dedicated to schema migrations, and this code needs to be removed.

This was completed some time back; Closing

In T219404#5062456, @RobH wrote:

For now lets wait for @Eevans to comment with the plan on what new servers are replacing what old servers for further info.

Kask performance testing is on-going, but I wanted to share some initial (early) results:

In T217650#5035879, @akosiaris wrote:

In T217650#5033562, @Eevans wrote:

Kask has now been setup for session storage in deployment-prep using docker_services (deployment-sessionstore01.deployment-prep.eqiad.wmflabs); I have a few questions about how this all will work in production (and presumably deployment-prep, at some point in the future).

• The name used in docker_services is a normalization of the Git repo name (i.e. mediawiki-services-kask here), will this also be the case when deployed to k8s in production?

More or less. It will be the name of the image that is used in the helm charts. But not in anything else.

Kask has now been setup for session storage in deployment-prep using docker_services (deployment-sessionstore01.deployment-prep.eqiad.wmflabs); I have a few questions about how this all will work in production (and presumably deployment-prep, at some point in the future).

In T215533#5024386, @EvanProdromou wrote:

Should this task go to @BPirkle now?

In T132632#5023075, @mobrovac wrote:

@Eevans @fgiunchedi should we go ahead with this?

From an IRC conversation: