Extension:CentralNotice/Phase 2

Central Notice Team members: Tfinc, Kaldari

Feature justification

Central notice is meant to be a global messaging system for WMF but lacks a number of key features that other systems provide.

• Geo located banners
• Admin log of changes
• Relative percentages

User requirements

• Ability to deliver banners by country and eventually by city.
• An easy way to understand what work has been done in the system through an admin log
• An easy way to understand the current state of the system and what the relative % of impressions any one banner might have

Specification

GeoIP

Using the internal Wikimedia GeoIP service serve the currently enabled campaign. We would need the ability to lazy load the banner possibly in an iframe.

Admin Log

The Admin log at a minimum would have to display

• Campaign enabled/disable, date changes, preferred changes, deletions
• Banner ads/deletes
• New campaigns
• Slot assignments.

Relative %'s

We would need a simple way for a user to understand the actual amount of views any banner might actually get. This would require knowledge of what campaigns are running and calculating the actual display % of the configured banners.

Software design document

In order to support geo functionality and the features in phase 3 were going to need to re-architect the loading mechanism for Central Notice. Instead of the current "one request pulls all banners" method were going to two move to a multi-stage loader.

When a visitor requests a Wikimedia project page they will initially issue two CentralNotice calls from the HTML head:

• a request to the CentralNotice extension that returns a small amount of JS that will act as a controller
• a request to geoiplookup.wikimedia.org that sets the user's geo information as a JSON object in a global JS variable

The client-side controller then uses the geo information to issue a new request to the CentralNotice extension that returns a simplified list of banners that they could be shown along with their weights. The controller then picks one of the banners and requests it from the CentralNotice extension in the user's interface language.

This is a large departure from our previous architecture and will break backwards compatibility with our previous loader. While it will increase the number of requests on every Wikimedia project page it will lessen the page request size as we will no longer be serving back banner content for a banner that will never be shown.

Caching

The caching plan for these requests are:

• controller (static) - squid - 2 hours (18000) server-side, 2 hours (18000) client-side (move to varnish?)
• geo - varnish - no caching (controlled by Mark)
• banner list - squid - 15 minutes (900) server-side, 15 minutes (900) client-side
• banners - squid - 15 minutes (900) server-side, no cache client-side (server-side cache can be extended once a versioning system is in place)

Test plan

We'll be able to do limited testing on tesla and test wiki to see how well the GeoIP functionality works. Testing the new loader is difficult as the current Wikimedia architecture can't do an a/b test per extension with a % of web traffic. We'll be heavily leaning on our staging and dev servers to do all of our functional tests.

Documentation plan

• Add caching switches for ops.

Schedule

GeoIP and new Loader

• Code Review: 9/13-9/14
• Fixes, Testing, Production Staging: 9/14-9/20
• Production Test: 9/20 (late afternoon PST)

• Release was rolled back due to lack of the ability to pull messages from alternate databases. We've rolled back the deployment branch to r72135 and are assessing our options.
  • Rescheduled to 9/27 with new JSONP implementation blessed by Tim
    • SUCCESSFULLY DEPLOYED

note: we also pushed out an early version of allocation tracking

Admin Log

Deferred until after 2010 fundraiser.

Relative %'s

• SUCCESSFULLY DEPLOYED

Task management

(e.g. link to relevant Bugzilla queries)

Release management plan

1. Disable all campaigns
2. Regen
3. Disable regen
4. Turn off cn for all projects except meta and test
5. Sync code
6. Test meta and test wikipedia
7. Test cswiki
8. Test dewiki
9. Make default

Community management plan

Engage with key stake holders like Casey, Alex, and chapters.