* 7:00pm PDT (0200 UTC) www.mozilla.org DNS change. We’ll be offloading
www.mozilla.org to a CDN and pushing a DNS change to make that active.
This is a retry from lastweek’s attempt. No downtime is expected.
Please let me know if you have any reason why we should not proceed with
the planned maintenance. As always, we aim to keep downtime to as little
as possible, but unexpected complications can arise causing longer
downtime periods than expected. All systems should be operational by the
end of the maintenance window.
I'm on a 1 mbps DCL/SDSL Line. I thought that was fast enough.
current time is Sat 11:12.30 am
--
------------------------------------------------------------------------
Phillip M. Jones, CET http://www.vpea.org
If it's "fixed", don't "break it"! mailto:pjo...@kimbanet.com
http://www.kimbanet.com/~pjones/default.htm
Mac G4-500, OSX.3.9, 1.5GB Mac 17" PowerBook G4-1.67 GHz, 2 GB OSX.4.11
------------------------------------------------------------------------
> I'm on a 1 mbps DCL/SDSL Line. I thought that was fast enough.
>
> current time is Sat 11:12.30 am
Here it's Sat 17:20:10
--
Carl
* 8pm PDT (0200 UTC) - mozilla.com mail upgrade. We’ll be upgrading
Zimbra to 5.0.9. Duration 3 hours.
* 9pm PDT (0400 UTC) - Bugzilla upgrade. We’ll be upgrading Bugzilla to
version 3.2. Duration 4 hours.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
Feel free to let me know if you see issues past the planned downtime.
* 7:00pm PDT (0200 UTC) support.mozilla.com updates. We’ll be updating
support.mozilla.com to pick up code updates. No downtime is expected.
* 7:00pm PDT (0200 UTC) tinderbox.mozilla.org updates. We’ll be updating
tinderbox.mozilla.org to pick up the latest code from CVS. Duration 2
hours. See bug 446547 for more details.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 453325. Feel
free to comment directly in that bug (or http://blog.mozilla.com/it/) if
* 7:00pm PDT (0200 UTC) addons.mozilla.org DNS change. As part of our
CDN trial/test, we’ll be offloading addons.mozilla.org to CDNetworks and
pushing a DNS change to make that active. See bug 450745 for details. No
downtime is expected.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
Feel free to comment directly if you see issues past the planned downtime.
* 7:00pm PDT (0200 UTC) duration 4 hours: Red Hat 5 upgrades. We’ll be
picking up OS upgrades on several machines tonight. The following
services/hosts will be affected:
o cvs-mirror.nl.mozilla.com
o doctor.mozilla.org
o despot.mozilla.org
* 7:00pm PDT (0200 UTC) addons.mozilla.org DNS change. As part of our
CDN trial/test, we’ll be offloading addons.mozilla.org to CDNetworks and
pushing a DNS change to make that active. See bug 450745 for details. No
downtime is expected.
Please let me know if you have any reason why we should not proceed with
We will have a scheduled maintenance window tonight from 7pm to 11:00pm
PDT. This is being tracked in master bug 455530. The following changes
will take place:
* 7:00pm PDT (0200 UTC) support.mozilla.com updates. We’ll be updating
support.mozilla.com to pick up code updates. No downtime is expected.
* 7:00pm PDT (0200 UTC) addons.mozilla.org database work.
addons.mozilla.org will be offline to move the master database to a new
MySQL 5 cluster. Duration 15 minutes.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 455530. Feel
free to comment directly in that bug (or this blog) if you see issues
past the planned downtime.
* 7:00pm PDT (0200 UTC) addons.mozilla.org updates. We’ll be updating
addons.mozilla.org to pick up code updates. No downtime is expected.
* 7:00pm PDT (0200 UTC) MDC / developer.mozilla.org updates. We’ll be
updating developer.mozilla.org to pick up code updates. No downtime is
expected.
* 7:00pm PDT (0200 UTC) Labs Forum upgrade. The Labs Forum software will
be switched to Vanilla. Duration 2 hours.
* 7:00pm PDT (0200 UTC) blog/wiki database restart. We need to restart
MySQL on one of our database masters to change some configuration
settings. This will affect all of the sites listed below. Duration 5
minutes.
o www.spreadfirefox.com
o All Blogs
o All Wikis
o All Intranet Sites
o All Forums
o support.mozilla.org
o reporter.mozilla.org
o pastebin.mozilla.org
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 455896. Feel
* 7:00pm PDT (0200 UTC) support.mozilla.com updates. We’ll be updating
support.mozilla.com to pick up code updates. No downtime is expected.
* 7:00pm PDT (0200 UTC) spreadfirefox.com updates. We’ll be updating
spreadfirefox.com to pick up code updates. No downtime is expected.
* 7:00pm PDT (0200 UTC) Wiki upgrades. We’ll be upgrading all Intranet
wikis hosted by Mozilla. This will affect anything under
intranet.mozilla.org. Duration 3 hours.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 456442. Feel
* 7:00pm PDT (0200 UTC) addons.mozilla.org/*.addons.mozilla.org database
restart and code updates. We’ll be updating addons.mozilla.org to pick
up code updates. We’ll also be restarting the master database to change
some configuration settings. See bug 458110 for more details. This will
impact addons.mozilla.org and all related sub-domains. Duration 15 minutes.
* 7:00pm PDT (0200 UTC) Final MySQL 5 migration. We will be completing
our last MySQL 4 master to MySQL 5. The following services will go
offline for up to 30 minutes while they are moved to a new master database:
o Bonsai
o Despot
o Graph Server
o Litmus
* 9:00pm PDT (0200 UTC) San Jose Netscaler software upgrade. We’ll be
doing a vendor recommended upgrade on the San Jose Netscalers. No
downtime expected.
* 10:00pm PDT (0200 UTC) Cisco IOS upgrade. We’ll be upgrading IOS on
two of the embedded HP BladeSystem Cisco switches to pick up a bug fix
(BugID CSCsf17036). The systems attached to these switches are
multi-homed. No downtime expected.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 458901. Feel
* 7:00pm PDT (0200 UTC) Thirdlane PBX upgrades. We will be upgrading the
configuration GUI and its underlying Asterisk add-on features for our
phone system. The phone system itself in Mountain View will probably be
down less than 5 minutes. Specific features (conference call rooms,
provisioning of new telephones, calls to phones in Toronto) may be
offline for up to 6 hours. Duration 6 hours
* 7:00pm PDT (0200 UTC) Mailman / mailing list upgrades. We’ll be
upgrading Mailman to 2.1.11 and upgrading the host OS to RHEL5. This
will affect all mailing lists and all email services under
lists.mozilla.org, mail.mozilla.org, mozilla.org and bugzilla.org.
Duration 3 hours.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 459262. Feel
--------------------------------------------------
From: "matthew zeier" <m...@mozilla.com>
Sent: Friday, October 10, 2008 5:11 AM
To: "matthew zeier" <m...@mozilla.com>
Cc: <dev-pl...@lists.mozilla.org>; <dev-moz...@lists.mozilla.org>;
<gen...@lists.mozilla.org>
Subject: Mozilla Scheduled Downtime - 10/09/2008, 7pm - 11pm PDT (0200 -
060010/10/2008 UTC)
> _______________________________________________
> general mailing list
> gen...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/general
>
And the reason this was posted/re-posted is.............????
Daniel
two words: Supoch Seanganant
--
*IMPORTANT*: Sorry folks, but I cannot provide email
help!!!! Emails to me may become public
Notice: This posting is protected under the Free Speech
Laws, which applies everywhere in the FREE world,
except for some strange reason, not to the mozilla.org
newsgroup servers, where your posting may get you banned.
Peter Potamus & His Magic Flying Balloon:
http://melaman2.com/cartoons/singles/mp3/p-potamus.mp3
http://www.toonopedia.com/potamus.htm
Far be it for lowly old me to disagree with you Peter, but this has none
of what I would consider Supoch Seanganant's usual traits.
Daniel
sure it does. It contains a posting that has no reply,
and it came from the lists. Therefore, he's going
under a different name.
> Daniel wrote:
>> Peter Potamus the Purple Hippo wrote:
>>> Daniel wrote:
>>>> guza...@hotmail.com wrote:
>>>>> --------------------------------------------------
[ ... ]
>>>> And the reason this was posted/re-posted is.............????
>>> two words: Supoch Seanganant
>> Far be it for lowly old me to disagree with you Peter, but this has
>> none of what I would consider Supoch Seanganant's usual traits.
> sure it does. It contains a posting that has no reply, and it came
> from the lists. Therefore, he's going under a different name.
Actually, it's the same e-mail address, he's just removed the
display name.
Ken Whiton
FIDO: 1:132/152
InterNet: kenw...@surfglobal.net.INVAL (remove the obvious to reply)
When I usually view Supochs posts, the formating is all stuffed up, but,
in this case, it/he has maintained the formating!
Maybe "He" is learning something.
Daniel
> Ken Whiton wrote:
>> *-* Peter Potamus the Purple Hippo wrote
>>> Daniel wrote:
>>>> Peter Potamus the Purple Hippo wrote:
>>>>> Daniel wrote:
>>>>>> guza...@hotmail.com wrote:
>>>>>>> --------------------------------------------------
>> [ ... ]
>>>>>> And the reason this was posted/re-posted is.............????
>>>>> two words: Supoch Seanganant
>>>> Far be it for lowly old me to disagree with you Peter, but this
>>>> has none of what I would consider Supoch Seanganant's usual
>>>> traits.
>>> sure it does. It contains a posting that has no reply, and it
>>> came from the lists. Therefore, he's going under a different
>>> name.
>> Actually, it's the same e-mail address, he's just removed the
>> display name.
> When I usually view Supochs posts, the formating is all stuffed up,
> but, in this case, it/he has maintained the formating!
Not only that, but his/her/its most recent posts no longer
include the "get live" SPAM sig.
* 7:00pm PDT (0200 UTC) support.mozilla.com updates. We’ll be updating
support.mozilla.com to pick up code updates. No downtime is expected.
* 7:00pm PDT (0200 UTC) Mailman / mailing list upgrades. We’ll be
upgrading Mailman to 2.1.11 and upgrading the host OS to RHEL5. This
will affect all mailing lists and all email services under
mail.mozilla.org, mozilla.org and bugzilla.org. Duration 3 hours.
* 7:30pm PDT (0230 UTC) mail.mozilla.com / Zimbra Upgrade. We’ll be
upgrading Zimbra to 5.0.10. Duration 3-4 hours.
* 8:00pm PDT (0300 UTC) ) MDC / developer.mozilla.org updates. We’ll be
moving developer.mozilla.org completely behind SSL. No downtime is expected.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 460825. Feel
* 8:00pm PDT (0300 UTC) ) MDC / developer.mozilla.org updates. We’ll be
updating developer.mozilla.org to pick up code updates. No downtime is
expected.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 460826. Feel
We will have an emergency maintenance window tonight from 6pm to 11:00pm
PST.
The following work will take place:
* 6:00pm PST (0200 UTC) ) EqualLogic storage array firmware upgrade.
See bug 464458 for details. We’ll be locking the tree to all check-ins
at 5:00 PST tonight to start the maintenance window and will unlock it
once the machines have come back up and gone green for a cycle.
Last night one of our network attached storage devices experienced an
error and didn’t fail over properly. The effect was such that we had to
close the tree as Tinderbox wasn’t getting proper data for updates, and
we couldn’t tell what was happening with our builds. While we were able
to restore that functionality, there is a high chance that any of our
VMs attached to this storage device may experience further problems.
To fix this, we’ll need to pause all of our VM systems (most notably
build machines & unit test machines, but also litmus and some others)
for a few hours. The affected systems would be:
fxdbug-win32-tbox
fx-win32-1.9-slave2
moz2-linux-slave1
patrocles
fx-linux-1.9-slave09
try-master
try-unit-linux-01
xr-linux-tbox
egg
fxdbug-linux-tbox
fx-linux-1.9-slave2
moz2-linux64-slave01
l10n-linux-tbox
prometheus-vm
tb-linux-tbox
try1-win32-slave
try-unit-linux-02
bm-l10n-win2k3-01
dm-bugs-test-app01
dm-graphs-stage01
dm-litmus02
dm-mailman01
fx-win32-1.9-slave08
fx-win32-1.9-slave09
moz2-linux-slave04
moz2-win32-slave04
pm-app01
sand
sm-summit01
moz2-linux-slave09
moz2-linux-slave10
moz2-linux-slave11
moz2-linux-slave12
moz2-win32-slave09
moz2-win32-slave10
moz2-win32-slave11
moz2-win32-slave12
moz2-win32-slave13
test-linslave
test-mgmt
moz2-linux-experimental1
moz2-linux-slave01
moz2-linux-slave13
moz2-linux-slave14
moz2-linux-slave15
moz2-linux-slave16
moz2-win32-slave14
moz2-win32-slave15
moz2-win32-slave16
moz2-win32-slave17
moz2-win32-slave18
try-unit-win32-01
test-winslave
try-linux-slave03
try-win32-slave03
bm-buildgraph01
bm-symbolfetch01
dm-ausstage01
dm-chat01
geodns01.sj
dm-graphs01
dm-webtools01
im-bes01
mrapp-intranet01
mrapp-stage01
pm-ns03
production-1.9-master
qm-evtest01
tm-amo01-webdev01
After discussing this with the sheriff, product leads and release
engineering team, we’ve decided it would be best to do this as soon as
possible. We’ll be locking the tree to all checkins at 5:00pm PST
tonight to start the maintenance window, and we’ll unlock it once the
machines have come back up and gone green for a cycle. Vlad will try to
shepherd the remaining patches for beta 2 blockers that are in the
checkin queue before 5pm, but at that time we’ll stop all work and pick
it up tomorrow morning.
Let us know if there are any objections as soon as possible.
--
matthew zeier | Mgr. IT Operations | Mozilla Corp. | (650)903-0800 x219
* 7:00pm PST (0300 UTC) support.mozilla.com updates. We’ll be updating
support.mozilla.com to pick up code updates. No downtime is expected.
* 7:00pm PST (0300 UTC) Root-level DNS changes. We will be updating
root-level DNS for mozilla.org, mozilla.com, and spreadfirefox.com to
Mozilla-operated nameservers. No downtime is expected.
* 7:00pm PST (0300 UTC) mozilla.com MX change. We’ll be updating
mozilla.com MX records as per bug 464745. No downtime is expected.
* 7:00pm PST (0300 UTC) Netscaler OS upgrade. We’ll be upgrading the
Netscaler load balancers in San Jose, Amsterdam and Beijing to pick up
code fixes. No downtime is expected.
* 10:00pm PST (0600 UTC) Cisco FWSM OS upgrade. We’ll be updating the
Cisco firewalls to resolve bug CSCsd67334. The two FWSMs run as an HA
pair and this upgrade should be hitless. No downtime is expected.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 464743. Feel
We will have a scheduled maintenance window tonight from 7:00pm to
11:00pm PST. This is being tracked in master bug 465599. The following
changes will take place:
* 6:00pm PST (0200 UTC) bugzilla.mozilla.org updates. We’ll be updating
bugzilla.mozilla.org to pick up code updates. See bug 464713 for more
details. Duration 5 minutes.
* 7:00pm PST (0300 UTC) support.mozilla.com updates. We’ll be updating
support.mozilla.com to pick up code updates. No downtime is expected.
* 10:00pm PST (0600 UTC) border2 Sup720-3BXL upgrade. See
http://blog.mozilla.com/mrz/ for more details. During this time all all
BGP sessions on border2 will be shutdown and traffic will continue to
route through border1. No user-facing downtime is expected.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 465599. Feel
* 10:00pm PST (0600 UTC) border1 Sup720-3BXL upgrade. See
http://blog.mozilla.com/mrz/ for more details (this is the second half
of Tuesday’s upgrade). During this time all all BGP sessions on border1
will be shutdown and traffic will continue to route through border2. No
user-facing downtime is expected.
Please let me know if you have any reason why we should not proceed with
this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be operational
by the end of the maintenance window.
Feel free to comment directly in that bug (or this blog) if you see
* 9:00pm PST (0500 UTC) addons.mozilla.org/Zeus ZXTM performance
testing. We will be running a performance test of addons.mozilla.org
behind a Zeus ZXTM cluster. See bug 467502 for more information. No
downtime is expected, however the test period is expected to run for
eighteen (18) hours.
* 7:00pm PST (0300 UTC) addons.mozilla.org updates. We’ll be updating
addons.mozilla.org to pick up code updates. See bug 469210 for more
details. No downtime expected.
* 7:00pm PST (0300 UTC) Bouncer/download.mozilla.org database upgrade.
We’ll be upgrading the hardware the Bouncer/download.mozilla.org
database runs on. See bug 464748 for more details. No downtime expected.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly in those bug (or this blog) if you see
I thought 12:00pm was noon, not midnight.
--
Irwin
Please do not use my email address to make requests for help.
Knowledge Base: http://kb.mozillazine.org/Main_Page
11:59 pm is most diffinently night, so, I guess, a little bit more would
still be night.
--
Daniel
(using his sister's computer)
(Test driving SM 2.x)
> Irwin Greenwald wrote:
> >
> > On 12/11/2008 matthew zeier said
> >> We will have a scheduled maintenance window tonight from 6:00pm to
> >> 12:00pm PST. The following changes will take place:
> >
> > I thought 12:00pm was noon, not midnight.
>
> 11:59 pm is most diffinently night, so, I guess, a little bit more
> would still be night.
Alternatively, 12:01 pm is definitely day, so a little earlier should
still be day, right?
"am" and "pm" just shouldn't be used with 12:00. They stand for "ante
meridiem" and "post meridiem", which mean "before noon" and "after
noon". So, saying "am" or "pm" when referring to noon itself
makes no sense. Saying "12 am" means "12 o'clock before noon",
which must be midnight. Saying "12 pm" means "12 o'clock after
noon", which must also be midnight. But they are different midnights.
"12 am Tuesday" would be the midnight between Monday and Tuesday,
whereas "12 pm Tuesday" would be the midnight between Tuesday and
Wednesday.
The solution to that mess is just to say "12 noon" and "12 midnight" if
you're using a twelve-hour clock. You can omit the "12" if you like. ;)
Most (all?) twelve-hour digital clocks display noon as 12:00 pm and
midnight as 12:00 am, but that doesn't make it right. And hopefully
computers aren't using twelve-hour clocks at all.
--
»Q«
Kleeneness is next to Gödelness.
11:59 PM is one minute before midnight. 12:01 PM is one minute after
noon. IIUC (but English is not my mother language), 12:00 AM and 12:00
PM are ambiguous, and "12:00 noon" or "12:00 midnight" should be used
instead.
Or else, use 24-hour clock, where midnight is 00:00, noon is 12:00, and
the clock time can go from 00:00:00 to 23:59:59 normally, or to 24:00:00
when there is a leap second to keep atomic time in synch with average
sundial time.
Best regards,
Tony.
--
Finagle's First Law:
If an experiment works, something has gone wrong.
By the time you say it, it's correct. Even if it's 12:00:01 PM it's
STILL PM. Your explanation is only good for the exact moment 12:00 occurs.
--
Terry R.
Anti-spam measures are included in my email address.
Delete NOSPAM from the email address after clicking Reply.
are you sure about that? I always thought it was
written as 1200 or 2359:59
--- Original Message ---
> Tony Mechelynck wrote:
>> On 12/12/08 07:58, Daniel wrote:
>>> Irwin Greenwald wrote:
>>>>
>>>> On 12/11/2008 matthew zeier said
>>>>> We will have a scheduled maintenance window tonight from 6:00pm to
>>>>> 12:00pm PST. The following changes will take place:
>>>>
>>>> I thought 12:00pm was noon, not midnight.
>>>>
>>>>
>>>
>>> 11:59 pm is most diffinently night, so, I guess, a little bit more would
>>> still be night.
>>>
>>
>> 11:59 PM is one minute before midnight. 12:01 PM is one minute after
>> noon. IIUC (but English is not my mother language), 12:00 AM and 12:00
>> PM are ambiguous, and "12:00 noon" or "12:00 midnight" should be used
>> instead.
>>
>> Or else, use 24-hour clock, where midnight is 00:00, noon is 12:00, and
>> the clock time can go from 00:00:00 to 23:59:59 normally, or to 24:00:00
>> when there is a leap second to keep atomic time in synch with average
>> sundial time.
>
> are you sure about that? I always thought it was
> written as 1200 or 2359:59
>
24hr clock:
1200 is noon
2400 is midnight
--
Jay Garcia - Netscape / Flock Champion
Netscape - Firefox - Flock - Thunderbird Support
UFAQ - http://www.UFAQ.org
Certainly not 2359:59. About the other, I would regard "twelve hundred
hours" as Army slang from a time and place where 12:00 was commonly
abbreviated to 1200.
My current screen clock displays (at the instant I type it) 20:26:44 and
that's the kind of clock display with which I'm familiar (for digital
clocks). My (digital) wristwatch says (about a minute later) 20:27⁴⁶
(you'll need a Unicode-capable mailer to see it properly).
Best regards,
Tony.
--
It's a very *UN*lucky week in which to be took dead.
-- Churchy La Femme
The latter is not for time but for angles, where 1 turn = 360°. I've
been told both sexagesimal number systems derive from the astronomers
(and bookkeepers) of the Tigris-Euphrates region maybe five thousand
years ago or more. They used cuneiform writing and had a base-six-ten
number system (positional without zero), used for astrology, for land
measuring, for collecting taxes, etc. The advantage is that 60 has an
almost incredibly high number of integer divisors: 2, 3, 4, 5, 6, 10,
12, 15, 20, 30 (and of course 1 and 60).
Best regards,
Tony.
--
All science is either physics or stamp collecting.
-- E. Rutherford
So when someone says they'll be around at 12 pm, all you have to do is
adk whether they mean the exact moment or one second later. ;)
--
Ron Hunter rphu...@charter.net
<snip>
>>>
>>
>> 24hr clock:
>>
>> 1200 is noon
>> 2400 is midnight
>>
> Seems I recall military time (24 hour) starting at 0000.
> My computer clock says it is 18:34:23.
>
>
When I was in the Aust Army, we were told that the time between 2359hrs
and 0001 hrs was our own to do with as we pleased, as the manual didn't
know how to refer to 2400/0000 hrs!
>
> On 12/11/2008 9:05 PM, Irwin Greenwald wrote:
> >
> > On 12/11/2008 matthew zeier said
> >> We will have a scheduled maintenance window tonight from 6:00pm to
> >> 12:00pm PST. The following changes will take place:
> >
> > I thought 12:00pm was noon, not midnight.
>
> /*Now*/ look at what you've stirred up /*Dumb Head*/*// :-( *
Wasn't this group created specifically for the discussion of traffic and
time/timezone issues? ;)
Of course not, it was created to deal with freezer issues. Please try
to keep up.
--
Cheers, Bev
==============================
All bleeding eventually stops.
--
------------------------------------------------------------------------
Phillip M. Jones, CET |MEMBER:VPEA (LIFE) ETA-I, NESDA,ISCET, Sterling
616 Liberty Street |Who's Who. PHONE:276-632-5045, FAX:276-632-0868
Martinsville Va 24112 |pjo...@kimbanet.com, ICQ11269732, AIM pjonescet
------------------------------------------------------------------------
If it's "fixed", don't "break it"!
mailto:pjo...@kimbanet.com
<http://www.kimbanet.com/~pjones/default.htm>
<http://www.kimbanet.com/~pjones/90th_Birthday/index.htm>
<http://www.kimbanet.com/~pjones/Fulcher/default.html>
<http://www.kimbanet.com/~pjones/Harris/default.htm>
<http://www.kimbanet.com/~pjones/Jones/default.htm>
12 in middle of day is noon its neither am or PM.
12 in middle of night is Midnight neither am or pm
11:59 AM, 12:00 N, 12:01 pm
11:59 PM, 12:00 M, 12:01 am
How about 12 in the middle of the day is 12 m, i.e. it IS the meridiem!!
> 12 in middle of night is Midnight neither am or pm
How about 12 in the middle of the night is EITHER 12 a.m. OR 12 p.m. as
it is 12 hours before (anti) OR 12 hours after (post) meridiem!!
>
> 11:59 AM, 12:00 N, 12:01 pm
> 11:59 PM, 12:00 M, 12:01 am
>
--
12 PM is 12 noon
12 AM is 12 midnight
but to avoid this confusion, it was decided that we use
12 midnight and 12 noon instead of 12 AM and 12 PM
http://www.answers.com/topic/ante-meridiem
Don't know who "we" is but that is not what the article you referenced indicates
it clearly states that noon can not be 12 AM and can not be 12 PM
-- specifically at http://www.answers.com/ante%20meridiem#Confusion_at_noon_and_midnight
Was looking for when "military time" started and found -- http://en.wikipedia.org/wiki/24-hour_clock
The British and Canadian militaries first started to use the 24-hour clock in late 1917. [4] Previous to this, military orders were
drafted using the familiar "a.m." and "p.m." suffixes.
--- Original Message ---
Starts at 0000 and ends at 2400 .. really!!
--
Jay Garcia - Netscape/Flock Champion
www.ufaq.org
Netscape - Flock - Firefox - Thunderbird - Seamonkey Support
Think like a number Jay. If you start at 0000 then there cannot be a
2400 in a 24 hour cycle. 2400 is the start of the 25 hour.
Dennis
It's not like counting apples, where there could be one apple more or
one apple less. It's a continuum. The start of the 25th hour (or the
start of the 1st hour of the new day) is the same as the end of the
24th.
The same kind of thing, two representations of the same number, happens
in the decimal system for real numbers (or rational ones, if you
like). E.g., the number 1 is exactly the same as the number
0.99999999999999999999999999..., where the nines repeat forever.
(Irwin, are you happy now? ;)
*Absolutely*. I think this thread belongs on the top of the "Stupid
threads" list! And to think..I started it! Sheeeeesh.
You shouldn't feel shame -- you've provided a public service, proving
that some people have wayyyyy too much time on their hands and that I'm
not the only one who needs to get a life.
Oh wait, I already had one; this is better.
One approach to a continuum might be that there is no past and there
is no future, there is only the now. Then 0000 covers everything.
Since we're talking time...
On December 31, 2008 when we add a leap second will our computers show
23:59:60 UTC before rolling over to 00:00:00?
2008 December 31, 23h 59m 59s
2008 December 31, 23h 59m 60s
2009 January 1, 0h 0m 0s
Hmm. Wouldn't you know, Dave Mills has it figured out:
http://doc.ntp.org/4.1.0/leap.htm
--
-Rinaldi-
A child of five could understand this! Fetch me a child of five.
> »Q« wrote:
> > In <news:lvydnZi3JqrkDtnU...@mozilla.org>,
> > Dennis <junk...@beyondlimit.org> wrote:
> >
> >> Jay Garcia wrote:
> >>> On 12.12.2008 18:34, Ron Hunter wrote:
> >>>
> >>> Starts at 0000 and ends at 2400 .. really!!
> >> Think like a number Jay. If you start at 0000 then there cannot be
> >> a 2400 in a 24 hour cycle. 2400 is the start of the 25 hour.
> >
> > It's not like counting apples, where there could be one apple more
> > or one apple less. It's a continuum. The start of the 25th hour
> > (or the start of the 1st hour of the new day) is the same as the
> > end of the 24th.
>
> One approach to a continuum might be that there is no past and there
> is no future, there is only the now. Then 0000 covers everything.
Or -0000, just as well.
> > The same kind of thing, two representations of the same number,
> > happens in the decimal system for real numbers (or rational ones,
> > if you like). E.g., the number 1 is exactly the same as the number
> > 0.99999999999999999999999999..., where the nines repeat forever.
> >
> > (Irwin, are you happy now? ;)
> >
--
»Q« /"\
ASCII Ribbon Campaign \ /
against html e-mail X
<http://asciiribbon.org/> / \
--
Ron Hunter rphu...@charter.net
Since most people are probably up to the New Year
that would be one second LESS sleep (wake time vs. sleep time)
--- Original Message ---
In the military you don't think in "numbers" when it comes to time.
Remember the old argument as to when time started and why we're in the
year 2008 but in the 21st century?? :-D
If your drill sergeant says "up and at 'em at 0000" (zero hundred
hours), you gonna challenge it and stay in the rack? 8-)
0000 is a valid time in the Navy for sure.
--- Original Message ---
"Q" should know all about the "Continuum" 'eh? :-D
I whole heartedly agree 0000 is a valid time. 2400 would be invalid in
a 24 hour scheme. I wouldn't challenge a drill sergeant even if he
said 2400, aren't most of them morons anyway?
Zero is my favorite number. It doesn't mean much by itself and you can
put a whole bunch of them together and they still don't add up to
squat. But if you put any positive number in front of them they can
really make that number look like something.
Dennis
--
Ron Hunter rphu...@charter.net
Some people around me welcome in the New Year with their old fireworks
that they may have misplaced or failed to finish up on July 4th, so sleeping
through doesn't work around here, though might catch that extra second
as sleep before the fireworks, don't know how good their timing is.
The main reason to stay up was it was easier to synch wrist watch then.
But with nice computer clock synchronization and Atomic (Radio)
clocks make getting right time to set watch anytime very easy.
--- Original Message ---
According to Naval traditions, 0000 is a starting time and 2400 is an
ending time. The party starts at 0500 and ends at 2400 hrs. Think of it
like a glass half full or half empty, depends on the direction you're
going. :-D
* 7:00pm PST (0300 UTC) mozilla.org MX change. We’ll be updating
mozilla.org MX records. No downtime is expected.
* 7:00pm PST (0300 UTC) duration 4 hours: Kernel upgrades. We’ll be
doing kernel security updates on various machines affecting the
following services for approximately 10 minutes each:
- build graphs / pageload tests
- CVS, cvs-mirror, SVN, Hg
- LXR/MXR
- Despot, Doctor
- ftp.mozilla.org
- quality.mozilla.org
- videos.mozilla.org
- stage.mozilla.org
- people.mozilla.com
- Buildbot Try Server
- MDC Search
- internet-facing mail relays, list servers, and outbound mail (mail
will be queued)
- Any sites using LDAP for authentication
- DNS/DHCP/wifi/telephone services in all Mozilla offices (except
Beijing)
- support.mozilla.com chat server
- irc.mozilla.org
- All database-backed websites and services, including but not
limited to: Bugzilla, Breakpad, Bonsai, SUMO, SpreadFirefox, Addons,
bouncer/download, Blogs, QMO, Litmus
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly in this blog if you see issues past the
planned downtime.
* 8:00pm PST (0500 UTC) Cisco IOS upgrades. We’ll be upgrading IOS on
the two core switches to pickup feature enhancements. See bug 473084
for more details. The systems attached to these switches are multi-
homed. No user-facing downtime is expected.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly in the bug if you see issues past the
planned downtime.
* 7:00pm PST (0300 UTC) labs.mozilla.com updates. We’ll be updating
labs.mozilla.com to pick up code updates (bug 469210). No downtime
expected.
* 7:30pm PDT (0300 UTC) ) MDC / developer.mozilla.org updates. We’ll
be updating developer.mozilla.org to pick up code updates (bug
471945). No downtime is expected.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly in those bugs if you see issues past the
planned downtime.
* 7:00pm PST (0300 UTC) labs.mozilla.com blog updates. We’ll be
updating labs.mozilla.com’s blog to pick up code updates. No downtime
is expected.
* 7:00pm PST (0300 UTC) developer.mozilla.org / MDC &
library.mozilla.org database maintenance. Both developer.mozilla.org
and library.mozilla.org will be offline to re-sync database slaves
(bug 475477). Duration 30 minutes..
* 7:00pm PST (0300 UTC) versioncheck.addons.mozilla.org &
fxfeeds.mozilla.com load balancer change. We’ll be moving both
versioncheck.addons.mozilla.org & fxfeeds.mozilla.com behind the
production Cisco ACE/Zeus ZXTM cluster. For background, see this blog
post[1]. No downtime is expected.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
As mentioned, this maintenance window is tracked in bug 475602. Feel
free to comment directly in that bug if you see issues past the
planned downtime.
* 7:00pm PDT (0300 UTC) crash-stats.mozilla.com (Socorro) database
maintenance. We’ll be partitioning the production Socorro database
(refer to bug 475815 for details). During this time, crash-
stats.mozilla.com will be offline. crash-reports.mozilla.com will be
up and accept crashes. They will be queued and processed later.
Downtime is expected to last into Saturday but total time is unknown
and could run throughout the weekend.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly in those bugs if you see issues past the
planned downtime.
* 7:00pm PDT (0200 UTC): EqualLogic firmware upgrade. We will be
upgrading the firmware on the EqualLogic storage arrays. We’ve made
every effort to minimize user-facing downtime by shifting SAN volumes
around, however, we are planning for the following systems/services to
be offline for approximately four hours.
o Build & Release Infrastructure will be degraded.
Please refer to John’s post[1] for more information regarding checkins.
o crash-stats.mozilla.com (we’ll still collect reports,
however, reporting and processing will be affected.)
o support.mozilla.com chat services
o mail.mozilla.org (mailman mailing lists)
o air.mozilla.com
o www.mozilla.com search
o im-bes01 / Blackberry Enterprise Server
o litmus.mozilla.org
o graphs stage and stage2 (bm-buildgraph01)
o aus stage - dm-ausstage01
o build-graphs.mozilla.org
o icecast.mozilla.org
o videos.mozilla.org
* 7:00pm PDT (0200 UTC): Cisco FWSM OS upgrade. We’ll be updating the
Cisco firewalls. The two FWSMs run as an HA pair. No downtime is
expected.
* 7:00pm PDT (0200 UTC) support.mozilla.com / SUMO updates. We’ll be
updating support.mozilla.com to pick up code updates (bug 492030). No
downtime expected.
* 7:00pm PDT (0200 UTC) services.addons.mozilla.org / SAMO updates.
We’ll be updating services.addons.mozilla.org to pick up code updates
(bug 492389). No downtime expected.
* 7:00pm PDT (0200 UTC): C01 Database Cluster kernel upgrades. We’ll
be doing kernel security updates on the C01 database cluster. The
following database-driven services will be affected for about 10
minutes:
o blog.lizardwrangler.com
o blog.mozilla.com
o blog.mozillafoundation.org
o communitystore.mozilla.org
o contribute.mozilla.org
o firefoxflicks.com
o getfirebug.com
o impact.mozilla.com
o kubla.mozilla.org
o labs.mozilla.com blogs and forums
o livetitles.com
o mozilla-europe.org
o mozillaparty.com
o pastebin.mozilla.org
o priorartshare.com
o quality.mozilla.org
o reporter.mozilla.org
o spreadfirefox.com
o survey.mozilla.com
o survey.mozilla-europe.org
o developer.mozilla.org
o wiki.mozilla.org
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly in those bugs if you see issues past the
planned downtime.
* 6:00pm PDT (0100 UTC): crash-stats.mozilla.com database migration.
We’ll be migrating the current production breakpad database to new
hardware. Crash reports will still be collected but processing and
reporting will be offline. Duration 5 hours.
* 7:00pm PDT (0200 UTC): Cisco FWSM OS upgrade. We’ll be updating the
standby Cisco firewall. No downtime is expected.
* 7:00pm PDT (0200 UTC) support.mozilla.com / SUMO updates. We’ll be
updating support.mozilla.com to pick up code updates (bug 492030). No
downtime expected.
* 7:30pm PST (0330 UTC) Kernel upgrades. We’ll be doing kernel
security updates on various machines affecting the following services
for approximately 10 minutes each:
o mradm01.mozilla.org
o gravel.mozilla.org
o build graphs / pageload tests
o CVS, cvs-mirror, SVN, Hg
o LXR/MXR
o Despot, Doctor
o ftp.mozilla.org
o quality.mozilla.org
o videos.mozilla.org
o stage.mozilla.org
o people.mozilla.com
o MDC Search
o Internet-facing mail relays, list servers, and
outbound mail (mail will be queued)
o Any sites using LDAP for authentication
o DNS/DHCP/wifi/telephone services in all Mozilla
offices (except Beijing)
o support.mozilla.com chat server
o irc.mozilla.org
o All database-backed websites and services, including
but not
limited to: Bugzilla, Breakpad, Bonsai, SUMO,
SpreadFirefox, Addons, bouncer/download, Blogs, QMO, Litmus
Please let me know if you have any reason why we should not proceed
* 7:00pm PDT (0200 UTC) support.mozilla.com update. We’ll be updating
support.mozilla.com to pick up code updates (bug 499964). Duration 4
hours.
* 7:00pm PDT (0200 UTC) graphs.mozilla.org update. We’ll be updating
graphs.mozilla.org to pick up code updates (bugs 501432 and 498802).
Duration 4 hours.
* 8:00pm PDT (0300 UTC) DHCP infrastructure changes. We’ll be
implementing an active/standby DHCP server setup which requires some
reconfiguration on the current DHCP server. No downtime expected.
* 10:00pm PDT (0500) UTC hg repo maintenance. We’ll be resetting the
hg repo (bug 500246). Duration 30 minutes.
* 6:00pm PDT (0100 UTC) crash-stats.mozilla.com database maintenance.
We’ll be switching crash-stats.mozilla.com to use pgbouncer instead of
accessing the postgres db directly. This will impact the crash-
stats.mozilla.com website and the ability to process priority reports.
Duration 15 minutes.
* 8:00pm PDT (0300 UTC) Bugzilla upgrade and network changes. We’ll
be making some changes to our internal network that will affect the
Bugzilla application servers. We’ll also use this time to upgrade to
version 3.2.4. Downtime shouldn’t be more than 15 minutes expected,
however we’re planning for an hour.
* 11:00pm PDT (0600 UTC) svn/hg maintenance. We’ll be updating server
software. Both svn.mozilla.org and hg.mozilla.org will be impacted.
Duration 15 minutes.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly if you see issues past the planned
downtime.
* 6:00pm PDT (0200 UTC) blog.mozilla.com upgrade. We’ll be picking up
a Wordpress MU update. Duration 5 minutes.
* 6:00pm PDT (0200 UTC) support.mozilla.com update. We’ll be updating
support.mozilla.com to pick up code updates (bug 504148). No downtime
expected.
* 7:00pm PDT (0200 UTC) Labs VMware update. We will be upgrading the
Labs VMware ESX cluster. This will affect most labs projects,
including Bespin, Jetpack, Ubiquity and Prism. Weave and Personas
should not be affected. Duration 2 hours.
* 9:00pm PDT (0400 UTC) aus2.mozilla.org/download.mozilla.org
maintenance. We’ll be making some changes to our internal network that
could affect the servers that run aus2.mozilla.org &
download.mozilla.org. Downtime shouldn’t be more than 15 minutes
expected, however we’re planning for an hour .
* 6:00pm PST (0100 UTC) Kernel upgrades. We’ll be doing kernel
security updates on various machines affecting the following services
for approximately 10 minutes each:
* sand.mozilla.org (part of irc.mozilla.org)
* All RHEL-based development machines (hostnames beginning with sm-
* or cm-*)
* build graphs / pageload tests
* CVS, cvs-mirror, SVN, Hg
* LXR/MXR
* Despot, Doctor
* ftp.mozilla.org
* quality.mozilla.org
* videos.mozilla.org
* stage.mozilla.org
* people.mozilla.com
* MDC Search
* Internet-facing mail relays, list servers, and outbound mail
(mail will be queued)
* Any sites using LDAP for authentication
* DNS/DHCP/wifi/telephone services in all Mozilla offices (except
Beijing)
* support.mozilla.com chat server
* All database-backed websites and services, including but
notlimited to: Bugzilla, Breakpad, Bonsai, SUMO, SpreadFirefox,
Addons, bouncer/download, Blogs, QMO, Litmus
* 8:00pm PDT (0300 UTC): LDAP server maintenance. We’ll be testing out
LDAP failover and redundancy setup. Resources that depend on LDAP
authentication may experience disruption during this time. Duration 1
hours.
* 9:00pm PDT (0400 UTC) addons.mozilla.org maintenance. We’ll be
making some changes to our internal network that could affect the
servers that run addons.mozilla.org. Downtime shouldn’t be more than
15 minutes expected, however we’re planning for an hour .
* 10:00pm PDT (0500 UTC): Bugzilla component renames. We’ll be
renaming three components in Bugzilla to complete leftover items that
got missed in the last component reorganization. See bug 461546 for
details (step 4 on the first attachment). Duration 10 minutes.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly in those bugs if you see issues past the
planned downtime.
* 7:00pm PDT (0200 UTC) The Amsterdam Reboot. We’ll be turning down
services in Amsterdam and pulling production traffic back to San Jose
in preparation for The Amsterdam Reboot next week. No user facing
downtime is expected.
* 8:00pm PDT (0300 UTC) Layer42 BGP turnup. We’ll be turning up BGP
peering with Layer42 and pushing production traffic through Layer42.
No downtime expected.
* 9:00pm PDT (0400 UTC) www.mozilla.org relaunch. We’ll be pushing out
a new version of www.mozilla.org. See bug 510267 for details.
Duration 30 minutes.
* 9:00pm PDT (0400 UTC) PHP upgrade. We be upgrading PHP on
addons.mozilla.org. See bug 506703 for details. No downtime expected.
* 9:00pm PDT (0400 UTC) addons.mozilla.org EV SSL certificate
deployment. We’ll be replacing the wild card certificate with a
VeriSign EV SSL certificate tonight. No downtime expected.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly if you see issues past the planned
downtime.
* 8:00pm PDT (0300 UTC) crash-stats.mozilla.com content push. We’ll be
picking up code updates (bug 515739). During this time, crash-
stats.mozilla.com should be up but some aggregated reports may not be
available. crash-reports.mozilla.com will be up and accept crashes.
Duration two hours.
* 8:00pm PDT (0300 UTC) graphs.mozilla.org update. We’ll be updating
graphs.mozilla.org to pick up code updates (bug 515461). Duration one
hour.
* 9:00pm PDT (0300 UTC) The Amsterdam Reboot, Part II. We’ll be
rolling changes to push several production websites out of Amsterdam.
This involves changing DNS over to our Zeus GLB servers. No downtime
expected. The following sites will be moved tonight:
* addons.mozilla.org (bug 514994)
* developer.mozilla.org (bug 484807)
* 9:00pm PDT (0300 UTC) EdgeCast CDN trials. In our continuing effort
to bring content to closer to end users, we’ll be starting a trial
with EdgeCast. We’ll be flipping DNS for www.mozilla.com over to
EdgeCast. No downtime expected.
* 7:30pm PDT (0230 UTC): Cisco FWSM OS upgrade. We’ll be updating the
Cisco firewall module. No downtime is expected.
* 8:00pm PDT (0300 UTC) support.mozilla.com / SUMO updates. We’ll be
updating support.mozilla.com to pick up code updates (bug 520042). No
* 9:00pm PDT (0400 UTC) addons.mozilla.org update. We’ll be updating
addons.mozilla.org to pick up code updates (bug 523428). Duration 30
minutes.
* 9:00pm PDT (0400 UTC) We’ll be rolling changes to push several
production websites out of Amsterdam. This involves changing DNS over
to our Zeus GLB servers. No downtime expected.
The following sites will be moved tonight:
* www.spreadfirefox.com
* support.mozilla.com
* 5:00pm PDT (0000 UTC) addons.mozilla.org database hardware upgrade.
We’ll be adding additional RAM to the master database server for
addons.mozilla.org. (bug 522112). Duration 30 minutes (although the site
may stay down pending completion of the file moves, see below)
* 5:00pm PDT (0000 UTC) We'll be taking advantage of the database outage
to remap part of the back-end filesystem on addons.mozilla.org. (bug
517015). Duration 90 minutes.
* 7:00pm PDT (0200 UTC) We'll be making DNS changes to move the
support.mozilla.org domain to our Zeus GLB servers. (bug 522923) No
downtime expected.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to as
little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly if you see issues past the planned downtime.
--
Dave Miller http://www.justdave.net/
System Administrator, Mozilla Corporation http://www.mozilla.com/
Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/
* 7:00pm PDT (0200 UTC) We'll be deploying a software upgrade to the
support.mozilla.com application (upgrading to version 1.4.1). (bug
523264). Duration 30 minutes.
Dave Miller wrote on 10/22/09 7:15 PM:
* 7:00pm PDT (0200 UTC) labs.mozilla.com migration. We’ll be migrating
labs.mozilla.com to mozillalabs.com (bug 489638). Duration 60 minutes.
* 9:00pm PDT (0400 UTC) addons.mozilla.org backend server maintenance.
We’ll be making changes to the backend storage (bug 517015) and
database servers (bug 524011). Duration 90 minutes.
* 7:00pm PST (0300 UTC) support.mozilla.com update. We’ll be updating
support.mozilla.com to pick up code updates (bug 526284) . Duration 60
minutes.
* 7:00pm PST (0300 UTC) getpersonas.com update and database upgrade.
We’ll be updating getpersonas.com to pick up code updates (bug 526291)
and moving its database to a different database cluster (bug 521597).
Duration 10 minutes.
* 7:00pm PST (0300 UTC) smtp.mozilla.org configuration change. We’ll
be removing mozilla.com and mozilla.org from the authorized recipients
list on the inbound mail servers, since they are no longer used as the
MX for those domains (bug 524804) No downtime expected.
* 11:00pm PST (0700 UTC) www.mozilla-europe.org GLB DNS change. We’ll
be making DNS changes to move www.mozilla-europe.org to our Zeus GLB
servers (bug 523711). No downtime expected.
* 6:00pm PST (0200 UTC) crash-stats.mozilla.com database maintenance.
We’ll be working on the database and will impact the materialized
views on crash-stats.mozilla.com. All of the cron generated reports
will be down for the duration of this window. See bug 526624 for
details.Duration 7 hours.
Mozilla uses Cisco Firewall Service Modules in the core Cisco 6509
switches. At about 5:07am the primary unit failed and appears to have
crashed within the failover code. This caused an incomplete failover
and the standby FWSM never assumed full control.
At 5:19am PST the primary FWSM was manually reset which allowed the
standby to complete its failover.
We have grabbed crashinfo and are working with Cisco TAC to diagnose.
Specific details will be tracked in bug 528186.
We apologize for any inconvenience this may have caused and will
continue to work with Cisco on a remedy.
* 5:00pm PST (0100 UTC) addons.mozilla.org update. We’ll be updating
addons.mozilla.org to pick up code updates (bug 528272). Duration 30
minutes.
* 7:00pm PST (0300 UTC) getpersonas.com update. We’ll be updating
getpersonas.com to pick up code updates (bug 527792). Duration 10
minutes.
* 7:00pm PST (0300 UTC) crash-stats.mozilla.com database maintenance.
We’ll be working on the database and will impact the materialized
views on crash-stats.mozilla.com. All of the cron generated reports
will be down for the duration of this window. See bug 526624 for
details. Duration 7 hours.
* 9:00pm PST (0500 UTC) dev-vmware01 ESX server upgrade. We’ll be
upgrading the server hardware for dev-vmware01. During this window
the following VMs will be offline for 2 hours:
* mrapp-stage03
* sm-ctc01
* sm-chat01
* sm-cms01
* sm-crm01
* sm-dekistage01
* 9:00pm PST (0500 UTC) Netscaler OS upgrade. We’ll be upgrading the
Netscaler load balancers in San Jose, Amsterdam and Beijing to pick up
code fixes. No downtime is expected.
* 6:00pm PST (0200 UTC) bugzilla.mozilla.org update. We'll be
upgrading Bugzilla from version 3.2.4 to 3.4.3 (bug 503055). Duration
90 minutes.
Feel free to comment directly on the bug or on #bmo on irc.mozilla.org
if you see issues past the planned downtime.
--
* 6:00am PST (1400 UTC) stage.mozilla.org - core operating system will
be upgraded from RHEL4 to RHEL5. Expected downtime 60 minutes, things
may not behave quite right for an hour or two after the upgrade as the
loose ends get cleaned up. This will affect any build systems that
upload to stage.mozilla.org. (bug 524794)
Feel free to comment directly on the bug or on #build on irc.mozilla.org
* 5:00pm PST (0100 UTC) addons.mozilla.org update. We’ll be updating
addons.mozilla.org to pick up code updates (bug 529600). Duration 30
minutes.
* 9:00pm PST (0500 UTC) getpersonas.com GLB DNS change. We’ll be
making DNS changes to move getpersonas.com to our Zeus GLB servers
(bug 525908). No downtime expected.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.
Feel free to comment directly if you see issues past the planned
downtime.
* 6:00pm PST (0100 UTC) Breakpad upgrade. We will be upgrading the
breakpad environment to the next release ([1]). In addition, we will
also be making changes to the storage layout to help back-end storage
scaling. The crash collector should not be impacted during the
upgrade. The reporter however may be unavailable during parts of the
upgrade. Please contact us in #breakpad if you notice issues past 9pm.
Duration 3 hours.
* 6:00pm PST (0100 UTC) support.mozilla.com update. We’ll be updating
support.mozilla.com to pick up code updates (bug 532232). Duration 60
minutes.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.