<div dir="ltr"><div>On Tue, Aug 19, 2014 at 12:38 PM, Chris McMahon <span dir="ltr"><<a href="mailto:cmcmahon@wikimedia.org" target="_blank">cmcmahon@wikimedia.org</a>></span> wrote:<br></div><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">* ...Right now performance on Jenkins is the main cause of false test failures, not only browser tests, but unit tests, qunit tests, etc.</div></blockquote><div><br></div><div>Do you think the continual sporadic getaddrinfo failures[1] and  timeouts running browsertests on SauceLabs are due to jenkins performance?<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">** ... a beta1 that adheres to our old policy of "nothing except master branch of code and config already in prod" and a beta2 for our current policy of "code that will be in prod eventually but is not now" <br></div></blockquote><div>Names matter. "deploy-test" and "beta"?  "gamma" and "beta"?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div> ** Novel uses of vagrant and/or docker, such as the ability to easily create and provision a shared test environment for a particular dedicated purpose like a demo without having to build an entire mediawiki cluster from scratch.</div></div></blockquote><div><br></div><div>That sounds like "create a labs instance", but with fewer pain points. Clients like Jared Zimmerman can best express what they need for demos and UX testing, but I think their problems include<br></div><div>* Loading a default useful set of content, media, and templates. I have no idea how to automate this.<br></div><div>* Only having to do additional tweaking for the demo or test setup once. As I understand it, OpenStack can take a snapshot of a running instance.[2] but we don't expose this. So for demos or UX tests, one could set up the test wiki, take a snapshot and then reload the snapshot for each demo or test. <br><br><br>It would also be useful to automate keeping test instances up to date and matching production config. For code there's `vagrant git-update`, but it doesn't work in labs-vagrant; for configuration the vagrant settings.d system doesn't share anything with production's wmf-config/{CommonSettings,InitialiseSettings}.php. Could the puppet code that makes beta-labs work so well "do the right thing" when run on a single labs instance?<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div>Note that these are really good problems to have.<br></div></div></blockquote><div>+++ :)<br> <br></div></div><br>[1] <a href="https://bugzilla.wikimedia.org/show_bug.cgi?id=68125">https://bugzilla.wikimedia.org/show_bug.cgi?id=68125</a><br>[2] <a href="http://docs.openstack.org/openstack-ops/content/snapshots.html">http://docs.openstack.org/openstack-ops/content/snapshots.html</a><br clear="all"><br>-- <br><div dir="ltr">=S Page  Features engineer<br></div>
</div></div></div></div>