@Krinkle Also, it sounds like we'd be changing the contract as loosely defined in the source code from 'Callers should be prepared for: Writes to be slower in non-"primary" (e.g. HTTP GET/HEAD only) DCs' to 'No writes on GET/HEAD'.

In T212129#5211137, @EvanProdromou wrote:

I'd assume there would be a lot of counters and so on that might need to be written to even on a GET request.

I'm not aware of any counters using the Stash.

So, per our discussion this morning, the rollout plan will be:

In T212129#5199079, @Krinkle wrote:

Yes, I think no TTL is the way to go. We don't want to lose this info.

All of this is a wee bit complicated by the fact that CentralAuthCookieProvider sets the session cookie expiration to null (expire at end of browser sesssion):

OK, I'm not sure if I'm reading this right, but it seems like CentralAuth session store uses the same backend as the per-wiki session storage, but will throw an in-memory cache around it if it's not already caching. See here:

Tagging Bill on this one, since he'll probably be most in control of the timing. Happy to help with the testing, though.

@aaron OK. I'm going to maybe just hit a page or run through a script on test wiki with siege or httperf or something similar and see if it starts throwing errors anywhere.

@Eevans Sweet. I'm going to use some 10% time to get smarter about Cassandra. Seems fascinating!

@sbassett I'm going to close this ticket. Is there a good way to bring Security into the loop as we roll this code out? As in, "We are rolling login-related code out, so keep alert."

In T221986#5284687, @Eevans wrote:

@Eevans and @BPirkle I feel pretty satisfied. I'm not a security professional, but I'm having a hard time thinking up other attacks than those listed. I have three questions left for you, and then I think we can close this ticket.

So, would the best way to do this be to configure test.wikipedia.org to use RESTBagOStuff and the production Kask service?

So, one way we could do this is with siege or something similar, hitting a Web page or API endpoint with a session cookie set. We could do a baseline comparison against production (?) and then get similar data for a staging service we set up for T222099.

This is an uninformed and inexpert analysis of potential security concerns with our upcoming session stack. I haven't looked at the code to see if any of these potential problems are mitigated. I hope that most or all of them are!

We had an email conversation with @sbassett about security review of this component. He reviewed @BPirkle 's patches on gerrit, and thinks that since the RESTBagOStuff code has been in master for a few years, we don't have to do a review.

We don't need this for using RESTBagOStuff with Kask for session storage, so I'm removing the parent task and untagging for this project.

We don't need this for using RESTBagOStuff with Kask for session storage, so I'm removing the parent task and untagging for this project.

@Eevans brought up the valid point that if this code is already in MediaWiki, and has only been altered somewhat to support Kask, that it may not need a security review.

We don't need this for Session storage so I'm removing the parent task and de-tagging.

We don't need this for using RESTBagOStuff with Kask for sessions, so I'm taking it out of the epic and removing the session tag.

Also checking in with @CCicalese_WMF to see if we can rebalance some resources.

I guess this task is stalled? I'll check with @Legoktm to see if we can move it forward.

So, it sounds like any additional code here would be to deal with a misconfiguration problem, where the configured TTL for MediaWiki and Kask are grossly mismatched.

I've created a ticket for doing the configuration options for RESTBagOStuff at T224993, so I'm closing this down.

So, we on CPT think that it's essential to use the job queue for large watchlists, because older code that did the deletion directly would time out.

So, it sounds like we've got a good split on this task. IMHO, the right way to do this is:

So, this doesn't seem to be a high-priority feature request, and we don't have a project this wedges into too well. I've put this into our Backlog, so if someone gets to it we'll pick it up.

@Anomie Somehow I managed to not read #5 very well. I think we're on the same page.

@Anomie One option neither of us brought up was developing the Parsoid routes as part of a MediaWiki extension. That would not only exercise the ability of the REST API Router to be useful for extensions, but it would allow us to manage the Parsoid interface without committing to master.

@Tgr yes, that's the plan.

@mobrovac and @Pchelolo it'd be helpful here to make sure we're doing this right.

We're dependent on T221988 for this.

This may be of interest to @daniel w/r/t strategies for decoupling

@Tgr @tstarling @Anomie per our discussion in sprint meeting

I'd assume there would be a lot of counters and so on that might need to be written to even on a GET request.

In T221177#5207250, @tstarling wrote:

Task description update: I'm explicitly limiting the scope so that we can move towards approval.

So, this isn't required for session storage. I'm going re-tag it, but I don't think it should block.

So, it seems like the MultiWriteBagOStuff does what we need. It will be slightly inefficient, since it will do unnecessary writes to the old store, but that will probably be OK and actually be more robust during rollout period.

The class comment says "Reads are implemented by reading from the caches in the order they are given in the configuration until a cache gives a positive result." The code seems to match.

It has different write semantics than you ask for though, as it will write to both the new and old stores.

@BPirkle the code for session storage doesn't deal with propagation delay because we haven't had multi-DC session storage before! ;-)

@aaron asked me to create tickets for all the TODO comments in RESTBagOStuff. This is one of those tickets.

I decided to put my time into T223510 so I'm going to shut this one down.

So, this is still an interesting project to me, but I think I'm going to work on T223510 instead. So I'm closing this but if someone else wants to give it a shot, cool.

OK, I jumped in and started this: https://gitlab.com/evanp/alexa-skill-update-wikidata/boards

Metaphacts created an Alexa skill to query Wikidata. Paper is at https://metaphacts.com/images/PDFs/publications/ISWC2017-Alexa-Ask-Wikidata.pdf .

I got intimidated trying to bring any sizeable board game on the plane from Canada, so I ended up just packing dice, cards, pencils and instruction books for a bunch of rules-light role-playing games. I'd love to GM a drop-in session.

As far as I can tell, the SessionManager code doesn't use the add() interface from BagOStuff.

Most important types to validate are in the routes to finish the Parsoid REST API, T221738. Looks like string and integer...?