[Ocfs2-devel] ocfs2-1.0.0 ebuilds

[Ocfs2-devel] ocfs2-1.0.0 ebuilds

[lazar obradovic]

Hello all,

ocfs2-1.0.0 and ocfs2-tools-1.0.0 ebuilds are uploaded and available 
from bugs.gentoo.org (old bz# 98024).

-- 
LO275-RIPE

[Ocfs2-devel] ocfs2-1.0.1 ebuilds

[lazar obradovic]

Gentoo ocfs2 1.0.1 ebuilds are available from 
http://bugs.gentoo.org/show_bug.cgi?id=98024

Enjoy (:

-- 
LO275-RIPE

[Ocfs2-devel] ocfs2-1.0.1 ebuilds

[Manish Singh]

On Mon, Aug 15, 2005 at 11:20:16PM +0200, lazar obradovic wrote:
> Gentoo ocfs2 1.0.1 ebuilds are available from 
> http://bugs.gentoo.org/show_bug.cgi?id=98024

A few comments and questions:

> KEYWORDS="-* ~x86"

Does that mean this is only enabled for x86 platforms? 1.0.x works on
x86_64 and ia64 too.

The glib2 dependency in the tools should not be in the gtk2 option,
since ocfs2cdsl and debug.ocfs2 depend on it too, and they are command
line tools. Passing --disable-gtktest in the non-gtk2 case is kind of
silly, since there isn't any test for gtk itself, only pygtk.

The python binding for VTE is needed for some ocfs2console functionality
(though it does work without it).

Why are you using --prefix=/ ?

It looks like you are still installing a sample cluster.conf. This makes
no sense, there's no sane defaults for it, and putting the sample will
only lead to confusion.

Replacing the o2cb init script with your own is a bad idea. This makes
the gentoo distribution gratuitiously incompatible with the OCFS2
documentation out there, as well as breaking some ocfs2console
functionality. Please don't do this.

-Manish

[Ocfs2-devel] ocfs2-1.0.1 ebuilds

[Sunil Mushran]

I have not seen the changes in code but the comments in the bug
indicate they have to do with adding umounts in o2cb stop.

Maybe a better idea would be to have a generic ocfs2 mount/umount
service as follows:
http://oss.oracle.com/bugzilla/attachment.cgi?id=162

This one is for SLES9. Maybe someone can write one up for gentoo.

If so, please add it as an attachment to bug:
http://oss.oracle.com/bugzilla/show_bug.cgi?id=524

Doc-ing this would be far easier.

Thanks
Sunil

Manish Singh wrote:

>On Mon, Aug 15, 2005 at 11:20:16PM +0200, lazar obradovic wrote:
>  
>
>>Gentoo ocfs2 1.0.1 ebuilds are available from 
>>http://bugs.gentoo.org/show_bug.cgi?id=98024
>>    
>>
>
>A few comments and questions:
>
>  
>
>>KEYWORDS="-* ~x86"
>>    
>>
>
>Does that mean this is only enabled for x86 platforms? 1.0.x works on
>x86_64 and ia64 too.
>
>The glib2 dependency in the tools should not be in the gtk2 option,
>since ocfs2cdsl and debug.ocfs2 depend on it too, and they are command
>line tools. Passing --disable-gtktest in the non-gtk2 case is kind of
>silly, since there isn't any test for gtk itself, only pygtk.
>
>The python binding for VTE is needed for some ocfs2console functionality
>(though it does work without it).
>
>Why are you using --prefix=/ ?
>
>It looks like you are still installing a sample cluster.conf. This makes
>no sense, there's no sane defaults for it, and putting the sample will
>only lead to confusion.
>
>Replacing the o2cb init script with your own is a bad idea. This makes
>the gentoo distribution gratuitiously incompatible with the OCFS2
>documentation out there, as well as breaking some ocfs2console
>functionality. Please don't do this.
>
>-Manish
>_______________________________________________
>Ocfs2-devel mailing list
>Ocfs2-devel@oss.oracle.com
>http://oss.oracle.com/mailman/listinfo/ocfs2-devel
>  
>

[Ocfs2-devel] ocfs2-1.0.1 ebuilds

[lazar obradovic]

Sunil Mushran wrote:

> I have not seen the changes in code but the comments in the bug
> indicate they have to do with adding umounts in o2cb stop.

'init script' in bug report refers to new gentoo-style init script...
I added unmount to that one, not the original one... Please take a look 
at sys-fs/ocfs2-tools/files/ocfs2.init file in the attachment.

> Maybe a better idea would be to have a generic ocfs2 mount/umount
> service as follows:
> http://oss.oracle.com/bugzilla/attachment.cgi?id=162
> This one is for SLES9. Maybe someone can write one up for gentoo.

ocfs2 should be added to gentoo's list of network filesystems (I forgot 
to open a bug on baselayout, just did it now - gentoo bz#102659 ), so 
netmount script will take care of mounting and unmounting it.

However, if you decide to stop ocfs2 cluster by other means than 
rebooting, it's initscript should unmount every ocfs2 mountpoint. Piece 
of script I copied from gentoo's netmount is far more complex, since 
'umount -at ocfs2' might fail if someone is still using files on ocfs2. 
It adds a extra layer, killing all the processes that have open files on 
the mountpoint one is trying to unmount, so I find it a better solution.

> If so, please add it as an attachment to bug:
> http://oss.oracle.com/bugzilla/show_bug.cgi?id=524
> Doc-ing this would be far easier.

Will do, as soon as I fix errors previously noted by manish.singh. I 
think this piece of code should also be usable on SLES and RHEL...

-- 
LO275-RIPE

[Ocfs2-devel] ocfs2-1.0.1 ebuilds

[Manish Singh]

On Tue, Aug 16, 2005 at 01:47:24AM +0200, lazar obradovic wrote:
> Sunil Mushran wrote:
> 
> >Maybe a better idea would be to have a generic ocfs2 mount/umount
> >service as follows:
> >http://oss.oracle.com/bugzilla/attachment.cgi?id=162
> >This one is for SLES9. Maybe someone can write one up for gentoo.
> 
> ocfs2 should be added to gentoo's list of network filesystems (I forgot 
> to open a bug on baselayout, just did it now - gentoo bz#102659 ), so 
> netmount script will take care of mounting and unmounting it.
> 
> However, if you decide to stop ocfs2 cluster by other means than 
> rebooting, it's initscript should unmount every ocfs2 mountpoint. Piece 
> of script I copied from gentoo's netmount is far more complex, since 
> 'umount -at ocfs2' might fail if someone is still using files on ocfs2. 
> It adds a extra layer, killing all the processes that have open files on 
> the mountpoint one is trying to unmount, so I find it a better solution.

The cluster stack and the filesystem stuff should be distinct. If an fs
is still mounted, trying to stop the cluster service should simply fail,
and not try to unmount anything.

Killing all processes will screw up someone trying to use ocfs2 as their
root filesystem, so that's a bad idea.
 
-Manish

[Ocfs2-devel] ocfs2-1.0.1 ebuilds

[lazar obradovic]

Manish Singh wrote:

>A few comments and questions:
>  
>

Thanks for the feedback.

>>KEYWORDS="-* ~x86"
>>    
>>
>
>Does that mean this is only enabled for x86 platforms? 1.0.x works on
>x86_64 and ia64 too.
>  
>
Yes, and it's masked unstable for x86.
I was not aware of the fact that it also works on amd64 and ia64 (though 
I see a lot of *-endian fixups lately), so I'll mark it unstable on 
those platforms as well.
ocfs2 is definitely not working on ppc, ppc64, mips, sparc, alpha or 
hppa, nor will, in the near future?

>The glib2 dependency in the tools should not be in the gtk2 option,
>since ocfs2cdsl and debug.ocfs2 depend on it too, and they are command
>line tools. 
>
Will correct it, thanks.

>Passing --disable-gtktest in the non-gtk2 case is kind of
>silly, since there isn't any test for gtk itself, only pygtk.
>  
>
gtktest broke the emerge of ocfs2-tools and --disable-gtktest seem to work.
I'll check the exact reason for it and offer a solution instead of 
workaround, but until then, it's best if it stays like this.

>The python binding for VTE is needed for some ocfs2console functionality
>(though it does work without it).
>  
>
Thanks for this one too, I'll add VTE to deps list.

>Why are you using --prefix=/ ?
>  
>
econf is a wrapper around configure script that gives gentoo-defaults of 
paths to regular configure. Among these, default value for prefix is 
/usr, so it would break o2cb_ctl (as a workaround, init script could 
update /proc/sys/fs/ocfs2/nm/hb_ctl_path but I find that dirtier than 
giving --prefix=/ to econf).
On the other hand, this leads to installation of python extensions under 
/lib, instead of /usr/lib, which is fixed later, during src_install... 
Confiure's python.m4 should probably be updated to properly detect 
pyexecdir (or, perhaps, give the option to specify it).

>It looks like you are still installing a sample cluster.conf. This makes
>no sense, there's no sane defaults for it, and putting the sample will
>only lead to confusion.
>  
>
Gentoo's config protection will take care of that during the upgrades, 
and I find templates with bogus data rather useful for a quick 
first-time configuration... If you insist, I could push the empty config 
for first-time installs, with commented templates...

>Replacing the o2cb init script with your own is a bad idea. This makes
>the gentoo distribution gratuitiously incompatible with the OCFS2
>documentation out there, as well as breaking some ocfs2console
>functionality. Please don't do this.
>  
>
As stated in INSTALL.GENTOO:

---8<---
KNOWN BUGS
==========
1. Init script does not have all the functionality as o2cb script
----------------------------------------------------------------
I know that, but o2cb script doesn't use "depend" and therefore it's start
can't be controlled inside runlevel. I had to rewrite major portions of it
to make it gentoo-friendly. o2cb is still available, and if you need
additional functionality from /etc/init.d/ocfs2, file a bugreport (see
"Reporting Bugs" below).
---8<---

That's why Gentoo init script is not called o2cb, but simple ocfs2, 
since it's not a full replacement. As users request, I'll add parts to 
ocfs2.init, and untill that, o2cb is still available.

Once again, thanks for the feedback.

-- 
LO275-RIPE

[Ocfs2-devel] ocfs2-1.0.1 ebuilds

[Manish Singh]

On Tue, Aug 16, 2005 at 01:24:29AM +0200, lazar obradovic wrote:
> Manish Singh wrote:
> 
> >A few comments and questions:
> > 
> >
> 
> Thanks for the feedback.
> 
> >>KEYWORDS="-* ~x86"
> >>   
> >>
> >
> >Does that mean this is only enabled for x86 platforms? 1.0.x works on
> >x86_64 and ia64 too.
> > 
> >
> Yes, and it's masked unstable for x86.
> I was not aware of the fact that it also works on amd64 and ia64 (though 
> I see a lot of *-endian fixups lately), so I'll mark it unstable on 
> those platforms as well.

Well, amd64 and ia64 are little endian too, so 1.0.x works fine.

> ocfs2 is definitely not working on ppc, ppc64, mips, sparc, alpha or 
> hppa, nor will, in the near future?

The big endian support is in 1.1.x now. So all those arches work in the
bleeding edge code.

> >The glib2 dependency in the tools should not be in the gtk2 option,
> >since ocfs2cdsl and debug.ocfs2 depend on it too, and they are command
> >line tools. 
> >
> Will correct it, thanks.
> 
> >Passing --disable-gtktest in the non-gtk2 case is kind of
> >silly, since there isn't any test for gtk itself, only pygtk.
> > 
> >
> gtktest broke the emerge of ocfs2-tools and --disable-gtktest seem to work.
> I'll check the exact reason for it and offer a solution instead of 
> workaround, but until then, it's best if it stays like this.

Something else must've broken then, since there simply is no gtk2 test
performed. Perhaps you're confusing things with --disable-glibtest,
which should've been addressed if you get the glib2 dependencies right.
 
> >The python binding for VTE is needed for some ocfs2console functionality
> >(though it does work without it).
> > 
> >
> Thanks for this one too, I'll add VTE to deps list.
> 
> >Why are you using --prefix=/ ?
> > 
> >
> econf is a wrapper around configure script that gives gentoo-defaults of 
> paths to regular configure. Among these, default value for prefix is 
> /usr, so it would break o2cb_ctl (as a workaround, init script could 
> update /proc/sys/fs/ocfs2/nm/hb_ctl_path but I find that dirtier than 
> giving --prefix=/ to econf).

No, it wouldn't. You're supposed to use --prefix=/usr. There's a
separate --root-prefix which defaults to /, where stuff like o2cb_ctl
lands.

This is the same semantics as e2fsprogs.

> On the other hand, this leads to installation of python extensions under 
> /lib, instead of /usr/lib, which is fixed later, during src_install... 
> Confiure's python.m4 should probably be updated to properly detect 
> pyexecdir (or, perhaps, give the option to specify it).

And if you do --prefix=/usr, this is a non-issue.

> >It looks like you are still installing a sample cluster.conf. This makes
> >no sense, there's no sane defaults for it, and putting the sample will
> >only lead to confusion.
> > 
> >
> Gentoo's config protection will take care of that during the upgrades, 
> and I find templates with bogus data rather useful for a quick 
> first-time configuration... If you insist, I could push the empty config 
> for first-time installs, with commented templates...

Users are expected to use ocfs2console to make the config file, so this
stuff is really for advanced users. If you really want a sample there,
then yeah, have it all commented out. Actually having it active is bad,
since you currently can't remove nodes out of a live cluster
configuration. So having a fake configuration will be bad news for users
who use ocfs2console to make their cluster config.
 
> >Replacing the o2cb init script with your own is a bad idea. This makes
> >the gentoo distribution gratuitiously incompatible with the OCFS2
> >documentation out there, as well as breaking some ocfs2console
> >functionality. Please don't do this.
> > 
> >
> As stated in INSTALL.GENTOO:
> 
> ---8<---
> KNOWN BUGS
> ==========
> 1. Init script does not have all the functionality as o2cb script
> ----------------------------------------------------------------
> I know that, but o2cb script doesn't use "depend" and therefore it's start
> can't be controlled inside runlevel. I had to rewrite major portions of it
> to make it gentoo-friendly. o2cb is still available, and if you need
> additional functionality from /etc/init.d/ocfs2, file a bugreport (see
> "Reporting Bugs" below).
> ---8<---
> 
> That's why Gentoo init script is not called o2cb, but simple ocfs2, 
> since it's not a full replacement. As users request, I'll add parts to 
> ocfs2.init, and untill that, o2cb is still available.

ocfs2console expects there to be an /etc/init.d/o2cb, and expects
start/stop/online semantics. Otherwise the cluster configuration
functionality will be degraded.

If o2cb.init needs a "depend" to be happy with Gentoo, please provide a
patch to o2cb.init that provides this. Implementing a separate init
script that does different things than every other Linux distribution
creates user confusion.

Also, the cluster stack only supports having a single cluster right now,
so the stuff in ocfs2.conf is misleading.

-Manish