21:11:48 <gilles> #startmeeting Shared hosting support definition
21:11:48 <wm-labs-meetbot> Meeting started Mon Dec 21 21:11:48 2015 UTC and is due to finish in 60 minutes.  The chair is gilles. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:11:48 <wm-labs-meetbot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:11:48 <wm-labs-meetbot> The meeting name has been set to 'shared_hosting_support_definition'
21:12:01 * _joe_ out
21:12:52 <gilles> so, is it possible to define "shared hosting support" more granularly?
21:13:20 <hashar> #link https://phabricator.wikimedia.org/T113210 How should the WMF support non-technical mediawiki installs?
21:14:04 <hashar> I really liked the introduction of the browser compatilibilty matrix
21:14:12 <hashar> and grading them.
21:14:16 <gilles> if we start talking about "graded support" definition, what would that look like? "required" "recommended"? like PHP, Apache and MySQL would fall in "required" for mediawiki core, and IM would be "recommended" for example
21:14:35 <gilles> or is that the wrong way to look at it?
21:16:25 <hashar> for MediaWiki for a long time we ensured lot of features run on a basic PHP compilation
21:16:37 <hashar> going as far as proposing pure PHP versions for some pecl extensions
21:17:12 <hashar> or having different "backend" services that should fit most needs
21:17:23 <hashar> the cache for example,  you can use either squid/varnish or a file based cache
21:17:42 <hashar> the backend caches can be memcached/apc/database
21:18:18 <gilles> yes, I think that having multiple options is a recurring problem, but I also notice that a lot of the time we have one well supported one and several other options that are actually not getting proper support. starting with alternative DBs, for example
21:18:20 <SMalyshev> I see there grading of platforms, but should there be also grading of extensions? i.e. "we should ensure CirrusSearch runs on the platform before we declare MW fully supports the platform"?
21:18:48 <gilles> yes I think that extensions would need their own compatibility grids
21:18:53 <gilles> ideally using the same format as core
21:20:05 <SMalyshev> gilles: that's for sure but I'm asking about something slightly different - should we also have a priorities between extensions? i.e. if we discover extension X does not work on platform Y, how is it important for WMF to invest in fixing it?
21:20:08 <gilles> for things where several options are available, I think we could have a "support" level for each. "WMF-supported", "community-supported", "unsupported" for example
21:20:25 <gilles> because when we say "you can use MSSQL" it's basically a joke
21:20:43 <gilles> but if it was listed as one of the options, you wouldn't know that
21:21:29 <gilles> SMalyshev: yes I guess that for browsers we have a universal baseline that all extensions and core abide to
21:21:34 <gwicke> given limited resources, I think we should put more effort into making a standard install work really well than pretending to support all kinds of impossible permutations
21:22:16 <SMalyshev> gwicke: so, standard install implies standard list of extensions?
21:22:37 <gwicke> definitely some, yes
21:22:48 <gwicke> VE is a no-brainer, for example
21:22:49 <hashar> I would say right now the supported extensions are those shipped in the release tarball
21:23:49 <cscott> the permuations are a good place to leverage the community.  let the person who really cares about MSSQL support maintain that (or not, if nobody cares about it)
21:24:15 <subbu> another option would be to say what a standard install is for different hosting platforms: shared hosting, containers, vps, etc. for example
21:24:23 <cscott> for databases, eg, i'd say the things we really support are mysql and sqlite (the latter because we use it in jenkins)
21:24:46 <gilles> subbu: like for a given extension you'd see if it has support for each of those?
21:24:50 <cscott> if we're not regularly running tests on a particular code path, i don't think we can say it's supported.
21:24:51 <subbu> so it is clear that if someone wants shared install, they won't get VE which might be okay for some wikis.
21:24:54 <hashar> Postgre has lot of community support but it does not leverage any of Postgre ability so there is little point
21:24:55 <subbu> gilles, yes.
21:25:19 <gwicke> that's still quite a few permutations
21:25:20 <gilles> "shared hosting" is a bit vague, though, as it depends on the specific host's willingness to install services
21:25:46 <gilles> we'd have to define what that smallest common denominator has
21:25:57 <gilles> our own definition of "typical shared hosting", I guess
21:26:27 <subbu> to me, it is clear that smallest common denominator is php+apache .. i haven't seen any conversation or discussion so far that has advanced it beyond that basic setup.
21:26:36 <hashar> I don't think we ever firmly defined the minimum requirements
21:26:38 <gilles> and mysql :)
21:26:51 <subbu> yes.:)
21:26:53 <hashar> and some code paths are barely tested
21:26:55 <gilles> so what would that be? minimal requirements? just those 3?
21:26:58 <gwicke> it's really PHP and $webserver
21:27:23 <hashar> Apache is not even a requirement afaik
21:27:26 <gwicke> but, you are getting an experience that's far from what you might have expected when you signed up for "what Wikipedia uses"
21:27:27 <gilles> right
21:27:38 <subbu> rather than get into these endless debates / discussions about shared hosting, containers, vps, deb .. maybe specify a small subset of hosting platforms, and what the support is for each.
21:27:46 <SMalyshev> so should we have a list of extensions which work with pure php/mysql? and maybe a list of those that is important to keep working with pure php/mysql?
21:27:47 <cscott> subbu: node-mediawiki-express replaces apache w/ node.  but yes: php + some web server.
21:27:55 <hashar> and one could suggest using sqlite for degraded perfs :-D
21:28:27 <gilles> so, any objections to have a matrix of "hosting types" with each having a support level value? for core and each extension
21:28:46 <hashar> based on composer.json we have a requirement for the PHP extension  iconv.  We probably require some others as well but I guess they are not explicitly defined because most distro compile PHP with them
21:28:53 <SMalyshev> also, should we have a test suite that would install those on minimal envt and actually checks they work?
21:29:02 <hashar> SMalyshev: +2
21:29:42 <hashar> part of the reason sqlite is so well supported is that we have been running CI with sqlite as a backend.  Though CI now uses MySQL
21:29:44 <gwicke> I think we should approach this more from a user perspective
21:30:12 <hashar> but we first need to define some basic support matrix I guess.  Then come up with test patterns to ensure we do not break our requirements
21:30:13 <cscott> iconv is optional, we only use it for some i18n support.
21:30:21 <gwicke> as a small wiki user, I don't want to spend $X per month, and don't want to deal with OS maintenance
21:30:22 <cscott> if not present, php falls back on a pure-php implementation
21:30:24 <gwicke> tell me what to do
21:30:39 <gilles> well, I'm a user, I use a VPS, I'd go to an extension page. first thing I see is that VPS is supported, good. then I'd like to see a list of software to install to make that extension work, or even a command I can copy+paste
21:30:45 <gilles> same for container, etc.
21:30:58 <subbu> gilles, +1 on the matrix.
21:30:58 <gwicke> I would suggest to start at the other end
21:31:04 <hashar> the kind of host is irrelevant imho
21:31:20 <hashar> it is what the host can ship which matter
21:31:24 <gwicke> I'm a user with budget X and skill Y, and want features A, B, C; what should I use?
21:31:52 <gilles> gwicke: would you go to mediawiki.org to answer that question, though?
21:32:11 <gilles> I guess we could have a wizard of sorts that answers that question for you
21:32:12 <hashar> the actual support will vary between VPS hosts / shared hosts
21:32:13 <SMalyshev> gwicke: "want features" is not that clear though - if you want search, do you need CirrusSearch or not? that depends on size of the wiki, speed, etc.
21:32:24 <gwicke> gilles: if there were clear recommendations, then probably yes
21:32:51 <gwicke> and few options = good for most users
21:32:58 <subbu> gwicke, gilles i think the user budget/skill/feature matrix and the hosting type matrix are orthogonal .. i think the latter is more about what the wmf is willing to support.
21:32:58 <gilles> I guess then that a wizard where people can pick budget and features and gives you a list of hosts that match your criteria?
21:33:08 <hashar> gilles: definitely
21:33:28 <gwicke> gilles: wizard sounds too complex
21:33:29 <gilles> subbu: right, I think both things solve a different problem and can coexist
21:33:40 <subbu> yes.
21:33:59 <gwicke> I really think we should focus our efforts on less than 3 options
21:34:25 <gwicke> just enough to cover the main use cases
21:34:36 <cscott> just enough to run CI tests on all three options before commit
21:34:46 <cscott> that's what i'd say.  if we don't test it, we don't support it.
21:34:58 <gilles> now we established earlier that containers are unlikely to replace shared hosting, but could containers eat the VPS market completely in a few years?
21:34:58 <cscott> but we can't run tests on tens of different permutations
21:35:11 <gilles> that would make a good case for caring about containers rather than VPS in all of this
21:35:26 <gwicke> containers typically run in a VPS
21:35:39 <gwicke> no conflict there
21:35:45 <hashar> potentially but I don't think it is our role lead the migration toward containers
21:36:24 <gilles> if containers live inside a VPS, then our support buckets are really just "shared hosting" and "server you have full control over"
21:36:47 <gilles> and I don't see how some extension could ever not run on a server where you can do what you want...
21:37:02 <gilles> so really this becomes binary about where some extension runs on typical shared hosting or not
21:37:08 <gilles> whether
21:37:45 <hashar> for requirements, I guess whenever you have full control of the host you should be able to get them installed
21:37:49 <gwicke> okay, so I guess we agree that we don't need a wizard
21:37:53 <hashar> whether it is redhat/debian a VPS or a container
21:38:00 <hashar> for shared hosts, it is slightly more complicated
21:38:10 <hashar> different shared host will provide different set of packages / versions
21:38:25 <hashar> so you would need a finer list of requirements than just the type of hosts
21:38:34 <gwicke> if you are willing to spend $5 / month and want full functionality, get a VPS with distro X, Y or Z and run this command in a shell
21:38:56 <hashar> so if you want i18n , you will want a host that ship PHP with iconv / mbstring
21:39:01 <gwicke> else, follow these instructions for shared hosting
21:39:21 <cscott> ...if you want to use node-based shared hosting then...
21:40:00 <gilles> can't we just have a simple list of software dependencies and minimum versions?
21:40:11 <gilles> I would expect to have that on the right-hand side of https://www.mediawiki.org/wiki/Extension:VisualEditor for example
21:40:18 <gwicke> for non-technical users, that's not very helpful
21:40:27 <hashar> gilles: we have already. In /INSTALL and on https://www.mediawiki.org/wiki/Manual:Installation_guide
21:40:40 <hashar> look for the gray box "requirements in a short"
21:40:53 <gilles> hashar: yes but not per-extension
21:40:58 <hashar> eg:
21:41:00 <hashar> "Image thumbnailing and TeX require additional programs. Parsoid (required by VisualEditor) and other services have their own requirements."
21:41:24 <gwicke> my point is that there needs to be a simple option for most non-technical users
21:41:33 <hashar> for extensions there is some effort with the extension registry system. I am not sure it has fields listing requirements
21:41:39 <gwicke> no reading of dependencies, versions, distros etc
21:41:48 <gwicke> do this & it will work
21:41:49 <hashar> some extensions have composer.json which might or might not list requirements
21:42:31 <hashar> gwicke: well the mediawiki installer does check for requirements and bails out when one is missing
21:42:46 <gilles> gwicke: so walk us through the end-user experience
21:42:56 <hashar> in some occasion we released a version for which the installer suddenly required  an optional dependency which broke the install
21:42:56 <gilles> what would you expect?
21:43:08 <gwicke> follow instructions on how to buy a vm
21:43:13 <gwicke> run a command in that vm
21:43:26 <gwicke> and start using the wiki
21:43:36 <gwicke> upgrades should be automated
21:43:46 <gwicke> ideally, ssl too
21:43:50 <cscott> LocalSettings.php tweaks should be discouraged
21:43:54 <gwicke> https://letsencrypt.org/
21:44:01 <cscott> (as in, not required)
21:44:19 <robla> gwicke: that sounds like a good vision, but I'm not sure on what the path to that vision looks like
21:44:54 <cscott> "upgrades should be automated" -- like chrome, it just updates itself without asking?
21:45:00 <robla> what are the incremental changes we can make to our software to get to that end point?
21:45:08 <cscott> or automated == there's some button in the web ui the user can press to upgrade the wiki
21:45:20 <gwicke> cscott: yes; basically, restart & upgrade once per night
21:45:28 <gwicke> or $period
21:46:00 <cscott> you need a little bit of care to ensure the entire world doesn't hit mediawiki.org looking for updates at 12:01am UTC every night.
21:46:16 <cscott> but yeah, i'm generally in favor of upgrade-by-default
21:46:41 <cscott> you might start by building the upgrade-check functionality into core
21:46:56 <robla> ckoerner: does "upgrade once per night" seem viable with the hosts you're familiar with?
21:47:14 <cscott> chrome has this, downloads the upgrade in the background, then changes color of the hamburger icon to indicate "an upgrade is ready, restart when you're ready"
21:47:41 <cscott> we might have some sort of echo integration to message the sysadmin when a new upgrade is ready; that would just most of the same infra that fully automated upgrades would use.
21:47:44 <gwicke> the startup script in https://github.com/gwicke/mediawiki-containers fetches the latest containers on each startup
21:48:01 <gwicke> & runs migrations in each of them
21:49:24 <gwicke> I think the best way to make progress with a reasonable cost is to minimize the amount of variance we need to account for
21:49:27 <hashar> I would not do auto upgrade
21:49:35 <hashar> but having an ability to check for upgrade would be neat
21:49:46 <subbu> i think there are two separate threads here (even if related) .. (a) what should wmf devs test/develop against in terms of promised support (b) what are the installation options available to users (and ease of use, upgradation, docs, etc.)?
21:49:53 <hashar> as well as one clickable upgrade.
21:50:27 <hashar> Jenkins does it http://blogs.mathworks.com/developer/files/2015InstallTAPPlugin.png
21:50:29 <subbu> s/wmf devs/mediawiki devs/
21:51:06 <robla> great point, subbu !
21:51:11 <subbu> to me, auto-upgrade seems tricky with breaking changes
21:51:12 <cscott> one-clickable upgrade from the web ui?  given a tar bundle, presumably?
21:51:42 <hashar> or a .phar :-}
21:51:45 <cscott> subbu: i think auto-upgrade entails a much greater attention paid to changes which might break
21:51:45 <gwicke> subbu: it requires good testing before releasing a new version
21:51:46 <gilles> subbu: yes supporting automatic upgrade/migration forever is quite a constraint to live with int he long term
21:52:18 <gwicke> but, it's a lot more tractable to do this for a fairly constrained configuration than for hundreds of possible permutations
21:52:20 <cscott> plus automated testing, of course -- we should be running the automated upgrades *before* they are pushed to users, so we can check any breakage before it hits the general public
21:52:24 <subbu> gwicke, cscott it is not just testing and attention but the promise of migration scripts that gilles mentions
21:52:34 <gilles> but, to circle back to the original theme, shared hosting, could auto-upgrade work in that sort of environment?
21:52:34 <subbu> i am not yet convinced we are there yet.
21:52:42 <cscott> subbu: yeah, but mediawiki-core already runs migrations on upgrade.
21:52:50 <hashar> cscott: openstack does that.  They run their patches against a test suite which attempt to upgrade from the last supported versions
21:53:01 <subbu> cscott, what happens when there are changes to wikitext spec?
21:53:13 <cscott> hashar: yeah.  and i did implemented it with the upgrade system at olpc and litl as well.
21:53:14 <gwicke> RB also runs migrations on each startup
21:53:15 <hashar> cscott: so install MediaWiki 1.23 + extensions,  update to REL1_26 packages, run update, run tests. Report
21:53:33 <cscott> subbu: same thing as when chrome updates the version of HTML they support
21:53:50 <cscott> subbu: they roll it out in stages, and sometimes roll back an update if it breaks too much of the web
21:54:00 <hashar> the one for database migration is named "Turbo Hipster" https://wiki.openstack.org/wiki/Nova/Turbo-Hipster
21:54:05 <cscott> but every feature is first available behind a opt-in flag first.
21:54:08 <gwicke> if you are serious about supporting upgrades for non-technical users, you need to fully automate & properly test them
21:54:18 <SMalyshev> gilles: the main problem would be non-BC changes and extension upgrades. You need to be very careful not to try and run new-version code against old-version platform and vice-versa.
21:54:29 <gilles> cscott: that's an even bigger infrastructural project. how do you even check that you didn't break 3rd-party wikis?
21:54:31 <subbu> i am not saying it is not doable ... but is that the discussion we are having now?
21:54:57 <hashar> gilles: you roll in batches to different corpus. That is what we do when pushing code to the wikimedia site
21:55:20 <hashar> gilles: with various groups of wiki.  mediawiki.org being among the first since it produces useful bug reports from end users
21:55:38 <hashar> and IIRC mobile is doing the same. The Play Store has different channels
21:55:55 <hashar> so you can push alpha, beta,  tech savvy,  US only, worldwide  (don't quote me)
21:55:55 <gwicke> docker has tags for this
21:55:55 <gilles> ok, auto-upgrade sounds like a cool project, but it doesn't solve how honest and documented we are about shared hosting support right now
21:56:07 <gilles> which is what we should be discussing
21:57:00 <hashar> I would organize the features in tiers
21:57:04 <gilles> if extensions define that they don't support shared hosting, then I guess it's a non-issue and the fancy world of having control over your server can get all the goodies
21:57:16 <hashar> and depending on what you platform provides, you would be eligible to some features
21:57:20 <gilles> but we should have that clearly communicated
21:57:31 <robla> hashar: as opposed to organizing our features in tears  ;-)
21:57:43 <hashar> and again shared-hosts have different capabilities!
21:57:56 <SMalyshev> gilles: absolutely. And for those that do declare support for shared hosting, aka minimal config, at least core ones, there should be tests to ensure that
21:57:58 <hashar> robla: :-))))))))))
21:58:00 <subbu> hashar, i think we define what we mean by 'shared hosting'.
21:58:25 <subbu> rather than overload the term 'shared hostng' to mean all kinds of variabilities .. let hostin gproviders market their support as shared-hosting++ or +++ or something like that.
21:58:34 <SMalyshev> hashar: I think we need to define "minimally viable shared hosting"
21:58:43 <gilles> we could have granular software requirement definitions, but there's no easy way to map that to which hosts support them
21:58:43 <hashar> to me shared-hosting is a host on which you have limited privileges such as the inability to install additional packages or upgrade versions.
21:58:43 <SMalyshev> aka "config we use in testing" :)
21:59:04 <gwicke> "it's complicated" ;)
21:59:22 <subbu> me.org+VE shared hosting for ex.
21:59:30 <gilles> subbu: so we define the support buckets and ask shared hosts to state which one they belong to?
21:59:41 * subbu is handwaving at this point :)
21:59:43 <hashar> and for that minimal version you really only need:  file access (eg: FTP), data backend (sqlite or mysql), PHP 5.3.3
21:59:53 <SMalyshev> we won't cover 100% but if we cover 80% that's good
22:00:20 <SMalyshev> maybe have a script that you could upload to shared host and if will check if it's ok?
22:00:41 <hashar> SMalyshev: that is what the mw installer does
22:00:42 <subbu> gilles, i was mostly trying not to go down the path of trying to capture all kinds of shared hosting solutions.
22:00:53 <subbu> and make 'shared hosting' an umbrella term/
22:01:02 <hashar> we ensure the installer works with the bare minimum. At least enough to run the various checks
22:01:02 <SMalyshev> hashar: cool then, so that's not a big problem
22:01:06 <gilles> I guess we could also have a list of hosts that support a given extension. Something collapsed by default. Ideally you'd want to be able to easily figure out the common hosts that support all the extensions you want...
22:01:37 <gilles> and it'd be up to them or community members to keep that up to date
22:01:42 <hashar> what I would like to see for each features their requirements
22:01:48 <subbu> i agree with gwicke that we need a small subset of installation options that we promise support for.
22:01:51 <hashar> eg I want VE,  I need nodejs (because of Parsoid)
22:02:19 <hashar> I want a powerful search ?   We recommend ElasticSearch, suggest whatever over super search system we have an extension for
22:02:38 <gilles> hashar: but this goes back to the novice user not knowing what node is. they know what dreamhost is, however
22:02:56 <cscott> gilles: you don't, you get feedback from the community.  that's how the HTML/JS standard is evolving.  potentially-breaking features are rolled out slowly, with good feedback paths and a quick update cycle if something actually breaks.
22:03:05 <hashar> click the link, popup a text box explaining what node is ? :D
22:03:44 <gwicke> that's a different user, who would probably be better served with simple instructions
22:03:51 <gwicke> shared hosting would be too complicated for them
22:03:53 <cscott> gilles: if they know dreamhost, they know heroku then.  (node-based shared hosting)
22:03:58 <gilles> but for the ideal case they don't need to understand that, if they pick the easiest hosting option. it'll be installed for them
22:04:07 <hashar> gilles:  something like "node is used to run a server but is different from PHP. To benefit from WYSIWYG support in MediaWiki your host would need to provide node support".
22:04:58 <gwicke> hashar: what is WYSIWYG?
22:05:19 <gwicke> you are targeting a fairly technical audience if you are using terms like this
22:05:34 <gilles> so maybe software requirement would work for shared hosting users then, who should be tech savvy enough to at least forward that list to a host and ask "do you have that?"
22:05:56 <hashar> gwicke: you got my point
22:06:12 <hashar> gwicke: explain in layman terms what node :-D
22:06:47 <hashar> for absolutely non tech savvy folks, I guess the "one click install" hosts is a better match for them
22:06:56 <gwicke> hashar: most users shouldn't need to care what node is
22:07:04 <hashar> unless you want VE
22:07:43 <ckoerner> robla (apologies for the long delay) once per night seems viable.
22:08:10 <subbu> gwicke, i think hosting providers can figure out how to do the marketing though. is it our job to figure out the marketing pitch for them so as to attract users?
22:09:07 <gilles> alright, I'm going to close the meeting because time is well over, but don't let that stop you from chatting on
22:09:09 <gilles> #endmeeting