X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C8A73C.7B16F940@onstor-exch02.onstor.net>; Fri, 25 Apr 2008 18:25:58 -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: please review 28864
Date: Fri, 25 Apr 2008 18:25:58 -0700
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E03E9A7FA@onstor-exch02.onstor.net>
In-Reply-To: <20080425164050.0142042f@ripper.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: please review 28864
Thread-Index: AcinLcuJIApE2DjYRv6TjOZFxZl8TQACNVWg
From: "Chris Vandever" <chris.vandever@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>

OK.

Additional comments inline...

-----Original Message-----
From: Andy Sharp=20
Sent: Friday, April 25, 2008 4:41 PM
To: Chris Vandever
Subject: Re: please review 28864

On Thu, 24 Apr 2008 14:15:25 -0700 "Chris Vandever"
<chris.vandever@onstor.com> wrote:

> Try the code in ~chrisv/forAndy.  The comment block in the .h was
> out-of-sync with the .c, so while I was updating that, I switched it
> to follow the coding standard.  (I've gradually been converting
> clustering to follow the standard as I touch each function, so it's
> pretty ugly now during the conversion period.  You wouldn't know the
> former, although you probably noticed the latter.)

Well, I finally went and looked at these files, and while your changes
are pickyune and meaningless (I tease), I want to point out that my
comment block is just cut and modified from the function above, so I
can't be blamed for that.  It's not my fault.

CV> I did not mean to imply any blame.  You were doing exactly the right
thing by matching the existing style of the file.  I don't expect you to
know that I'm gradually converting the code to follow the coding
standard.  Nor, do I expect you to remember that next time.  I just
figured that since you were in there, I'd take advantage of the
opportunity, so that's one less function I have to convert later.

And while we're here, having the auto variables inside the if block
allows the compiler to write a highly optimized routine for the case
where it is called multiple times in a program.  I'm just sayin'.  Not
to blow my own horn or anything because I would never do that.

CV> Tell me more.  I'll try to remember to stop by next week.

> In the .c I eliminated errno.  While it's a nice idea, none of the
> other clustering code uses it.  I also converted the tabs to spaces,
> and made a few other cosmetic changes.  I also added the name of the
> mgmt vsvr in the elog if we couldn't convert the name to a vsId,
> since there will be multiple mgmt vsvrs in a cluster and it would be
> nice to know which one we had trouble with.

OK So I just cut and pasted your inferior^W version into the files.
You have plenty of time to double check that because now I have to
retest everthing. ~:^)

Oops, I retested before sending this, silly me.  At least we know it
compiles and works.

CV> Phew!  I was a bit nervous about not having compiled it, but
obviously not nervous enough to do so.  :)

> I must have missed those 6000 modified files.  :)

Sometime Superman is so fast you can't see ... oh forget it, there's no
joke there.

CV> Oh, come on, there's got to be a joke in there somewhere.

> ChrisV
>=20
> -----Original Message-----
> From: Andy Sharp=20
> Sent: Thursday, April 24, 2008 10:27 AM
> To: Chris Vandever
> Subject: Re: please review 28864
>=20
> On Tue, 22 Apr 2008 16:15:34 -0700 "Chris Vandever"
> <chris.vandever@onstor.com> wrote:
>=20
> > Comments inline...
> >=20
> > -----Original Message-----
> > From: Andy Sharp=20
> > Sent: Tuesday, April 22, 2008 3:15 PM
> > To: Chris Vandever
> > Subject: Re: please review 28864
> >=20
> > On Tue, 22 Apr 2008 15:05:21 -0700 "Chris Vandever"
> > <chris.vandever@onstor.com> wrote:
> >=20
> > > Well, that was fun.  My p4v refused to show me any files beyond
> > > cluster-vintf-api.h for some obscure reason.  Thankfully, killing
> > > it and restarting a new one did the trick, but it's certainly
> > > frustrating when the tools don't frickin' work!
> >=20
> > Use the script, Luke.  It almost never doesn't work ~:^)
> > =20
> > > code/ssc-cluster/cluster-vsvr-api.c:
> > > *	@5973 would you rename this cluster_getVsMgmtId() for
> > > consistency?  Thanks.
> >=20
> > Consistency with which?  It was that originally, but I could never
> > find it because I was always searching for getMgmtVsId "get
> > management vserver ID" which is what it does.  So it's consistent
> > with what it does ~:^)  "get vserver management ID" doesn't seem to
> > make sense. So, my question is, do I have to?
> >=20
> > CV>  Consistency with cluster_getVsMgmtName(), the function directly
> > above it.  You can rename cluster_getVsMgmtName() to
> > cluster_getMgmtVsName() if you prefer...
>=20
> OK, I changed both to the correct name.  Notice the 6000 new files
> added to this changelist.  Little Timmay would just love that.
>=20
> > > *	@5979 cluster_getFilerMgmtVsvr() requires 2 + N clusDb
> > > accesses. Instead you can just call cluster_getVsMgmtName(), pass
> > > the name to cluster_makeVsvrNameKey(), and then read the record
> > > data via cluster_getRecordDataByKey().  The record data is the
> > > vsId.  This would take a single clusDb lookup.
> >=20
> > But, but, then I would have to write the code myself!  And I would
> > have to learn 3 functions when I didn't learn any the first time
> > because I copied the code from somewhere else?
> >=20
> > CV>  Stop whining.  Do you want to maintain clustering?  :-)  Okay,
> > CV> to
> > make it even easier, just call cluster_getVsMgmtName() followed by
> > cluster_getVsvrIdByName().  Two calls.  You don't even need to
> > create a function to do it, you can call them directly, and then
> > you don't need to worry about naming conventions and my weird ass
> > ideas of consistency.
>=20
> Pfft, who cares how many accesses it has to do?  Oh yeah, this is an
> API function.  Please check this new code as I have no idea what I'm
> doing.
>=20
> > > ChrisV
> > >=20
> > > -----Original Message-----
> > > From: Andy Sharp=20
> > > Sent: Tuesday, April 22, 2008 10:12 AM
> > > To: Chris Vandever
> > > Cc: Rendell Fong
> > > Subject: please review 28864
> > >=20
> > > Chris,
> > >=20
> > > I am sending this to you because I want you to review the changes
> > > to the cluster api.  You don't have to look at the other files,
> > > but you're certainly welcome to if you want to ~:^)
> > >=20
> > > Rendell,
> > >=20
> > > Same goes for you, except the two patch files for exim4.  Again,
> > > you're welcome to look at the rest as well.
> > >=20
> > > Thanks,
> > >=20
> > > a
> > >=20
> > >=20
> > >=20
> > > Change 28864 by andys@ripper on 2008/04/17 12:57:47 *pending*
> > >=20
> > > 	TED00023344 - autosupport from secondary cluster node not
> > > working
> > > =09
> > > 	Properly obtain the mgmt vsvr id from the cluster API and
> > > 	query the DNS with it.
> > > =09
> > > 	Add a method to the cluster API to return the management
> > > vsvr id.
> > > =09
> > > 	Fix the change that was supposed to shut up the paniclog
> > > noise by putting a regex into /etc/default/exim4 that matches
> > > anything.
> > > =09
> > > 	reviewed by
> > >=20
> > > Affected files ...
> > >=20
> > > ...
> //depot/dev/linux/Pkgs/binary/Deb/exim4-base_4.63-17_mipsel.deb#5
> > > edit
> > > ...
//depot/dev/linux/Pkgs/binary/Deb/exim4-config_4.63-17_all.deb#2
> > > edit
> > > ...
> > >
> >
>
//depot/dev/linux/Pkgs/binary/Deb/exim4-daemon-custom_4.63-17_mipsel.deb
> > > #6 edit
> > > ... //depot/dev/linux/Pkgs/source/exim4/debian.patch#6 edit
> > > ...
//depot/dev/linux/Pkgs/source/exim4/onstor-vsvr-support.dpatch#2
> > > edit
> > > ... //depot/dev/nfx-tree/code/ssc-cluster/cluster-vsvr-api.c#7
> > > edit ...
//depot/dev/nfx-tree/code/ssc-cluster/cluster-vsvr-api.h#4
> > > edit
> > >=20
