[Spread-users] Spread 4.0.0rc2 to official 4.0.0 upgrade

Jonathan Stanton jonathan at cnds.jhu.edu
Mon Nov 5 20:12:02 EST 2007

That's good to know. I don't remember if I tested it myself, but I'm not 
surprised it doesn't work as there were several bug fixes between rc2 and 
final that had to make some daemon packet changes. For example:

Sun Nov 19 15:13:47 2006  Jonathan Stanton  <jonathan at cnds.jhu.edu>

	* sess_body.h, groups.h, groups.c (group,G_build_groups_buf): 
	Fix big-endian bug caused by int->char memcpy. 
	group->changed field is now a boolean instead of int.
	Value sent in GROUPS message is an int16u to have fixed size.
	Use GROUPS_BUF_* macros instead of recalcuating size.

	Split into a version that returns changed status as a bool
	and a void return for G_eliminate_partitioned_members().
	Rename G_check_synced_set to void G_update_synced_set() and
	bool G_update_synced_set_status().
	Change return value of G_check_if_changed_by_cascade() to bool.
	Use bool types for all 'changed' type variables.


Fri Nov 17 13:36:12 2006  Jonathan Stanton  <jonathan at cnds.jhu.edu>

	* groups.c (G_mess_to_groups,G_build_groups_buf): Fix race
	condition bug that caused group members on different daemons
	to see different group_id's for the same group.

Mixing versions of the daemons has generally not worked in the past. A few
times it happened to work because of the changes in that version, but it
isn't usually safe. Changes between patch version changes (4.0.1) do try not
to break compatibility between daemons and definitely don't break the
client-server protocol so that you can upgrade to get bug fixes without
changing clients. 

As to the 4.0.0rc2 - 4.0.0 client-server protocol, I don't see any changes 
to it, but there were some bugfixes to the client library that you may want, 
which would require relinking with the new libraries. 

The major client library API change in 4 (compared to 3.17) was the 
new membership parsing functions SP_get_memb_info, 
get_vs_sets_info(), etc and they were already in before rc2.



 On Mon, Nov 05, 2007 at 03:51:45PM -0600, Matt Garman wrote:
> > Thursday, November 1, 2007, 12:57:27 PM, you wrote:
> > > My main question is: are 4.0.0rc2 and 4.0.0 backwards- and
> > > forwards-compatible, both in the daemons and at the API level?  Do
> > > we need to recompile all systems, or can we incrementally do it?
> On Thu, Nov 01, 2007 at 01:35:47PM -0400, John Lane Schultz wrote:
> > They are completely compatible at the API level.
> > 
> > I'm not 100% sure at the daemon level.  Jonathan, can you answer
> > this?
> My quick informal test suggests that they are *not* compatible at
> the daemon level.
> I have a spread segment configured for four nodes.  All nodes were
> running 4.0.0rc2.  I killed one of the daemons, and re-started with
> 4.0.0.  It immediately crashed with an assertion failure in
> G_compare_proc_ids_by_conf().
> I then killed all rc2 daemons and started only 4.0.0 daemons, and
> everything so far appears to be fine.
> Hope this helps someone,
> Matt
> _______________________________________________
> Spread-users mailing list
> Spread-users at lists.spread.org
> http://lists.spread.org/mailman/listinfo/spread-users

Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    

More information about the Spread-users mailing list