xrootd.org

Release announcement - 3.3.2

xrootd-dev@slac.stanford.edu (XRootD Developers) — Fri, 26 Apr 2013 00:00:00 -0700

Release announcement - 3.3.2

The XRootD 3.3.2 bugfix release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs exceptionally have not been pushed to the yum repositories, due to some deployments issues related to the package names conflicting with EPEL.

Source: http://xrootd.org/download/v3.3.2/xrootd-3.3.2.tar.gz
RPMs: http://xrootd.cern.ch/sw/releases/3.3.2/rpms/
Release Notes: https://github.com/xrootd/xrootd/blob/v3.3.2/docs/ReleaseNotes.txt

Please note, that we now also provide experimental python bindings:

RPMs: http://xrootd.cern.ch/sw/releases/python/0.1.0/
Documentation: http://xrootd.org/doc/python/xrootd-python-0.1.0/

Collaboration Meeting Minutes

xrootd-dev@slac.stanford.edu (XRootD Developers) — Wed, 20 Mar 2013 00:00:00 -0700

XRootD Collaboration Meeting held at CERN 20-March-2013

Attendees:

Dirk Duellmann (CERN)
Gerardo Ganis (CERN)
Andrew Hanushevsky (SLAC)
Lukasz Janyst (CERN)
Andreas Peters (CERN)
Justin Salmon (CERN)

Discussion Topics

Releases

The 3.3.1 release was two months late, so we should rethink the release schedule. Every six months would seem to be more realistic.

The 3.3.2 bug fix release expected 1st week of April
The 3.3.3 release, no earlier than June unless we find serious problems
The 4.0.0 release expected mid-July.

We generally support only the current minor release. We generally support the last minor release for one year after we produce a major release.

Next major release

The following items are planned for the 4.0.0 major release:

IPV6
Protocol bridge interface
Readv passthrough (Brian Bockelman).
I/O throttling plug-in (if we get it from Brian Bockelman)
The new client interface will become stable if ready
- XrdPosix using the new client
- TXNetFile using the new client
- xrdcopy will be renamed to xrdcp and the current xrdcp replaces xrdcpold.
- Perhaps a wrapper or command line option for xrdcp to get previous version.

EPEL conformance

EPEL has created the RPMs for 3.3.1 and they are in the EPEL testing repository for EPEL5, EPEL6 and recent Fedora. They should be available in the EPEL stable repos soon.

The git repository

We are migrating to GitHub for source in the next few days and bug tracking before CERN moves to Jira.

VOMS plug-in

The updated VOMS RPM should be available by March 23rd. It is going to be separately released because it depends on the external VOMS library. It should go to OSG for US and EPEL for EU. We should touch bases with David Smith. This RPM will only available for 3.3.x.

Other items

Python bindings will be ready for 3.3.2. They work with Python 2.4 and up and be distributed as a separate package. We plan to withdraw the Perl bindings.
C++11 will be enabled when gcc 4.7 packages become available until then we will up the warning level and include server and client compilations to catch and fix problems.
Exploring client-side plug-in to enable novel data access mechanisms.

Release announcement - 3.3.1

xrootd-dev@slac.stanford.edu (XRootD Developers) — Wed, 06 Mar 2013 00:00:00 -0800

Release announcement - 3.3.1

The XRootD 3.3.1 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Note: This release restores binary compatibility with 3.2.x that 3.3.0 has broken.

Warning for sites using PROOF and ROOT upgrading to 3.3.0

xrootd-dev@slac.stanford.edu (XRootD Developers) — Mon, 25 Feb 2013 00:00:00 -0800

Warning for sites using PROOF upgrading to 3.3.0

We have encountered a binary incompatibility issue in one of the private xrootd classes used by PROOF and ROOT which may applications using 3.3.0 to crash unless they are recompiled. We do not advise recompiling any applications and to wait until this issue is resolved in xrootd 3.3.1 which is currently being tested. Be aware that if you recompile for 3.3.0 you will need to recompile again for 3.3.1.

Release announcement - 3.3.0

xrootd-dev@slac.stanford.edu (XRootD Developers) — Mon, 18 Feb 2013 00:00:00 -0800

Release announcement - 3.3.0

The XRootD 3.3.0 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Release candidate announcement - 3.3.0-rc3

xrootd-dev@slac.stanford.edu (XRootD Developers) — Wed, 06 Feb 2013 00:00:00 -0800

Release candidate announcement - 3.3.0-rc3

The XRootD 3.3.0 release candidate 3 has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the testing yum repositories.

Release candidate announcement - 3.3.0-rc2

xrootd-dev@slac.stanford.edu (XRootD Developers) — Tue, 18 Dec 2012 00:00:00 -0800

Release candidate announcement - 3.3.0-rc2

The XRootD 3.3.0 release candidate 2 has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the testing yum repositories.

Release announcement - 3.2.7

xrootd-dev@slac.stanford.edu (XRootD Developers) — Tue, 11 Dec 2012 00:00:00 -0800

Release announcement - 3.2.7

The XRootD 3.2.7 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Release candidate announcement - 3.3.0-rc1

xrootd-dev@slac.stanford.edu (XRootD Developers) — Thu, 08 Nov 2012 00:00:00 -0800

Release candidate announcement - 3.3.0-rc1

The XRootD 3.3.0 release candidate 1 has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the testing yum repositories.

Release announcement - 3.2.6

xrootd-dev@slac.stanford.edu (XRootD Developers) — Mon, 05 Nov 2012 00:00:00 -0800

Release announcement - 3.2.6

The XRootD 3.2.6 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Collaboration Meeting Minutes (24-October-2012)

xrootd-dev@slac.stanford.edu (XRootD Developers) — Wed, 24 Oct 2012 00:00:00 -0700

XRootD Collaboration Meeting held at CERN 24-October-2012

Attendees:

Dirk Duellmann (CERN)
Gerardo Ganis (CERN)
Andrew Hanushevsky (SLAC)
Lukasz Janyst (CERN)
Danila Oleynik (JINR)
Andreas Peters (CERN)
Justin Salmon (CERN)

Discussion Topics

Releases

We are now 3.2.5 next 3.2.6 rc-1 patch release is schedule for Wednesday, October 31st. All patch submitters must supply their list of patches that should be included in 3.2.6 prior to this time. There is still one outstanding patch (Certificate Cache Serialization) that is still in testing but should be available prior to this date. Fortunately, all of them for this cycle were at this meeting.

Relative to the root release, root 5.34.02 (currently out) and subsequent patch releases will still use the old client. Root 6.0.0 candidate release will be out 10/30 with a production release scheduled for 12/2. This happily coincides with the XRootD 3.3.0 release schedule.

Next minor release

The next minor release will be 3.3.0. There are approximately 700 patches outstanding for this release (about 450 related to the new client). The release candidate, 3.3.0-rc1 is scheduled for Friday, November 2nd. The new client will be available as code in development in this release. Generally, everything that is in git head will be in this release. Production release is scheduled for December 2nd.

The three most significant user changes in 3.3.0 are:

xrdcpy will be renamed to xrdcp with xrdcp becoming xrdcpold. The new xrdcp adopts the backwards compatible but a more user-friendly command line interface that is used by all subsequent versions of xrdcp.
Third-party copy support as the new xrdcp interface includes that.
The XRootD protocol will be available as a plug-in shared library that can be used by xproofd allowing the root team to retire the rootd daemon.

Next major release

The next major release, 4.0.0 is scheduled for the first part of March, 2013. It will minimally include:

Full production version of the new client,
xrdcopy (new client) will replace xrdcp
XrdPosix will use the new client (this means that the proxy server and FUSE will use the new client)
IPV6 (will require plug-in writers to recompile their code)
The readv pass-through enhancement supplied by CMS

Some significant user changes are:

The xrdfs command replaces the xrd command to provide full access to XRootD features using the new client. The new interface is much more user-friendly.
The new client-based xrdcopy replaces xrdcp but the interface does not change,
While the new client can co-exist with the old client, the new client will become the default for the root plug-in. However, the old client can be selected by either an envar setting or a root.rc directive.
The two year support life-time clock for the old client starts ticking.

EPEL conformance

Generally, all EPEL related concerns have been addressed for DPM, ROOT, EOS, and CMS. We now have a list of publicly supported API and a support statement on how those API will be treated across releases. This has been tentatively approved by EPEL This, we can be in compliance starting at release 3.3.0.

Action Item: LJ will touch bases with Doug Strain (OSG) on 3.3.0 for EPEL compliance and keep in touch with Mattias Ellert (the EPEL coordinator) to make sure we are on track.

The git repository

The new client is in github. However, the repositories will be merged for 3.3.0 but ABI compatibility will not be guaranteed for the new client until 4.0.0. The collaboration expressed passive interest (most neutral and 3 positive) to moving the repository to github. The positives are that better tools are available in github and that the project will receive more visibility. The move will occur {+|-} two weeks around 4.0.0.

Action Item: LJ will research the security implications of shared access (i.e. controlling writes) in github.

Automated testing

Justin Salmon finished the automatic development framework and developed some functionality tests which include:

GSI, Kerberos, frm, meta-manager
Automatic cluster instantiations
Copy back/forth, stats
Fuse test for meta operations

Additional tests are needed, especially in testing performance retrogression. Some tests came from Doug Strain (OSG). In fact, we will encourage OSG involvement with the anticipation that they will adopt the automated test framework. In any case, we need more test programs from participants.

Action Item: ABH will ask Wei Yang and Doug Benjamin for test programs

Action Item: ABH will add Justin to xrootd-dev and obtains a SLAC account for him.

Software development for 6 months

While the following list seems short, given all the activity in producing the 4.0.0 release it should come as no surprise. So far we have:

Parallel writes in new client.
Third party copy using a delegated proxy certificate.

Release announcement - 3.2.5

xrootd-dev@slac.stanford.edu (XRootD Developers) — Thu, 04 Oct 2012 00:00:00 -0700

Release announcement - 3.2.5

The XRootD 3.2.5 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Release announcement - 3.2.4

xrootd-dev@slac.stanford.edu (XRootD Developers) — Mon, 10 Sep 2012 00:00:00 -0700

Release announcement - 3.2.4

The XRootD 3.2.4 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Release announcement - 3.2.3

xrootd-dev@slac.stanford.edu (XRootD Developers) — Tue, 04 Sep 2012 00:00:00 -0700

Release announcement - 3.2.3

The XRootD 3.2.3 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Release announcement - 3.2.2

xrootd-dev@slac.stanford.edu (XRootD Developers) — Mon, 18 Jun 2012 00:00:00 -0700

Release announcement - 3.2.2

The XRootD 3.2.2 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Release Management Meeting Minutes (15-June-2012)

xrootd-dev@slac.stanford.edu (XRootD Developers) — Fri, 15 Jun 2012 00:00:00 -0700

Release Management Meeting 15-June-2012

Attendees:

Gerri Ganis (CERN)
Andrew Hanushevsky (SLAC)
Lukasz Janyst (CERN)

We discussed the release schedule for the next 9 months or so. The summary of the discussion:

Patch release 3.2.2 is scheduled to be available by June-20-2012.
Minor release 3.3.0 should be available by September-5-2012. Hoever, given the number of meetings scheduled for September, it may slip to the end of the month. Included in this release:
- Refactoring of shared libraries and include files for full EPEL compatability. Plugin writers should see no operational changes. However, not all include files will be available. Specifically, we will now only install include files required for public interfaces and commonly utility classes.
- Changes to all source file to indicate that the code is now available under the GNU Lesser General Public License (LGPL). See http://www.gnu.org/licenses/ for details.
- Internal version checking run-time subsystem. This subsystem checks that all plug-ins as well as cross library linkages are compatible with each other. Any attempt to use incompatible code will cause the program to issue a warning, advise which version should have been used to compile the code, and exit.
- The new xroot client will become available in beta form. The new client includes numerous performance and stability enhancements.
Major release 4.0.0 should be available by March-1-2013. This release will require that all plugin writers recompile their code. This version will minimally include full IPV6 support. Because network addresses are, in many cases, passed across plugin interfaces a recompilation provides the opportunity to verify that plugins are able to accept IPV6 addresses. Our current stand is to replace the use of sockaddr with a new class, XrdNetAddr, that provides format independent information about an IP address. Plugin writers that wish to make minimal modifications to their code can use the following code:

Originally:
```
extern "C" myplugin( ..., ..., sockaddr *sockP, ..., ... )
          { plugin body }
```
Relese 4.0.0:
```
extern "C" myplugin( ..., ..., XrdNetAddr *netaP, ..., ... )                                               
        {struct sockaddr *sockP = netaP->Sockaddr();
         plugin body
        }
```
On the other hand, we expect plugin writers to fully exploit the features of XrdNetAddr as it provides a format independent way of handling all types of network addresses.
We have revised the code release schedule to be more practical. Release rules are:
- Patch releases will be released as soon as demand requires. We do not expect this to be more frequent than once a month and typically quarterly.
- Minor releases (i.e., those where the middle digit changes) will be released no more than every four months and typically only twice a year. Target dates are March, optionally in June, and one in October.
- We have not decided on the schedule of major releases (i.e., those where the first digit changes) but will likely be no more frequent every two years.
We now have formulated a policy on binary compatibility. The policy is:
- We guarantee that all public class interfaces are binary compatible for patch as well as minor releases.
- Public interfaces are defined as those interfaces for which we have installed include files in “/usr/include/xrootd” and whose implementation is located in “libXrdUtils.so”.
- The shared library implementing public interfaces will not change versions across minor and patch releases to allow plug-ins to function without re-linking or re-compilation. Version information for other libraries may change across minor releases.
- Use of classes not considered public is discouraged and we will make no attempt to keep binary compatibility for those classes. However, we will make a best effort to indicate when we have broken compatibility in the release notes.

Release announcement - 3.2.1

xrootd-dev@slac.stanford.edu (XRootD Developers) — Sat, 12 May 2012 00:00:00 -0700

Release announcement - 3.2.1

The XRootD 3.2.1 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Warning for sites upgrading to 3.2.x

xrootd-dev@slac.stanford.edu (XRootD Developers) — Fri, 11 May 2012 00:00:00 -0700

Warning for sites upgrading to 3.2.x

There was a bug found in the FRM mechanism, such that attempts to stage-in missing files upon open() or via xrdstagetool will hang. Sites using the frm for real-time staging should stick with the 3.1.1 release.

Release announcement - 3.2.0

xrootd-dev@slac.stanford.edu (XRootD Developers) — Tue, 24 Apr 2012 00:00:00 -0700

Release announcement - 3.2.0

The XRootD 3.2.0 release has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the stable yum repositories.

Warning for sites upgrading to 3.1.0 or higher

xrootd-dev@slac.stanford.edu (XRootD Developers) — Thu, 19 Apr 2012 00:00:00 -0700

Warning for sites upgrading to 3.1.0 or higher

XRootD releases 3.1.0 or higher use extended attributes to record special meta-data information. If your file system does not allow extended attribute (see note 2) and you are using multiple partitions, all new file creation requests will place the file data in the name space partition. This will likely fill up this partition and make space recovery much more difficult unless you are using extended architecture (XA) space partitions (see note 3).
The only way we have discovered to make sure that your file systems support extended attributes is to specify that you want support in /etc/fstab by addning the user_xattr option as follows:
```
/dev/partition /mount fstype defaults,user_xattr 1 2
```
Make the appropriate substitutions for partition (e.g hda3), /mount, and fstype (e.g. ext3, ext4, xfs, etc). After you make the change your can remount the file system as root by issuing:
```
 mount -o remount /mount
```
If you are running with multiple partitions and use the oss.cache directive without the xa option, (e.g. oss.cache public /data1) you are running with non-XA spaces. Non-XA spaces severely limit how space is managed by xrootd. You should strongly consider either migrating to an XA-space or adding the oss.runmodeold directive to your configuration file in order to run in backward compatibility mode. Failure to do so before restarting a new version of xrootd will make future conversions more difficult.
Please read the “Migrating to Extended Attribute Name and Data Spaces” guide: http://www.xrootd.org/doc/prod/frm_migr.htm#_Toc284350518 before you run servers using release 3.1.0 or higher and if any of the following are true:
- Your configuration file contains an oss.cache directive,
- You have specified the migrate, purge, or stage option on any all.export directive, or
- You have pinned or memory mapped any file.
If you do use a non-XA space we strongly recommend that you convert to an XA space as soon as possible. While not specifically noted in the migration guide, you must change all oss.cache directives to oss.space directives after you do a space conversion.

Release candidate announcement - 3.2.0-rc1 (26-March-2012)

xrootd-dev@slac.stanford.edu (XRootD Developers) — Mon, 26 Mar 2012 00:00:00 -0700

Release candidate announcement - 3.2.0-rc1 (26-March-2012)

The XRootD 3.2.0 release candidate 1 has been tagged. Please follow the links below for the source and the RPMs. Please note that the RPMs have been pushed to the testing yum repositories.

Collaboration Meeting Minutes (14-March-2012)

xrootd-dev@slac.stanford.edu (XRootD Developers) — Wed, 14 Mar 2012 00:00:00 -0700

XRootD Collaboration Meeting held at CERN 14-March-2012

Attendees:

Doug Benjamin (Duke)
Dirk Duellmann (CERN)
Gerardo Ganis (CERN)
Andrew Hanushevsky (SLAC)
Lukasz Janyst (CERN)
Danila Oleynik (JINR)
Andreas Peters (CERN)
Artem Petrosyan (JINR)

Discussion Topics (No particular Order)

New Client status

Mostly done but some functions are not yet implemented, more work on proper timeout handling is needed and the client relies on the use of root’s TTree Cache.
We discussed some pressing requirements desired by all of the experiments, especially in a federated environment. We decided that the priory would be:
- Timeouts for single source reads with a switch to another server (about 3 months) and
- Multi-source random reads with single source timeouts driving it (about 6 months).
There was a lot of discussion on how to transition to the new client. Specifically, just give people a deadline to move, support the old client indefinitely (only serious bugs fixed), provide an old-style client wrapper to the new client.
There was some agreement but no consensus. It’s still not clear how difficult it would be to devise an old wrapper for the new client to ease transition. With no wrapper, we would set a 2 year timeline to switch to the new client when it is released. We would likely support the old client for two years after that with no upgrades and only fault conditions fixed. Everyone thought this was reasonable but yet fully flushed out to commit to this scenario.

xrdcp

As part of the move to the new client, the front-end to xrdcp is completely revised in a way that can be used by the old client and the new one. This provides the identical user interface regardless of which client is being used (deemed a requirement).
Creating a new interface that uses common interface standards proved to be challenging as the old interface used some esoteric conventions. The solution was to support the esoteric as legacy options but otherwise just document the “standard” option list.
One conflict arose that was not clear how to fix and that was use of the -force option to allow the client to try the copy for about a week before giving up. We decided it wasn’t worth keeping but we should check.
Action Item: AH will e-mail Costin about whether the -force is still needed.

Versioning

Once we switched to using shared libraries, corresponding to EPEL guideline, people not using RPMS have had problems mixing and matching executables with the correct library versions.
We decided that the real problem was that we didn’t have a fool-proof mechanism to determine when a shared library evolves in a binary incompatible way.
Action Item: LJ will bump the so name for every master release. No binary incompatible changes will be accepted to patch releases.

Git hub

There was a long discussion of whether to move the project repository from SLAC to GitHub. It would raise visibility but that brings its own set of issues. The new client is already there. We decided to continue internal discussions at each of our respective sites to determine the ups and downs of such a move.

Monitoring

Discussion of how work would be split between JINR and UCSD. The approach is that, by large, JINR will focus on summary monitoring with some detail traffic included (e.g. file copy records). UCSD would concentrate on detailed monitoring.
There is some overlap and it’s not clear how we handle that. Specifically, we need plug-ins for rending agents (i.e., ganglia, Mona Lisa, etc) and plug-ins for monitoring record storage (i.e., Cassandra, root, etc). What was recognized is that for this to work smoothly, a common record format must be developed for each set of plug-ins.
Action Item: AH will ask Ian Bird for standard monitoring record format document circulating in the WLCG. As we are moving in the direction discussed at the Lyon Federation Workshop, it would be good to use the format if possible.

Third Party Copy Status

The server-side of 3rd party copy works and we need xrdcp to provide the correct cgi information to trigger the copy. This is tied up with the new xrdcp front-end (see above). It should be done within a month.
The interface is http friendly so it can be carried forward to http servers as well.
While there was a lot on interest from Atlas and CMS, that has waned with only Alice and CMS/Castor expressing great interest. So, we move forward.

Licensing

We decided that we would move our license to an LGPL model on the next release, subject to the action items below.
Action Item: LJ will provide the license text (done).
Action Item: AH will consult with SLAC lawyers to get this moving to completion.

Logging

This issue surfaced once again, triggered by RAL’s interest in deploying xrootd for a large project. We decided to address the concerns by:
Action Item: AH will put in support for the logrotate command for sites wishing to use this mechanism as opposed to the native mechanism.
Action Item: AH will factor in the desire to have machine parse able logs vs. human readable logs. This is always a problem with tensions between large sites and small sites. It may be possible to include key-value information as an option. This is clearly tied into the larger project of redoing log messaging.

RPM’s in Epel & OSG

We’ve always had historical tensions on where and how distributes RPM’s. Some rely on the EPEL repository while others on the OSG repository which is identical to the official RPM’s are hosted at SLAC.
To make things go smoother, LJ got the appropriate accounts to create fedora builds and make RPM’s compatible with EPEL. This should be done in 2-3 weeks. This will likely remove OSG out of the loop. However, OSG does the DSI plug-in packaging. So, this may be a stumbling block.
Action Item: LJ should become EPEL package co-owner to speed package deployment.
Action Item: AP will provide the DSI plug-in for RH6 (OSG does not) and as a separate RPM. This will provide a smooth transition.

Python vs Perl

Recently, a user got an unsupported Python binding to the xrootd API and implemented site critical services with it (never mind that was bad form). In the latest release, that binding no longer works because we moved some API’s to different libraries to solve other problems. Now, we are getting requests to resolve this problem. We have a Perl binding and feel that we cannot continue to support both. The group preferred the Python bindings.
Action Item: AH will mail to xrootd-l asking which one we should support. Ask who uses what and indicate we can only support one.

IPV6

While we see the world moving to IPV6 we see that movement so slow that this appears to not be a critical issue at this time. However, we decided to start putting in the basic blocks to make a smooth transition.
Action Item: AH will create a new IPV4/6 XrdNetAddress class and integrate it in the current code (it’s a significant effort). This will provide a firm foundation for LJ to do the development. Our time-line for full IPV6 support is 3Q 2013.

Simple Example Configurations

Many people have requested simplified templates for configuration files dealing with a simple site.
Action Item: DB will head this up.

Xrootd Protocol Plugin

GG requested that an so version of the xrootd protocol be created so that he could use it as a plug-in. We agreed that we would build an so version of the protocol as this is pretty trivial to do.

Miscellaneous

Action Item: LJ will create an automatic monthly telecom reminder e-mail. We will have a telecom only if there something we need to discuss as a group.

Next Meeting

Next collaboration meeting will be held at CERN during the week of June 11th (in conjunction with Atlas software week). LJ will get a phone bridge going so other can remotely attend.