X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C889EB.6F48D9FA@onstor-exch02.onstor.net>; Wed, 19 Mar 2008 11:02:45 -0700
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Content-class: urn:content-classes:message
Subject: RE: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and how do the cluster DB modify on cluster configuraton?" case 7476
Date: Wed, 19 Mar 2008 11:02:45 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E03E9A6E1@onstor-exch02.onstor.net>
In-Reply-To: <BB375AF679D4A34E9CA8DFA650E2B04E0889C04C@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and how do the cluster DB modify on cluster configuraton?" case 7476
Thread-Index: AciIIGVlAN+owYd+SO2X3WPburXaRwAQvPowAAAmZ2AAABjisAAa3PWAADmylhAACH5bfgAANnh5AARiJDA=
From: "Chris Vandever" <chris.vandever@onstor.com>
To: "Carlos Mora" <carlos.mora@onstor.com>,
	"Alan Cooke (Glasshouse)" <acooke@css.glasshouse.com>,
	"Larry Scheer" <larry.scheer@onstor.com>,
	"dl-cstech" <dl-cstech@onstor.com>

As I said, there is a single asCfg record in the clusDb.  The 'from'
field is part of it.  When it is changed on one node it is changed in
the asd app, and it is changed in the clusDb.  The clusDb change is
propagated throughout the cluster.  I do NOT believe that the asd apps
on the other nodes are notified of the change.  Thus, their in-memory
data structures still reflect the original value they read from the
clusDb when they were started.  They will not be updated until they are
rebooted (or asd is killed and restarted).

ChrisV

-----Original Message-----
From: Carlos Mora=20
Sent: Wednesday, March 19, 2008 9:02 AM
To: Carlos Mora; Alan Cooke (Glasshouse); Alan Cooke (Glasshouse); Chris
Vandever; Larry Scheer; dl-cstech
Subject: RE: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and
how do the cluster DB modify on cluster configuraton?" case 7476

The from entry is a single entry in the AS record of the clusterdb.
<rec_8448 recType=3DCLUSDB_REC_TYPE_AS_CFG key=3DasCfg >
<attributes>
	<recType valType=3Dint valSize=3D4> 3 <\recType>
	<recId valType=3Dint valSize=3D4> 8448 <\recId>
	<parentOffset valType=3Dint valSize=3D4> 10240 <\parentOffset>
	<parent valType=3Dint valSize=3D4> 4608 <\parent>
	<childOffset valType=3Dint valSize=3D4> 9984 <\childOffset>
	<keyLen valType=3Dint valSize=3D4> 5 <\keyLen>
	<keyOffset valType=3Dint valSize=3D4> 8704 <\keyOffset>
	<keyHash valType=3Dint valSize=3D4> 558 <\keyHash>
	<nextHash valType=3Dint valSize=3D4> 0 <\nextHash>
	<dataLen valType=3Dint valSize=3D4> 808 <\dataLen>
	<dataOffset valType=3Dint valSize=3D4> 8960 <\dataOffset>
	<counterReuse valType=3Dint valSize=3D4> 0 <\counterReuse>
	<counterMax valType=3Dint valSize=3D8> 0000000000000000
<\counterMax>
	<counterMin valType=3Dint valSize=3D8> 0000000000000000
<\counterMin>
	<counterLast valType=3Dint valSize=3D8> ffffffffffffffff
<\counterLast>
	<counterBmap valType=3Dint valSize=3D4> 0 <\counterBmap>
<\attributes>



<values>
	<enable valType=3Dint valSize=3D1> 0 <\enable>
	<to valType=3Dstring valSize=3D0>  <\to>
	<noteto valType=3Dstring valSize=3D0>  <\noteto>
	<minBitMap valType=3Dint valSize=3D8> 0000000000000001 <\minBitMap>
	<hourBitMap valType=3Dint valSize=3D4> 256 <\hourBitMap>
	<dateBitMap valType=3Dint valSize=3D4> 0 <\dateBitMap>
	<monthBitMap valType=3Dint valSize=3D4> 0 <\monthBitMap>
	<dayBitMap valType=3Dint valSize=3D4> 0 <\dayBitMap>
	<serverIp valType=3Dstring valSize=3D7> 0.0.0.0 <\serverIp>
	<from valType=3Dstring valSize=3D17> cslab1@onstor.com <\from>
<\values>
<\rec_8448>

You will notice that the very last value is the from field.
--
Carlos Mora
carlos.mora@onstor.com
ONStor, Inc.
Sr. Technical Support Engineer
(408)802-5602



-----Original Message-----
From: Carlos Mora
Sent: Wed 3/19/2008 11:47 AM
To: Alan Cooke (Glasshouse); Alan Cooke (Glasshouse); Chris Vandever;
Larry Scheer; dl-cstech
Cc: Carlos Mora
Subject: RE: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and
how do the cluster DB modify on cluster configuraton?" case 7476
=20
Even though the changes are actually placed in the clusterdb, the online
state of the other filer may not have been updated yet. One way to do
this is to just go to the other filer and make the change there as well.

--
Carlos Mora
carlos.mora@onstor.com
ONStor, Inc.
Sr. Technical Support Engineer
(408)802-5602



-----Original Message-----
From: Alan Cooke (Glasshouse)
Sent: Wed 3/19/2008 8:04 AM
To: Alan Cooke (Glasshouse); Chris Vandever; Larry Scheer; dl-cstech
Subject: RE: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and
how do the cluster DB modify on cluster configuraton?" case 7476
=20
Hi Guys,

I'm coming back to this because I'm not convinced.

I have just tried modifying the autosupport from email address on our
Glasshouse lab clustered systems Bobcat1 and Bobcat2.

The from was changed from the original houlding@css.glasshouse.com to
fredm@css.glasshouse.com=20

=20

bobcat1> autosupport show config

Auto Support configuration

--------------------------

Auto Support State: Enabled

Auto Support TO address: jmh2301@hotmail.com

Auto Support NOTETO address: alan.cooke2dive@ntlworld.com

Auto Support FROM address: houlding@css.glasshouse.com

Auto Support MAIL SERVER: 144.48.95.22

Auto Support Schedule:

               min  : 0

               hour : 0 6 12 18

               mday : *

               month: *

               wday : *

=20

=20

bobcat1> autosupport email from fredm@css.glasshouse.com

bobcat1> autosupport show config

Auto Support configuration

--------------------------

Auto Support State: Enabled

Auto Support TO address: jmh2301@hotmail.com

Auto Support NOTETO address: alan.cooke2dive@ntlworld.com

Auto Support FROM address: fredm@css.glasshouse.com

Auto Support MAIL SERVER: 144.48.95.22

Auto Support Schedule:

               min  : 0

               hour : 0 6 12 18

               mday : *

               month: *

               wday : *

=20

Unless I misunderstand you what should happen is that this from address
should migrate to the other system in the cluster - but it does not (
which in my mind is how it ought to be but that is not relevant ).

=20

bobcat2> autosupport show config

Auto Support configuration

--------------------------

Auto Support State: Enabled

Auto Support TO address: jmh2301@hotmail.com

Auto Support NOTETO address: alan.cooke2dive@ntlworld.com

Auto Support FROM address: houlding@css.glasshouse.com

Auto Support MAIL SERVER: 144.48.95.22

Auto Support Schedule:

               min  : 0

               hour : 0 6 12 18

               mday : *

               month: *

               wday : *

=20

So why should the customer's systems all show the same "from" address
after a system upgrade?

I'm not convinced this was an admin error.

=20

Regards .. Alan.

=20

________________________________

From: Alan Cooke [mailto:acooke@css.glasshouse.com]=20
Sent: 18 March 2008 08:15
To: 'Chris Vandever'; 'Larry Scheer'; 'dl-cstech'
Subject: RE: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and
how do the cluster DB modify on cluster configuraton?" case 7476

=20

Thanks for all your responses guys,

I think the reseller may be getting upset about a problem his customer
has told him has just "happened" which has really been them playing.

I will look at this more closely.

=20

Regards .. Alan.

=20

________________________________

From: Chris Vandever [mailto:chris.vandever@onstor.com]=20
Sent: 17 March 2008 19:48
To: Larry Scheer; Alan Cooke (Glasshouse); dl-cstech
Subject: RE: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and
how do the cluster DB modify on cluster configuraton?" case 7476

=20

There is a single asCfg record for the entire cluster in the clusDb.
This means that if the user changes the configuration on one node of the
cluster it will be changed on ALL nodes of the cluster.

=20

I suspect in this case the config had been changed on bobcat3.  I don't
know if/when such changes are propagated throughout the cluster.  I can
only find where we read the config from the clusDb when asd is first
started, but I may be missing something.

=20

ChrisV

=20

________________________________

From: Larry Scheer=20
Sent: Monday, March 17, 2008 12:23 PM
To: Chris Vandever; Alan Cooke (Glasshouse); dl-cstech
Subject: RE: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and
how do the cluster DB modify on cluster configuraton?" case 7476

=20

There is no part of system upgrade that changes records in the cluster
database. However systems upgrade -s will copy the cluster database from
the primary flash to the standby flash.

=20

Larry

________________________________

From: Chris Vandever=20
Sent: Monday, March 17, 2008 12:20 PM
To: Alan Cooke (Glasshouse); dl-cstech
Subject: RE: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and
how do the cluster DB modify on cluster configuraton?" case 7476

=20

There IS no cluster database upgrade involved in a system upgrade from
3.1.0.4 to 3.1.0.11.  If the EMRS record in the cluster database got
modified, then it must have occurred as part of the system upgrade
(which is a completely separate process from a clusDb upgrade) or it
must have been done manually.

=20

ChrisV

=20

________________________________

From: Alan Cooke (Glasshouse)=20
Sent: Monday, March 17, 2008 4:17 AM
To: dl-cstech
Subject: Question about when upgrades 3.1.0.4 to 3.1.0.11 "Why and how
do the cluster DB modify on cluster configuraton?" case 7476

=20

Hi Guys,

I have a customer, SGI Japan - case 7476 , who had their system EMRS
config changed by the upgrade when they went from 3.1.0.4 to 3.1.0.11.

Customer asks "Why and how do the cluster DB modify on cluster
configuration? =20

I think the question really is more like "why should the upgrade modify
this parameter? "

There is a defect open for this, 20699, but it the "Auto Support FROM
address:" parameter seems a bit of an odd field to change.

There were 3 systems in the cluster - cluster name was bobcat1. This
filer name was bobcat1 and the from field was changed to
bobcat3@jurists.co.jp - one of the other filer's names in the cluster.

=20

Any comments?

=20

Regards .. Alan.



