X-MimeOLE: Produced By Microsoft Exchange V6.5
Received: by onstor-exch02.onstor.net 
	id <01C7EBFD.7CE5B3D3@onstor-exch02.onstor.net>; Fri, 31 Aug 2007 10:33:55 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C7EBFD.7CE5B3D3"
References: <200708311242.l7VCgB6w032748@localhost.localdomain> <20070831082136.5268e594@ripper.onstor.net>
Content-class: urn:content-classes:message
Subject: RE: Compilation failure in dev branch
Date: Fri, 31 Aug 2007 10:29:56 -0800
Message-ID: <BB375AF679D4A34E9CA8DFA650E2B04E02F3D707@onstor-exch02.onstor.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Compilation failure in dev branch
Thread-Index: Acfr4qBnbPrCYv5uQnyVPdbOP0/7egAGk3rb
From: "Ken Renshaw" <ken.renshaw@onstor.com>
To: "Andy Sharp" <andy.sharp@onstor.com>,
	"Build Admin" <build@localhost.localdomain>
Cc: "Sandrine Boulanger" <sandrine.boulanger@onstor.com>,
	"Paul Hammer" <paul.hammer@onstor.com>,
	"Brian DeForest" <brian.deforest@onstor.com>,
	"dl-Cougar" <dl-Cougar@onstor.com>,
	"Chris Vandever" <chris.vandever@onstor.com>

This is a multi-part message in MIME format.

------_=_NextPart_001_01C7EBFD.7CE5B3D3
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Definitely, this should have been in the body:
---
[build@k2 Friday]$ cat err.out
/perforce/buildlogs/dev/Friday/bl-dbg-compile.log:make[2]: *** =
[../../Build/bl/dbg/Objects/SSC/ssc-cluster/clusdb-tools.o] Error 1
/perforce/buildlogs/dev/Friday/bl-dbg-compile.log:make[1]: *** [default] =
Error 1
/perforce/buildlogs/dev/Friday/bl-dbg-compile.log:make: *** [ssc] Error =
2
/perforce/buildlogs/dev/Friday/bl-opt-compile.log:make[2]: *** =
[../../Build/bl/opt/Objects/SSC/ssc-cluster/clusdb-tools.o] Error 1
/perforce/buildlogs/dev/Friday/bl-opt-compile.log:make[1]: *** [default] =
Error 1
/perforce/buildlogs/dev/Friday/bl-opt-compile.log:make: *** [ssc] Error =
2
/perforce/buildlogs/dev/Friday/cg-dbg-compile.log:make[2]: *** =
[../../Build/cg/dbg/Objects/SSC/ssc-cluster/clusdb-tools.o] Error 1
/perforce/buildlogs/dev/Friday/cg-dbg-compile.log:make[1]: *** [default] =
Error 1
/perforce/buildlogs/dev/Friday/cg-dbg-compile.log:make: *** [ssc] Error =
2
/perforce/buildlogs/dev/Friday/cg-opt-compile.log:make[2]: *** =
[../../Build/cg/opt/Objects/SSC/ssc-cluster/clusdb-tools.o] Error 1
/perforce/buildlogs/dev/Friday/cg-opt-compile.log:make[1]: *** [default] =
Error 1
/perforce/buildlogs/dev/Friday/cg-opt-compile.log:make: *** [ssc] Error =
2

Please check compilation logs at http://liszt for today for the dev =
branch
---

The full error is this:

clusdb-tools.c: In function 'dbtools_showUbikHdr':
clusdb-tools.c:427: warning: format '%x' expects type 'unsigned int', =
but argument 2 has type 'time_t'
clusdb-tools.c: In function 'dbtools_setUbikVersion':
clusdb-tools.c:1878: warning: format '%x' expects type 'unsigned int', =
but argument 3 has type 'time_t'
clusdb-tools.c:1882: warning: format '%x' expects type 'unsigned int', =
but argument 3 has type 'time_t'


I've been modifying the behavior of the build script fast and furious, =
and blew it with yesterday's changes to the notification email =
apparently.

I'll get the problem with the script taken care of, and I'm sure Chris =
will take care of the problem with this checkin that breaks cougar =
targets:

Change 25218 by chrisv@chrisv-dev on 2007/08/30 15:41:43

        Partial fix #18293 (vsvrs appear on multiple nodes): In a
        split-brain scenario if we can't enable the vsvrs that have
        failed over onto the node, then our clusDb is out of sync
        with the rest of the system.
        - Add an API to invalidate the clusDb and reboot when
        we know we can't make the system config match the
        clusDb and believe we're in a split-brain scenario.
        - When VSD fails to mount a volume due to ownership
        issues and we think we're in a split-brain scenario, use
        the new API to call clustering to invalidate the clusDb and
        reboot.
        - Add a command to dbtools to set the version number in
        the clusDb to either invalid or valid, but make the valid
        one old enough we won't confuse it with something that's
        actually valid.  This should only be used when there is no
        other valid clusDb in the cluster.
        - Fix interlock between init and failover (hold filer); it was
        allowing another node to initiate failover of our vsvrs
        between cluster init and vtm init when we were already
        committed to claiming them.  (Failover will still occur if the
        FP crashes or the node goes down during that
        timeframe.)
        - Clean up *_RestartClusterSver() functions.
        - Clean up misc related cluster_contrl functions.
        - Clean up error recovery if cluster_contrl doesn't think the
        clusDb is ready.

        Reviewed by JonG

Affected files ...

... //depot/dev/nfx-tree/code/ssc-cluster/clusdb-tools.c#2 edit
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-api.c#3 edit
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-contrl-cache.c#2 edit
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-contrl-cfg.c#2 edit
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-contrl-rpc.c#2 edit
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-contrl.h#2 edit
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-func.h#2 edit
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-msg.h#2 edit
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-server-rpc.c#2 edit
... //depot/dev/nfx-tree/code/ssc-cluster/cluster_int.xg#2 edit
... //depot/dev/nfx-tree/code/ssc-vsd/vs-daemon.c#9 edit


Thanks all,

-Ken

-----Original Message-----
From: Andy Sharp
Sent: Fri 8/31/2007 8:21 AM
To: Build Admin
Cc: Sandrine Boulanger; Paul Hammer; Ken Renshaw; Brian DeForest; =
dl-Cougar
Subject: Re: Compilation failure in dev branch
=20
On Fri, 31 Aug 2007 05:42:11 -0700 Build Admin
<build@localhost.localdomain> wrote:

>=20


Uh, I'm feeling like there was supposed to be a body to this email?
Kind of like the inverse of the headless horseman of doom.






------_=_NextPart_001_01C7EBFD.7CE5B3D3
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7652.24">
<TITLE>RE: Compilation failure in dev branch</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Definitely, this should have been in the body:<BR>
---<BR>
[build@k2 Friday]$ cat err.out<BR>
/perforce/buildlogs/dev/Friday/bl-dbg-compile.log:make[2]: *** =
[../../Build/bl/dbg/Objects/SSC/ssc-cluster/clusdb-tools.o] Error 1<BR>
/perforce/buildlogs/dev/Friday/bl-dbg-compile.log:make[1]: *** [default] =
Error 1<BR>
/perforce/buildlogs/dev/Friday/bl-dbg-compile.log:make: *** [ssc] Error =
2<BR>
/perforce/buildlogs/dev/Friday/bl-opt-compile.log:make[2]: *** =
[../../Build/bl/opt/Objects/SSC/ssc-cluster/clusdb-tools.o] Error 1<BR>
/perforce/buildlogs/dev/Friday/bl-opt-compile.log:make[1]: *** [default] =
Error 1<BR>
/perforce/buildlogs/dev/Friday/bl-opt-compile.log:make: *** [ssc] Error =
2<BR>
/perforce/buildlogs/dev/Friday/cg-dbg-compile.log:make[2]: *** =
[../../Build/cg/dbg/Objects/SSC/ssc-cluster/clusdb-tools.o] Error 1<BR>
/perforce/buildlogs/dev/Friday/cg-dbg-compile.log:make[1]: *** [default] =
Error 1<BR>
/perforce/buildlogs/dev/Friday/cg-dbg-compile.log:make: *** [ssc] Error =
2<BR>
/perforce/buildlogs/dev/Friday/cg-opt-compile.log:make[2]: *** =
[../../Build/cg/opt/Objects/SSC/ssc-cluster/clusdb-tools.o] Error 1<BR>
/perforce/buildlogs/dev/Friday/cg-opt-compile.log:make[1]: *** [default] =
Error 1<BR>
/perforce/buildlogs/dev/Friday/cg-opt-compile.log:make: *** [ssc] Error =
2<BR>
<BR>
Please check compilation logs at <A =
HREF=3D"http://liszt">http://liszt</A> for today for the dev branch<BR>
---<BR>
<BR>
The full error is this:<BR>
<BR>
clusdb-tools.c: In function 'dbtools_showUbikHdr':<BR>
clusdb-tools.c:427: warning: format '%x' expects type 'unsigned int', =
but argument 2 has type 'time_t'<BR>
clusdb-tools.c: In function 'dbtools_setUbikVersion':<BR>
clusdb-tools.c:1878: warning: format '%x' expects type 'unsigned int', =
but argument 3 has type 'time_t'<BR>
clusdb-tools.c:1882: warning: format '%x' expects type 'unsigned int', =
but argument 3 has type 'time_t'<BR>
<BR>
<BR>
I've been modifying the behavior of the build script fast and furious, =
and blew it with yesterday's changes to the notification email =
apparently.<BR>
<BR>
I'll get the problem with the script taken care of, and I'm sure Chris =
will take care of the problem with this checkin that breaks cougar =
targets:<BR>
<BR>
Change 25218 by chrisv@chrisv-dev on 2007/08/30 15:41:43<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Partial fix #18293 (vsvrs =
appear on multiple nodes): In a<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; split-brain scenario if we =
can't enable the vsvrs that have<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; failed over onto the node, =
then our clusDb is out of sync<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; with the rest of the =
system.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Add an API to invalidate =
the clusDb and reboot when<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; we know we can't make the =
system config match the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clusDb and believe we're in a =
split-brain scenario.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - When VSD fails to mount a =
volume due to ownership<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; issues and we think we're in =
a split-brain scenario, use<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the new API to call =
clustering to invalidate the clusDb and<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; reboot.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Add a command to dbtools to =
set the version number in<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; the clusDb to either invalid =
or valid, but make the valid<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; one old enough we won't =
confuse it with something that's<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; actually valid.&nbsp; This =
should only be used when there is no<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; other valid clusDb in the =
cluster.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Fix interlock between init =
and failover (hold filer); it was<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; allowing another node to =
initiate failover of our vsvrs<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; between cluster init and vtm =
init when we were already<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; committed to claiming =
them.&nbsp; (Failover will still occur if the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; FP crashes or the node goes =
down during that<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; timeframe.)<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Clean up =
*_RestartClusterSver() functions.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Clean up misc related =
cluster_contrl functions.<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; - Clean up error recovery if =
cluster_contrl doesn't think the<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; clusDb is ready.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Reviewed by JonG<BR>
<BR>
Affected files ...<BR>
<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/clusdb-tools.c#2 edit<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-api.c#3 edit<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-contrl-cache.c#2 =
edit<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-contrl-cfg.c#2 =
edit<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-contrl-rpc.c#2 =
edit<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-contrl.h#2 edit<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-func.h#2 edit<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-msg.h#2 edit<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/cluster-server-rpc.c#2 =
edit<BR>
... //depot/dev/nfx-tree/code/ssc-cluster/cluster_int.xg#2 edit<BR>
... //depot/dev/nfx-tree/code/ssc-vsd/vs-daemon.c#9 edit<BR>
<BR>
<BR>
Thanks all,<BR>
<BR>
-Ken<BR>
<BR>
-----Original Message-----<BR>
From: Andy Sharp<BR>
Sent: Fri 8/31/2007 8:21 AM<BR>
To: Build Admin<BR>
Cc: Sandrine Boulanger; Paul Hammer; Ken Renshaw; Brian DeForest; =
dl-Cougar<BR>
Subject: Re: Compilation failure in dev branch<BR>
<BR>
On Fri, 31 Aug 2007 05:42:11 -0700 Build Admin<BR>
&lt;build@localhost.localdomain&gt; wrote:<BR>
<BR>
&gt;<BR>
<BR>
<BR>
Uh, I'm feeling like there was supposed to be a body to this email?<BR>
Kind of like the inverse of the headless horseman of doom.<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C7EBFD.7CE5B3D3--
