[SSI-devel] Re: root failover
Brought to you by:
brucewalker,
rogertsang
From: Roger T. <rog...@gm...> - 2005-11-10 02:08:58
|
Hi Karl, On 11/9/05, Karl Merritts <km...@gm...> wrote: > > Brian and Roger, > There are two files that I have left to merge: mkinitrd and > util-linux/mount/mount.c. I will take the easier one first. > > With mkinitrd, it is the modified version of SuSE mkinitrd. It looks > like from what I have seen the OpenSSI features were added to the > original SuSE 9.2 Pro mkinitrd. So what really needs to be added to > the OpenSSI 1.9.2 SuSE Pro mkinitrd are the features exposed by doing > a diff between the MERGE-SU-FC and the OPENSSI-FC tags. This will > show me the features that have been added since the initial merge was > done. Does that makes sense as a good way to attack that merge? Yup. Mount.c is a little bit more difficult. I went through and looked at > the conflicts and edited the file to add the new ifndefs for CHARD and > PAM. Once that was finished I: > # diff openssi-merge/util-linux/mount.c openssi-fc/util-linux/mount.c > > Most of the file was the same but there were still some differences. > Is it best to take on the merge of mount.c in much the same way as I > am going to with mkinitrd above or should mount.c and for that matter > util-linux be the same between openssi-fc and openssi-su? You are patching a vanilla SuSE mount.c right? The remaining differences might be SuSE specific. If you're not sure, we can always take a look what you have. -Roger On 11/4/05, Karl Merritts <km...@gm...> wrote: > > Brian, > > Thanks for explanation. That makes more sense now. > > > > -Karl > > > > On 11/4/05, Brian J. Watson <Bri...@hp...> wrote: > > > > > > Karl Merritts wrote: > > > > Brian, > > > > The largest chunks of code seem to be in mount.c and mkinitrd > script. > > > > > > > > So I should just be able to do a: > > > > # cd openssi > > > > # cvs update > > > > > > > > That should give me all of the updates that Roger has checked for > the > > > > kernel right? > > > > I assume so but just want to make sure. > > > > > > Yes this should update the kernel* directories and all the other > aliased > > > directories with Roger's work. BTW, an even better version is: > > > > > > $ cvs -q update -dP > > > > > > The -q option to cvs makes it less chatty, which I like. The -d optio= n > > > to update tells it to pull in new directories, and the -P option tell= s > > > it to ignore directories that would otherwise be empty. > > > > > > For doing the actual merge, you need to use a different command: > > > > > > $ cvs -q update -dP -j MERGE-SU-FC -j OPENSSI-FC > > > > > > In addition to the options I already discussed above, this takes the > > > differences between the MERGE-SU-FC tag and the top of the OPENSSI-FC > > > branch and applies those changes as a patch against your current > working > > > directory. > > > > > > Rather than creating *.rej and *.orig files for conflicts like the > > > regular patch command, it puts patch conflicts inline into the source > > > files. If you subsequently run `cvs update', you'll see some files > > > marked with the code 'C' to indicate that they have unresolved > > > conflicts. Inside the file, you'll see the conflicts marked with > > > something like the following: > > > > > > <<<<<<< > > > existing code on the OPENSSI-SU branch > > > =3D=3D=3D=3D=3D=3D=3D > > > new code from the merge > > > >>>>>>> > > > > > > The conflict occurs because the existing code of the OPENSSI-SU branc= h > > > does not match the code that was changed on the OPENSSI-FC branch. > > > You'll have to figure out the appropriate way to modify the OPENSSI-S= U > > > code to integrate the change. This is the intellectually challenging > > > part of doing merges. > > > > > > > > > > Please explain briefly how the aliasing that you mention below work= s > > and > > > > should be implemented because on that part I am a bit confused. > > > > > > Please bear with me as I explain a bit of background... > > > > > > In CVS, branches are fundamentally just a set of numbers, separated b= y > > > the '.' character. You can recognize a branch number, because it has > an > > > odd count of numbers (branch 1.1.2). Sometimes a branch number is > shown > > > with an even count, by putting a 0 in the next-to-last position > (branch > > > 1.1.0.2 <http://1.1.0.2> <http://1.1.0.2> is the same as branch 1.1.2 > ). > > > > > > Associated with a branch number is a branch name, such as OPENSSI-SU. > If > > > you look at the `cvs log' output for a particular file, you'll see th= e > > > branch number with which OPENSSI-SU is associated. If you look at `cv= s > > > log' for multiple files, you might notice that the branch number for > > > OPENSSI-SU is not the same for all files (this is particularly true > for > > > our stable branches, like OPENSSI-FC-1-2-STABLE). The branch number i= s > > > based on the file's version number at the point where the branch was > > > created, and not all files have the same version number at that point= . > > > > > > There is a special branch that always has the same number, which is > the > > > trunk (branch 1). In the interest of not having to constantly merge > > > common code (like the kernel and openssi-tools) between development > > > branches, I realized that I could force the development branch names > to > > > be equal to branch 1 for all common files. The command to do this is > > > `cvs admin -n <branch_name>:<branch_number>'. > > > > > > Later on, I realized that it was also good to set the MERGE-*-* tags > > > equal to branch 1 for the common files, so that they wouldn't > interfere > > > while I was merging non-common code between development branches. > > > > > > The procedure for adding a new common file is: > > > > > > <checkout a trunk sandbox> > > > $ cd openssi > > > <create the new file, such as "foo"> > > > $ cvs add foo > > > $ cvs checkin > > > $ cvs admin -n OPENSSI-FC:1 foo > > > $ cvs admin -n OPENSSI-SU:1 foo > > > $ cvs admin -n OPENSSI-DEBIAN:1 foo > > > $ cvs admin -n MERGE-SU-FC:1 foo > > > $ cvs admin -n MERGE-DB-FC:1 foo > > > $ cvs admin -n MERGE-FC-SU:1 foo > > > $ cvs admin -n MERGE-FC-DB:1 foo > > > > > > > > > > What would I need to do to have lustre properly populated in the > > > > OPENSSI-SU if it is not checked into the repository? > > > > > > In one of my other recent e-mails, I listed the commands for doing > this. > > > > > > $ cd openssi/lustre <of a trunk or other development branch sandbox> > > > $ cvs admin -n OPENSSI-SU:1 > > > $ cvs admin -n MERGE-SU-FC:1 > > > $ cvs admin -n MERGE-FC-SU:1 > > > > > > Note that no filename is needed for these `cvs admin' commands, > because > > > you're applying the branch name recursively to everything below your > > > current working directory, whereas above I was just showing a single > > > common file being added. > > > > > > > > > > Thanks, > > > > Karl > > > > > > > > > Hope this helps, > > > > > > Brian > > > > > > > > > > > > > > > > That should be all I need to do > > > > > > > > On 10/27/05, *Brian J. Watson* < Bri...@hp... > > > > <mailto:Bri...@hp...>> wrote: > > > > > > > > Hi Karl, > > > > > > > > Just a simple update (no -j options) should be all that is needed t= o > > get > > > > the stuff in kernel.patches/common. The stuff in there is identical > > > > between development branches, so no real merge is needed. > > > > > > > > The stuff in openssi/lustre should also be common files. The reason > you > > > > got it with your merge is because aliases have not been created for > > > > OPENSSI-SU, MERGE-SU-FC, and MERGE-FC-SU. What you should do is run > > > > `cvs > > > > rm -f lustre' in your merge sandbox for OpenSSI, so that you don't > > > > checkin an identical but separate copy of Lustre. Later, you or > Roger > > > > should create the three aliases that I listed above, so that this > > > > doesn't happend again. > > > > > > > > Are there any other huge chunks of code that were introduced by you= r > > > > merge? > > > > > > > > Best, > > > > > > > > Brian > > > > > > > > > > > > Roger Tsang wrote: > > > > > Actually no. I just finished adding the MERGE tags for those > > > > files in > > > > > kernel.patches/common. Run your cvs update again and send me the > > > > > output. Thanks. > > > > > > > > > > Roger > > > > > > > > > > On 10/27/05, *Karl Merritts* < km...@gm... > > > > <mailto:km...@gm...> > > > > > <mailto:km...@gm... <mailto:km...@gm...>>> wrote: > > > > > > > > > > > > > > > Roger, > > > > > I went ahead and ran the cvs update -j MERGE-SU-FC -j > > > > OPENSSI-FC. > > > > > There were only 6 files that had conflicts. Is there anyway to > > > > > verify that this is all the needs to be done? My plan was > > > > to build > > > > > and make sure the things that were affected work correctly > > > > before I > > > > > tagged. With all of the packages and patches that were > > > > added(lustre > > > > > etc.) it would quite a bit of work to verify everything on > > > > SuSE. So > > > > > should I just focus on core functionality? Any suggestions for > > > > > testing would be greatly appreciated. > > > > > > > > > > On to the kernel issue. The way I have understood it is that > > > > this > > > > > is also one of the pieces that is shared between all of the > > > > OpenSSI > > > > > distros. So I should have also recieved all of you kernel > > > > changes > > > > > when I ran the update, right? > > > > > Are kernel changes checked in the tarball or applied as patches? > > > > > From I have seen it looks like the latter. > > > > > > > > > > -Karl > > > > > > > > > > > > > > > > > > > > On 10/27/05, *Roger Tsang* < rog...@gm... > > > > <mailto:rog...@gm...> > > > > > <mailto: rog...@gm... > > > > <mailto:rog...@gm...>>> wrote: > > > > > > > > > > Hi Karl, > > > > > > > > > > By the way what is there in the kernel to merge to > > > > OPENSSI-SU > > > > > branch? I thought Brian said all the development > > > > branches share > > > > > the same branch for the kernel sources which means my > > > > OPENSSI-FC > > > > > checkin's were done on the trunk and OPENSSI-FC is just a tag > > > > > for the openssi/kernel/ directory. > > > > > > > > > > -Roger > > > > > > > > > > > > > > > > > > > > On 10/27/05, *Karl Merritts* <km...@gm... > > > > <mailto:km...@gm...> > > > > > <mailto:km...@gm... <mailto:km...@gm...>> > wrote: > > > > > > > > > > Stephan, > > > > > I will announce it to you and the list. > > > > > > > > > > -Karl > > > > > > > > > > > > > > > On 10/27/05, *Stephan B=F6ni* < bo...@bp... > > > > <mailto:bo...@bp...> > > > > > <mailto: bo...@bp... <mailto:bo...@bp...>>> wrote: > > > > > > > > > > Karl, > > > > > > > > > > Thanks. Could you send me a mail, when it's ready? > > > > > > > > > > Stephan > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > *Von:* Karl Merritts [mailto:km...@gm... > > > > <mailto:km...@gm...> > > > > > <mailto:km...@gm... > > > > <mailto:km...@gm...>>] > > > > > *Gesendet:* Donnerstag, 27. Oktober 2005 17:45 > > > > > *An:* Steven Van Acker > > > > > *Cc:* Stephan B=F6ni; > > > > > ssi...@li... > > > > <mailto:ssi...@li...> > > > > > > > > > <mailto:ssi...@li... > > > > <mailto:ssi...@li...>> > > > > > *Betreff:* Re: [SSI-users] root failover > > > > > > > > > > Stephan, > > > > > You may want to wait on trying that right now. > > > > > There are a bunch of changes that I am merging in > > > > > from the FC tree. One of the major features that > > > > > this enables is root failover. > > > > > > > > > > -Karl > > > > > > > > > > On 10/27/05, *Steven Van Acker* > > > > > <dee...@ul... > > > > <mailto:dee...@ul...> <mailto: dee...@ul... > > > > <mailto:dee...@ul...>>> > > > > > wrote: > > > > > > > > > > On Thu, Oct 27, 2005 at 01:58:09PM +0200, > > > > > Stephan B?ni wrote: > > > > >> > > > > >> I've installed now my first cluster node, > > > > > but without root failover. > > > > >> How can i create now the root failover. I > > > > > think, that i have to use > > > > >> the clusterfstab command, but i don't know > > > > > to correct syntax to > > > > >> configure it. What is a UUID? And where can > > > > > i find the correct UUID? > > > > > > > > > > Hi, > > > > > > > > > > you may want to use the ssi-chnode > > > > command for that > > > > > > > > > > greets, > > > > > -- Steven > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > This SF.Net email is sponsored by the > > > > JBoss Inc. > > > > > Get Certified Today * Register for a JBoss > > > > > Training Course > > > > > Free Certification Exam for All Training > > > > > Attendees Through End of 2005 > > > > > Visit > > > > > http://www.jboss.com/services/certification > > > > > <http://www.jboss.com/services/certification> > > > > > for more information > > > > > > > > > _______________________________________________ > > > > > Ssic-linux-users mailing list > > > > > Ssi...@li... > > > > <mailto:Ssi...@li...> > > > > > > > > > <mailto:Ssi...@li... > > > > <mailto:Ssi...@li...>> > > > > > > > > > https://lists.sourceforge.net/lists/listinfo/ssic-linux-users > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > |