Bug 736015 - Review Request: fedfs-utils - Utilities for mounting and managing FedFS domains
Summary: Review Request: fedfs-utils - Utilities for mounting and managing FedFS domains
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Eric Sandeen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-06 12:27 UTC by Jeff Layton
Modified: 2013-08-18 19:09 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-12-01 12:55:02 UTC
esandeen: fedora-review+
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Jeff Layton 2011-09-06 12:27:29 UTC
Spec URL: http://fedorapeople.org/~jlayton/fedfs-utils/fedfs-utils.spec

SRPM URL: http://fedorapeople.org/~jlayton/fedfs-utils/fedfs-utils-0.7.0-1.fc15.src.rpm

Description: 

RFC 5716 introduces the Federated File System (FedFS, for short). FedFS
is an extensible standardized mechanism by which system administrators
construct a coherent namespace across multiple file servers using file
system referrals.

A file system referral is like a symbolic link to another file system
share, but it is not visible to applications. It behaves like an
automounted directory where a new file system mount is done when an
application first accesses that directory. The arguments of the mount
operation are controlled by information returned by the file server.

Today, file system referral mechanisms exist in several network file
system protocols. FedFS provides its namespace features by leveraging
referral mechanisms already built in to network file system protocols.
Thus no change to file system protocols or clients is required.

Currently, the Linux FedFS implementation supports only NFS version 4
referrals. More on NFS version 4 referrals can be found in RFC 3530.
FedFS may support other network file system protocols in the future.

Comment 1 Jeff Layton 2011-09-06 12:29:47 UTC
Also, note that I've started a feature page for fedfs that I'm targeting for F17:

    http://fedoraproject.org/wiki/Features/FedFS

...it's still skeletal at this point, but I'll flesh it out more in the near future.

Comment 2 Chuck Lever 2011-09-07 04:32:19 UTC
(In reply to comment #1)
> Also, note that I've started a feature page for fedfs that I'm targeting for
> F17:
> 
>     http://fedoraproject.org/wiki/Features/FedFS
> 
> ...it's still skeletal at this point, but I'll flesh it out more in the near
> future.

Just a couple of notes on the F17 project web site.

  1.  In the "Scope" section you might reference the fedfs-utils upstream project web site, for more information:

     http://oss.oracle.com/projects/fedfs-utils

In addition to license information, interested readers can find presentation slides, the FedFS LDAP schema, and a project roadmap.

  2.  In the "Dependencies" section, you should list nfs-utils along with the kernel patches.  Changes are needed to mountd in order to process junctions.  I've discussed these plans with Steve, but we can fill in more details on this site if that's required.

Additionally, LDAP servers need to have the FedFS LDAP schema installed.  Finally, /etc/rpc needs to be updated to include the IANA-assigned fedfs RPC program number.  There are bugzillas filed for each of these items.

  3.  We should note somewhere (maybe in the "Benefit to Fedora" section) that fedfs-utils is part of a larger, ongoing effort to build out storage administration features on Linux file servers.  This includes, to name but a few:

  *  The ability to manage NFS referrals either via FedFS or via a simple command line tool on file servers
  *  Support for SMB2 in a FedFS framework
  *  Support for NFSv4.1's fs_locations_info attribute
  *  Client-side support for NFSv4 migration with transparent state migration
  *  Support for transparent NFS client access to replicated file sets

Comment 3 Jeff Layton 2011-09-07 10:28:38 UTC
Thanks Chuck. I've updated the wiki page with the above suggestions.

Comment 4 Volker Fröhlich 2011-09-08 20:44:15 UTC
It's common to group the %files sections at the bottom and %package and %description sections at the top.

defattr was found to be not necessary after EPEL 4.

Add Changelog, COPYING and README to the base package via %doc.

Use the name macro whereever it makes sense to replace the actual name, like in Source0.

If you're not aiming for EPEL5 or older, Buildroot, clean section and the rm in the install section are not needed.

Replace the .gz in the files sections with .*

[makerpm@fedora15 fedfs-utils-0.7.0-1.fc15.src]$ rpmlint ../fedfs-utils-0.7.0-1.fc15.src ~/rpmbuild/RPMS/x86_64/fedfs-utils-*
fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated
fedfs-utils-client.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-client.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated
fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/mount.fedfs.8.gz 141: warning: macro `NF' not defined
fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/mount.fedfs.8.gz 142: warning: macro `TA' not defined
fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/mount.fedfs.8.gz 144: warning: macro `FI' not defined
fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/fedfs-map-nfs4.8.gz 90: warning: macro `NF' not defined
fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/fedfs-map-nfs4.8.gz 91: warning: macro `TA' not defined
fedfs-utils-client.x86_64: W: manual-page-warning /usr/share/man/man8/fedfs-map-nfs4.8.gz 93: warning: macro `FI' not defined
fedfs-utils-common.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-common.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated
fedfs-utils-nsdbparams.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-nsdbparams.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated
fedfs-utils-server.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-server.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated
fedfs-utils-server.x86_64: W: non-standard-uid /var/lib/fedfs fedfs
fedfs-utils-server.x86_64: W: non-standard-gid /var/lib/fedfs fedfs
fedfs-utils-server.x86_64: E: non-standard-dir-perm /var/lib/fedfs 0700L
fedfs-utils-server.x86_64: W: no-manual-page-for-binary resolve-junction
6 packages and 1 specfiles checked; 1 errors, 19 warnings.

You can try to iron out the glitches in the manpage after it's generated. I don't know, if it is possible to remove the cause.

Use the _sharedstatedir macro for /var/lib.

The sub-packages should require the common package, see: http://fedoraproject.org/wiki/Packaging:Guidelines#Requiring_Base_Package

The common package can be labeled noarch.

I don't know anything about fedfs-utils, but breaking a quarter of a megabyte into 5 parts is probably not necessary.

Comment 5 Chuck Lever 2011-09-12 15:58:16 UTC
Proposed solutions:

(In reply to comment #4)
> 
> [makerpm@fedora15 fedfs-utils-0.7.0-1.fc15.src]$ rpmlint
> ../fedfs-utils-0.7.0-1.fc15.src ~/rpmbuild/RPMS/x86_64/fedfs-utils-*
> fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US namespace ->
> name space, name-space, names pace

"name space" is fine, but "namespace" seems to be a common item of terminology.  Should rpmlint be updated, or can we ignore this warning?

> fedfs-utils-server.x86_64: W: non-standard-uid /var/lib/fedfs fedfs
> fedfs-utils-server.x86_64: W: non-standard-gid /var/lib/fedfs fedfs

I'd like a special user and group for fedfs operation, although we could also use the same one nfs-utils uses, which is "rpcuser" I believe.  Really, though, this value needs to be specified via a ./configure option as well, to make it easy for distributions to set it how they like.  I'm not familiar with the rules around UID and GID usage.

> fedfs-utils-server.x86_64: E: non-standard-dir-perm /var/lib/fedfs 0700L

What is suggested?

> fedfs-utils-server.x86_64: W: no-manual-page-for-binary resolve-junction

resolve-junction is going away in 0.8.0, which is why I didn't compose a man page for it.  However, we could easily add a stub man page in 0.7, similar to the man page for mount.nfs.

> I don't know anything about fedfs-utils, but breaking a quarter of a megabyte
> into 5 parts is probably not necessary.

We could reduce it to just three:  one common noarch package, one for client pieces, and one for everything else.

Comment 6 Jeff Layton 2011-09-12 17:49:40 UTC
I've uploaded a newer fedfs-utils SRPM and specfile to my fedorapeople page:

    http://fedorapeople.org/~jlayton/fedfs-utils/0.7.0-2/

I think this addresses almost all of the things that rpmlint complained about.
The only exceptions are:

1) the complaints about "namespace" and "automounted". I'd argue that those
are valid terms and the dictionary just lacks them for whatever reason. I'd
suggest that we just ignore those warnings. If that's not acceptable, then
I suppose we could change them, but I'd rather not.

2) I did not change the layout/number of packages. We could reduce the
number of packages if that's necessary, but this breaks things up in a
reasonably granular way such that clients and admin machines won't need to
have unnecessary binaries installed. I'm flexible on this point however if
the reviewers think that this many packages is overkill. We could even
reduce it to one single package -- after all, we ship nfs-utils as a single
package...

3) I didn't worry about the resolve-junction manpage since that program is
going away (as Chuck points out).

Comment 7 Jeff Layton 2011-11-05 10:09:54 UTC
I've updated the package to 0.7.2 release and have added a systemd service file for rpc.fedfsd.

    http://fedorapeople.org/~jlayton/fedfs-utils/0.7.2-1/

Comment 8 Jeff Layton 2011-11-30 17:55:12 UTC
Updated the package to 0.7.3 and respun the "contrib" patch to better match
what will be in 0.8.0:

    http://fedorapeople.org/~jlayton/fedfs-utils/0.7.3-1/

Comment 9 Jeff Layton 2011-11-30 18:14:57 UTC
For the record, the only rpmlint warnings left are these:

fedfs-utils.src: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils.src: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automated

...and I think those are just gaps in the dictionary. Also, I've left it as 5 packages for now. If it's really a problem to keep it that granular, then let me know.

Comment 10 Eric Sandeen 2011-11-30 20:51:41 UTC
MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review.

$ rpmlint fedfs-utils*.rpm
fedfs-utils.src: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils.src: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled
fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-admin.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled
fedfs-utils-client.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-client.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled
fedfs-utils-common.noarch: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-common.noarch: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled
fedfs-utils-nsdbparams.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-nsdbparams.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled
fedfs-utils-server.x86_64: W: spelling-error %description -l en_US namespace -> name space, name-space, names pace
fedfs-utils-server.x86_64: W: spelling-error %description -l en_US automounted -> auto mounted, auto-mounted, automobiled
fedfs-utils-server.x86_64: W: no-manual-page-for-binary resolve-junction
7 packages and 0 specfiles checked; 0 errors, 13 warnings.

MUST: The package must be named according to the Package Naming Guidelines.
OK

MUST: The spec file name must match the base package %{name}, in the format %{name}.spec unless your package has an exemption.
OK (fedfs-utils.spec)

MUST: The package must meet the Packaging Guidelines.
OK

MUST: The package must be licensed with a Fedora approved license and meet the Licensing Guidelines.
OK (License:        GPLv2)

MUST: The License field in the package spec file must match the actual license.
OK (not v2+)

MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in %doc.
OK (%doc COPYING README ChangeLog)

MUST: The spec file must be written in American English.
OK

MUST: The spec file for the package MUST be legible.
OK

MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use md5sum for this task. If no upstream URL can be specified for this package, please see the Source URL Guidelines for how to deal with this.
wget http://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-utils-0.7.3.tar.gz
dad5ceedfb05974837673664de6b158a  fedfs-utils-0.7.3.tar.gz
dad5ceedfb05974837673664de6b158a  fedfs-utils-0.7.3.tar.gz.1
OK

MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture.
OK (http://koji.fedoraproject.org/koji/taskinfo?taskID=3554224)

MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in ExcludeArch. Each architecture listed in ExcludeArch MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding ExcludeArch line.
OK (all primary architectures built)

MUST: All build dependencies must be listed in BuildRequires, except for any that are listed in the exceptions section of the Packaging Guidelines ; inclusion of those as BuildRequires is optional. Apply common sense.
OK (koji build was fine)

MUST: The spec file MUST handle locales properly. This is done by using the %find_lang macro. Using %{_datadir}/locale/* is strictly forbidden.
OK (no locales)

MUST: Every binary RPM package (or subpackage) which stores shared library files (not just symlinks) in any of the dynamic linker's default paths, must call ldconfig in %post and %postun.
OK (no libraries)

MUST: Packages must NOT bundle copies of system libraries.
OK (no libraries)

MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker.
OK

MUST: A package must own all directories that it creates. If it does not create a directory that it uses, then it should require a package which does create that directory.
OK (/var/lib/fedfs created & owned)

MUST: A Fedora package must not list a file more than once in the spec file's %files listings. (Notable exception: license texts in specific situations)
OK

MUST: Permissions on files must be set properly. Executables should be set with executable permissions, for example.
OK

MUST: Each package must consistently use macros.
OK

MUST: The package must contain code, or permissable content.
OK

MUST: Large documentation files must go in a -doc subpackage. (The definition of large is left up to the packager's best judgement, but is not restricted to size. Large can refer to either size or quantity).
OK (no doc package, no large docs)

MUST: If a package includes something as %doc, it must not affect the runtime of the application. To summarize: If it is in %doc, the program must run properly if it is not present.
OK (%doc COPYING README ChangeLog)

MUST: Header files must be in a -devel package.
OK (no header files shipped)

MUST: Static libraries must be in a -static package.
OK (no libraries, static or otherwise)

MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.
OK (no libraries)

MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name}%{?_isa} = %{version}-%{release}
OK (no devel pkg)

MUST: Packages must NOT contain any .la libtool archives, these must be removed in the spec if they are built.
OK (none)

MUST: Packages containing GUI applications must include a %{name}.desktop file, and that file must be properly installed with desktop-file-install in the %install section. If you feel that your packaged GUI application does not need a .desktop file, you must put a comment in the spec file with your explanation.
OK (no gui)

MUST: Packages must not own files or directories already owned by other packages. The rule of thumb here is that the first package to be installed should own the files or directories that other packages may rely upon. This means, for example, that no package in Fedora should ever share ownership with any of the files or directories owned by the filesystem or man package. If you feel that you have a good reason to own a file or directory that another package owns, then please present that at package review time.
OK

MUST: All filenames in rpm packages must be valid UTF-8.
OK

Looks fine to me.

Thanks,
-Eric

Comment 11 Jeff Layton 2011-11-30 22:08:21 UTC
New Package SCM Request
=======================
Package Name: fedfs-utils
Short Description: Utilities for mounting and managing FedFS
Owners: jlayton
Branches: 
InitialCC:

Comment 12 Gwyn Ciesla 2011-11-30 23:26:34 UTC
Git done (by process-git-requests).

Comment 13 Jeff Layton 2011-12-01 12:55:02 UTC
Thanks for all the help. I think we're done here!

Comment 14 Chuck Lever 2013-08-16 20:35:56 UTC
Package Change Request
======================
Package Name: fedfs-utils
New Branches: epel 6
Owners: ikent steved mrchuck

We'd like to get fedfs-utils 0.9.2 into EPEL so it can be installed on EL6 systems.  There is a dependency on the uriparser package, which exists in EPEL, but is not in the base EL6 packages.

Comment 15 Christopher Meng 2013-08-17 01:28:06 UTC
(In reply to Chuck Lever from comment #14)
> Package Change Request
> ======================
> Package Name: fedfs-utils
> New Branches: epel 6
> Owners: ikent steved mrchuck
> 
> We'd like to get fedfs-utils 0.9.2 into EPEL so it can be installed on EL6
> systems.  There is a dependency on the uriparser package, which exists in
> EPEL, but is not in the base EL6 packages.

Branch "epel 6" is invalid, oracle guy.

Comment 16 Chuck Lever 2013-08-17 01:30:06 UTC
(In reply to Christopher Meng from comment #15)
> (In reply to Chuck Lever from comment #14)
> > Package Change Request
> > ======================
> > Package Name: fedfs-utils
> > New Branches: epel 6
> > Owners: ikent steved mrchuck
> > 
> > We'd like to get fedfs-utils 0.9.2 into EPEL so it can be installed on EL6
> > systems.  There is a dependency on the uriparser package, which exists in
> > EPEL, but is not in the base EL6 packages.
> 
> Branch "epel 6" is invalid, oracle guy.

Help me out, then.  What branch do I want?

Comment 17 Jeff Layton 2013-08-17 10:19:53 UTC
Chuck, I think you want to follow the trail of breadcrumbs from here:

    http://fedoraproject.org/wiki/EPEL/FAQ#How_do_I_request_a_EPEL_branch_for_an_existing_Fedora_package.3F

Since this bug is closed, you'll either want to reopen it and take ownership of it or create a new bug.

Comment 18 Chuck Lever 2013-08-17 20:05:28 UTC
(In reply to Jeff Layton from comment #17)
> Chuck, I think you want to follow the trail of breadcrumbs from here:
> 
>    
> http://fedoraproject.org/wiki/EPEL/
> FAQ#How_do_I_request_a_EPEL_branch_for_an_existing_Fedora_package.3F
> 
> Since this bug is closed, you'll either want to reopen it and take ownership
> of it or create a new bug.

Hi Jeff-

I'm looking at:

  http://fedoraproject.org/wiki/Getting_a_Fedora_package_in_EPEL

and

  https://fedoraproject.org/wiki/Package_SCM_admin_requests?rd=PackageMaintainers/CVSAdminProcedure

Which seem to more or less agree with the link you posted:  find the original package review bug (this one), leave it CLOSED, change the fedora-cvs field to "?", and post the request in that bug using the SCM Change Request Template.

The only thing I missed was mentioning that I am one of the Fedora fedfs-utils package co-maintainers.  I discussed this request at the June NFS Bake-a-thon with Steve Dickson (steved) in person, who is also interested in this change.

I do not see mention in any of these links of which SCM branch to specify to request EPEL packaging.  Maybe the right answer is "EL-6" ?

Comment 19 Jeff Layton 2013-08-18 11:08:01 UTC
Yeah, I think it has to be 'el6', actually. IIRC, there's a script that scrapes these requests and does it automatically, so getting the form correct is important.

Comment 20 Chuck Lever 2013-08-18 17:02:51 UTC
Package Change Request
======================
Package Name: fedfs-utils
New Branches: el6
Owners: iankent steved mrchuck

The fedfs-utils package maintainers would like to get fedfs-utils-0.9 into EPEL so that it can be installed on EL6 systems.

Comment 21 Kevin Fenzi 2013-08-18 19:09:54 UTC
Git done (by process-git-requests).


Note You need to log in before you can comment on or make changes to this bug.