Hello Reader, here is this month’s iRODS news and developments!
News
iRODS 4.3.1 is released!
release announcement
This release represents a steady improvement on 4.3.0's significant release last year. Most significantly, the memory leaks introduced with the new frameworks in 4.3.0 have been fixed alongside internal refactoring. Additionally, three new operating systems are now supported by our binary packaging.
Detached mode has been added to the unixfilesystem plugin which provides superior performance when working with parallel filesystems.
Additional machinery has been made available to control TCP Keepalive behavior, ticket administration, connection pooling, and authentication configuration.
Big news and congratulations to the developers!
A few issues I’ve picked out from the list below to prepare for if you are looking at upgrading;
- (Add log_level for sql to server_config.json file )[https://github.com/irods/irods/issues/7393]
- (the service account environment requires
irods_connection_pool_refresh_time_in_seconds to be set)[https://github.com/irods/irods/issues/7392]
iRODS Python Client Library v1.1.9 is released
v1.1.9
- [#471][#472] allow save, load, and autoload of configuration [Daniel Moore]
- [#456] auto-close data objects that go out of scope [Daniel Moore]
- [#455] remove ticket check [Daniel Moore]
- [#452] implement client redirection to resource server [Daniel Moore]
- [#455] introduce low level ticket api changes [Daniel Moore]
- [#234] Implement case-insensitive queries [Sietse Snel]
Especially interested to see the config loading section - will reduce boilerplate code!
iRODS Development Update - October 2023
Too much to summarise - go read it!
Main Repository Activity
Open Issues
This seems a great idea; do take a look if you work with compiling from source
At present, we increment the version number of the main branch to that of the next major release once it has diverged significantly from the current stable series branch. This means that the major release itself may not have a higher version number than a development build from the same branch from before the release. This poses a problem for packaging, as it may not result in a release taking priority over an older development build. In our stable series branches, we avoid this by incrementing version numbers just before release.
I am proposing that instead of incrementing to the next major release on significant divergence from stable, we follow the example set by Gnome and increment to a minor release with a value of .90 (ex: 4.3.90) and increment to the next major version just before release.
With this change to our versioning, downstream projects being developed side-by-side with iRODS will still have a version number to target, but we will not run into the version number precedent issue described above.
This change also comes with some additional benefits:
If a downstream project that inherits iRODS' version number is built against the main branch rather than a release, it will be evident in the version number.
When a user reports an issue with iRODS (or a downstream project that inherits iRODS' version number), we can tell from the version number whether they are using a development build from the main branch.
Related to the above
At present, we increment version numbers in project repositories just before a release. This is a good practice and we should keep doing this, as it ensures that a release version number will always be greater than one from a development build from after the previous release but before the release in question.
However, this also presents the challenge to downstream projects that are developed side-by-side with iRODS: How to detect that the version of iRODS being used or built against is a development version. In my opinion, it should not be up to the developer to tell the buildsystem what version of iRODS it is actually building against, nor should it be up to iRODS users to tell clients that the version reported by the iRODS server should be taken with a grain of salt.
I am proposing that we change how we handle version numbers for iRODS to resemble the even/odd pattern used by many other software projects: we will continue to increment the iRODS version number just before a release, but we will also increment the version number again post-release.
Closed Issues
Who wouldn’t be using ‘Minimum Space For Resource in Bytes’ if you have a unixfilesystem type resource! It’s a literal best practice mentioned in the documentation!
After re-reading the issue a few times, this was the pertinent section;
So the necessary conditions appear to be both using Python-irodsclient and setting minimum_free_space_for_create_in_bytes on unixfilesystem resources.
I think that this affects all versions of iRODS before 4.3.1 but was introduced at least after 4.2.7 (since I’ve been able to use the PRC on a 4.2.7 system but not tried the most recent PRC version). It would be excellent to know;
- what version this got introduced in.
- If the version of the PRC is related (i.e. can you use an earlier one? I think not, but…)
- If other APIs (e.g. C) are affected.
Note that stsnel has a workaround, but that involves using another system to monitor the free space and check that first, which… yay that they had this but most Zones won’t.
Trel does mention that
The workaround for using Python is to set the filesize to 0 when talking to a pre-4.3.1 iRODS server.
However, the documentation for the PRC doesn’t mention this, and it is not clear to me what effect setting the file size will have on other operations that might depend on it (e.g. it might try and create a file on a resource without sufficient space, or fail to recognise a partial upload?)
Hmm. I agree It’s hard to reproduce but by closing the ticket without a positive test and therefore knowing its working, It’s hard to know if we can continue to use that combination of commands.
Python iRODS Client Activity
Open Issues
Closed Issues
NFSRODS Activity
Open Issues
Closed Issues
Hurrah! This should make ips reporting more obvious.
If you are thinking of this, check out the note where Terrell explains how this can be done via NFS already.
icommands Activity
Closed Issues
externals Activity
Open Issues
Closed Issues
Closed on - 2023-10-09 16:38:10 Remove pistache
YODA Activity
Open Issues
Closed Issues
If you think someone else would appreciate this newsletter, they can sign up at https://theresource.metadata.school/
Just one Yak was shaved in the making of this newsletter.
