On 13 May 2016 at 17:25, Sam Ruby <[email protected]> wrote: > TL;DR: whimsy3.apache.org is now operational. Details below. > > On 2016-04-23 10:49, Sam Ruby <[email protected]> wrote: >> We just got settled into whimsy-vm2, and I've already started working on >> whimsy-vm3. >> >> The precipitating factor was >> https://issues.apache.org/jira/browse/INFRA-11723; where the solution >> was to cache content that was statically being served by Apache httpd to >> another machine on another network... where it would be statically >> served by Apache httpd. > > I wonder if it would be worth undoing this? Either that or changing the code > to try to fetch from whimsy and then fail back to a local cached copy on > failure?
Although the problem with *really* slow responses was a temporary issue, it's definitely slower using remote access. Compare the current local access: http://home.apache.org/phonebook.html with whimsy access: http://home.apache.org/whimsybook.html or http://home.apache.org/whimsy3book.html Clear the browser cache to see the full effect. Using a fall-back mechanism would inevitably be slower for the cases when Whimsy was not responding promptly. Also I don't know how easy that is to do in Javascript. >> This supports the notion that the problem is either the network or the >> proxy. So I requested and obtained a new VM on a different colo >> facility and network: >> >> https://issues.apache.org/jira/browse/INFRA-11725 >> >> As a testament to puppet, the site is already sorta there >> (http://whimsy3.apache.org), the largest thing missing is the svn >> checkouts that the code requires. > > Puppet really made this easy. Only differences I noted: > > 1) on whimsy-vm3; most of the space is on /x1; so I changed the directory > layout > > 2) no proxy means that a signed cert is needed, and the apache configuration > tweaked accordingly > > 3) the HOME directory is different for CGIs; this affects the secretarial > workbench. Might be a consequence of #2 above. > >> Note that for the moment, the site is accessed via http instead of >> https; that's because this vm is NOT currently accessed via a proxy. >> I'd like to keep it that way at least initially so that can more easily >> determine where the actual problem lies. I'm working out the mechanics >> of obtaining an SSL cert for this, and that should be resolved in a few >> days. > > This is indeed fixed now. > >> If all goes well, I'll ask that the DNS entry for whimsy.apache.org to >> be updated to point to whimsy-vm3 before the next board meeting, and >> then to release whimsy-vm2 after that point. > > As this point, I'd rather wait until after the next meeting to make this > switch; I'll be using whimsy3 during the board meeting, and will be > encouraging others to do likewise. > > If anybody has any remaining need for whimsy-vm2 please speak up now; > otherwise it will likely go away by the end of the month. > >> The original whimsy-vm still hosts some unrelated tools (e.g., >> infra.apache.org and etherpad), and that would need to be addressed >> before that machine is released. > > I have no further need for this vm; but haven't spent any cycles trying to > figure out who else might. OK by me. I think we need to switch off most of the cronjobs on VM2 as soon as we can - the notification messages are currently duplicated. However this probably cannot happen until PingMyBox is talking to VM3. > - Sam Ruby
