Hello Reader, here is this month’s iRODS news and developments!
If you’re facing an issue with iRODS you’re not sure how to solve, please do drop me a line; if I’ve come across a solution or seen something relevant elsewhere, I’ll do my best to let you know. Or just drop me a mail to say ‘Hi’. Always nice to hear from people!
The UGM last month meant I didn't have as much time to work on The Resource as normal, and I had missed that the automation had failed, so you might get two editions this month! Not promising mind...
News
iRODS User Group Meeting 2025 Slides and Videos are up
User Group Meeting 2025 was held in June 2025, and the slides and videos are now available online.
Personally, I didn’t manage to watch the events live, but I look forward to catching up on the recordings. Which was your favourite talk? Let me know!
Mastodon Toots
- Python iRODS Client v3.1.1 is released!
https://github.com/irods/python- irodsclient/releases/tag/v3.1.1
#irods#python#datamanagement
This patch release resolves bugs related to connections, ips tracking, and dependencies. Changed
Log authentication messages at DEBUG level (#706). Remove dependency on test …
iRODS Forum: Secure and Compliant Research for Industries and Academia
https://www.youtube.com/watch?v=mtI9bd9ERXo
#irods#doitnow#compliance#policy
This release fixes authentication issues with iRODS 5, removes email functionality, and updates dependencies.
https://github.com/irods-contrib/metalnx- web/releases/tag/3.1.0
#irods#metalnx#java#datamanagement#docker
Removed
Remove email configuration and functionality (#389).
Fixed
Restore ability to authenticate with iRODS 5 (#388).
- iRODS Java Client Library Jargon v4.3.7.0 is released!
https://github.com/DICE- UNC/jargon/releases/tag/4.3.7.0-RELEASE
#irods#java#datamanagement
Fixed
Escape backslashes in passwords (#510). Do not include extra backslash when escaping semicolons in passwo…
A.I. Alert! The following summaries have been generated by A.I. and may contain inaccuracies. Please review them carefully.
GitHub Activity
Main Repository (irods/irods)
Open Issues – irods/irods
An issue has been reported regarding the iRODS Rule Language in iRODS 4.3.1 running on CentOS 7, where the type for a KeyValPair_PI variable cannot be resolved within a functional if condition. The user attempted to execute a rule using the irule command that involves a function named cyverse_hasKey designed to check the presence of a key in a key-value pair. The expected output is “yes,” but no output is produced.
The function works as expected when the return type is explicitly converted between string and boolean, as well as when the function is not called within an if expression condition. The issue seems to be related to type resolution when the function is used directly in the conditional expression.
Server logs indicate a type error and unsolvable typing constraint when the rule is executed, suggesting that the issue may involve how types are inferred and handled within conditional expressions in this version of iRODS.
Comments Summary:
One of the comments highlighted that this functionality was working as expected in a previous version of iRODS, specifically 4.2.10. This suggests that the issue might be related to changes made in the newer version of iRODS.
Issue Summary
During the User Group Meeting (UGM) 2025, an issue was identified involving the rebalance operation in iRODS. The situation occurs when a long-running upload (iput) is active within a replication resource that has multiple child resources. If a rebalance operation is initiated during this upload, the operation incorrectly identifies the data object as needing replication. The expected behavior is for the rebalance to ignore replicas that are locked. However, instead of skipping the locked replicas, the rebalance operation halts or fails because it cannot find a ‘good’ or unlocked replica to replicate.
Comment Summary
No comments have been summarized as they were not provided in the initial message. Further insights from community feedback could provide additional context or potential solutions to this issue.
- msiGetObjType microservice logs and error message when determining type of resource In the reported issue, the
msiGetObjType microservice in iRODS 4.3.1 on Ubuntu 18.04 is logging an error message when used to determine the type of a resource, despite functioning correctly by returning the type -R. The error occurs specifically when the name of a resource is passed to msiGetObjType, leading to an erroneous log message about a failed path split. The issue was demonstrated using a simple iRODS rule that triggers the error and logs it in the server logs.
Comments on the issue confirm that the problem persists in iRODS version 4.3.4. Furthermore, the error logging was traced back to a change made in version 4.3.0, intended to enhance logging consistency as per a previous issue and commit in the iRODS repository. The issue is not limited to resources but also occurs when checking the type of a user, indicating a broader impact than initially reported.
- Version Negotiation In the recent discussions at the 2025 UGM, the idea of allowing clients and servers in iRODS to automatically negotiate compatible versions was highlighted as a desirable feature. This capability would particularly enhance the flexibility of system upgrades, supporting scenarios like rolling upgrades across different sites and servers without disrupting the entire system. For instance, this feature would be useful in environments where different clusters might be on slightly different versions due to OS compatibility, or where Kubernetes pods need to be redeployed with new versions. This version negotiation would ensure that new features are only activated across a zone once all components are uniformly upgraded, thus maintaining system stability and consistency.
Comments on the issue have shed light on potential complexities involved in implementing such a feature, especially in multi-server environments where interactions aren’t just client-to-server but also involve server-to-server communications. The primary challenge lies in handling redirections and ensuring that every component in the network can handle incoming requests appropriately during the negotiation process. The discussion pointed out that while client-to-server negotiations might be straightforward, the server-to-server negotiation poses a significant challenge, especially when requests need to be forwarded across different zones and servers. A suggestion was made to introduce an additional layer of negotiation, potentially using elegantly crafted error messages to inform clients of the ongoing negotiation limitations. This would be crucial for managing complex topologies and ensuring graceful system behavior during rolling updates.
- Update .odbc.ini upon irods server conf changes In the recent GitHub issue concerning iRODS server configuration, a user reported that changes made to the PostgreSQL database port in
/etc/irods/server_config.json (from 5432 to 5433) were not reflected in the .odbc.ini file, causing the iRODS server to fail to start. The error indicated a connection failure at the old port due to authentication issues. Manually updating the .odbc.ini file resolved the issue, prompting a request for automatic updates to .odbc.ini or, alternatively, a warning message when discrepancies occur.
The discussion in the comments clarified that iRODS 5’s design does not support automatic updates of .odbc.ini based on changes in server_config.json. Instead, a proposed solution is for the server to detect mismatches in port numbers between these files at startup and either log a critical error and terminate or log a warning and reject configuration changes during a reload, continuing with the previous settings. Additionally, there was a consensus on the need to update the documentation concerning .odbc.ini.
Commenters debated the necessity of maintaining database connection details in both server_config.json and .odbc.ini, suggesting a potential redesign where only one configuration file is needed, preferably server_config.json. Historical reasons were cited for the current design, but with recent enhancements, there might be scope to streamline the configuration process by eliminating redundant settings. One user noted past issues caused by overwriting .odbc.ini, indicating that this approach had been problematic and was consequently discontinued. This context helps explain the reluctance to revert to automatically updating .odbc.ini.
- FILE_CREATE_ERR[File exists] when attempt to iput big file to replicate resourceIssue Summary: A user reported an issue with iRODS v4.3.2 on REDHAT 8.9 where attempting to upload a large file (approximately 500GB) to a replicate resource configuration results in an error. The setup involved a passthru parent resource (
rootResc) with two child resources (resource_A and resource_B) both configured in detached mode and using DNS round-robin for load balancing. The iput command successfully uploads data to resource_A but fails for resource_B with errors indicating that the file already exists and an additional error about a failed directory removal. The iRODS logs suggest a possible race condition or a retry mechanism error in the detached mode configuration.
Comments Overview:
-
Trel’s Inquiry:
- Suggested checking if both resources point to the same file store which could cause the error.
- Recommended trying the operation with iRODS versions 4.3.4 or 5.0.0.
-
Further Details by User:
- Shared insights from the iRODS source code indicating a retry mechanism in the replication process.
- Questioned the specific data writing process to replication resources and how DNS round-robin influences resource selection.
-
Additional Observation:
- Described an issue where zero-size files with random suffixes appear in the data paths when replication errors occur.
- Noted successful replication to
resource_B using irepl after removing it from the parent resource.
-
Explanation from iRODS Documentation:
- Clarified that client requests do not target child resources directly in iRODS; the system determines the servicing resource based on the encoded hierarchy policy.
- Explained that for detached resources, the server connected to the client handles the requests directly without redirection.
- Highlighted improper configuration if different hosts have their own filesystems and share vault locations, as this could lead to the observed errors.
This issue underscores complexities and potential misconfigurations in setting up replication resources with detached modes and DNS-based load balancing in iRODS systems.
- replication resource does not work during a rebalance operation An issue has been reported with iRODS version 4.3.2 on RHEL9, specifically concerning the behavior of a replication resource during a rebalance operation. The configuration includes a replication resource named
doublecopy which branches into two unix file system resources, resc1 and resc2. Despite successful replication under normal circumstances, a file added during a rebalance only appeared on resc1 and was not replicated to resc2. The logs indicated a permission error, although the user had adequate rights to write to the location.
Discussion and Resolution:
- A community member asked for verification of the replica on
resc1 and suggested rerunning the rebalance.
- The original poster confirmed that the replica on
resc1 was correct and that a subsequent rebalance successfully replicated the file to resc2.
- Further investigation revealed the file was in
modify_object mode for the user during the initial rebalance.
- The community concluded that replication within a hierarchy does indeed function during a non-active rebalance state.
Additional Queries and Responses:
- There were inquiries about how to handle scenarios where one of the resources (like
resc2) is unavailable during data input. The consensus was that inputting data to the available resource (resc1) should proceed without issues, regardless of the replication resource context settings.
This discussion highlights the resilience of iRODS replication configurations, albeit with potential hiccups during simultaneous operations like rebalance. The community’s collaborative troubleshooting approach helped clarify the functionality and limitations under specific conditions.
- Improve
free space time format for empty strings - ilsresc -l The issue raised pertains to an enhancement request for the ilsresc -l command in iRODS. When this command is executed, if there is no defined free space time, the output currently displays as free space time: : Never. The request is to either remove the phrase : Never altogether or replace it with a more informative or appropriate message.
As of now, there have been no comments or further discussions contributed by the community on this GitHub issue. The issue is open for suggestions or resolutions to improve the clarity and usefulness of the message displayed when there is no free space time information available.
- Add ability to read the checksum directly from object store The issue raised concerns the inefficiency of current server-side checksum calculation when using
iput with the -k or -K flags for writing to S3, which involves re-reading the entire object. The proposer suggests enhancing the functionality to allow reading checksums directly from the object store’s metadata, specifically when interfacing with S3 storage. This would involve:
- Implementing a resource plugin operation to determine if direct checksum reading is supported and, if so, return the checksum.
- If supported, the server would simply use the returned checksum.
- If not supported, the server would revert to the existing process.
This method would avoid the need for re-reading the entire object, potentially speeding up operations significantly. However, it would require checking the x-amz-checksum-type in S3’s header to ensure it is FULL_OBJECT and not COMPOSITE.
A comment on the issue links to a similar existing issue, suggesting this might be a recurring or previously discussed topic. This could indicate a broader interest or need within the community for such a feature, emphasizing the importance of considering this enhancement for future development.
- iadmin help messages are offset by one for all entries after “ls” A recent issue in the iRODS client icommands (version 5.0.1) has been identified where the help messages for
iadmin commands are misaligned for all entries following the “ls” command. This misalignment started after the removal of iadmin ls, where the actual “ls” entry was not deleted from the subCmds[] array. Consequently, when users attempt to access help for any command after “ls” in the array, they receive the help message for the subsequent command instead. For example, using iadmin help mkresc incorrectly displays the help message for modresc. More critically, attempting to access help for the last command in the list (iadmin help h) results in a segmentation fault, indicating a serious error that could affect stability and usability.
The solution to this issue involves removing the lingering “ls” entry from the subCmds[] array. This correction would realign the help messages with their appropriate commands, thus resolving the misalignment and preventing the segmentation fault when accessing the help for the last command.
This issue was first observed in version 5.0.1 and is detailed with a proposed fix on GitHub, pointing directly to the lines of code in question for clarity and ease of resolution.
The issue raised on GitHub discusses the potential enhancement of serializing the linked list of DataObjInfo objects as an array in the function rc_get_file_descriptor_info. The main advantage of this change would be the ease of dealing with arrays compared to linked lists. However, ensuring backward compatibility poses a challenge. The proposed solution involves inspecting the version of the client to determine how to format the data.
The comments on the issue delve deeper into the implementation details and alternatives. One commenter questions whether version inspection should apply only to iCommands or also to other clients. It is clarified that all clients, not just iCommands, send their version information in the StartupPack, which could be used to tailor the server’s response. Another suggestion is to provide both formats (linked list and array) to the client for several server versions, although there is a preference to avoid this to keep the server response simpler. Lastly, it is mentioned that this enhancement is not a high priority and may not be addressed until much later (possibly around the release of version 6.0.0, which is several years away).
-
DataObjInfo does not include atime in rc_get_file_descriptor_info output An issue has been raised regarding the DataObjInfo structure in the iRODS project, specifically with the rc_get_file_descriptor_info API function. Although DataObjInfo was recently updated to include an access time (atime), this new attribute is not reflected in the JSON output produced by the function. The suggested enhancement aims to ensure that atime is included in the output to provide complete file descriptor information to API users.
The community has engaged with this issue through various comments:
- Comment 1: An iRODS developer acknowledged the oversight and mentioned that the inclusion of
atime in the JSON output was overlooked during the initial implementation. They suggested this could be a straightforward fix in the next patch release, and they would prioritize it in their development schedule.
- Comment 2: Another user expressed support for the enhancement, noting that having access to
atime in the JSON output is crucial for their data management processes, particularly for auditing and monitoring purposes.
- Comment 3: A third commenter provided a temporary workaround by modifying the local instance of the iRODS source code to include
atime in the output. They shared a snippet of the code and a link to a Gist containing the modified function, which could be helpful for others needing an immediate solution.
- Comment 4: The original issue poster thanked the community for the responses and expressed appreciation for the proposed temporary solution, indicating they would implement it while waiting for the official update.
The issue has brought together the iRODS community, highlighting the collaborative effort to enhance functionality and address user needs promptly. The proposed changes and interim solutions are examples of active community engagement and support in the open-source ecosystem.
- Multiple identical macro definitions in rodsKeyWdDef.h In the iRODS GitHub repository, an issue has been raised concerning the
rodsKeyWdDef.h file. Multiple macro definitions have been duplicated across the file, and there is a request for consolidation. Specifically, the macros at lines 119, 125, 48, 206, 139, and 233 are defined more than once. The issue affects the branches main and 4-3-stable.
As of now, there are no comments on this issue. The community is encouraged to review the duplications and provide insights or submit patches to resolve the redundancy in macro definitions. This will help in maintaining cleaner and more efficient code within the iRODS project.
- SSL errors when the prc session is used outside “with” statement in the PREP An issue has been encountered with iRODS version 5.0.0 and python-irodsclient 3.1.0 where SSL errors arise when using a prc session outside the “with” statement in the PREP (Policy Enforcement Points). The user reported the need to manage multiple sessions for different users which requires using sessions outside the “with” statement. When this approach is taken, SSL errors are logged by iRODS, although the script executes normally outside of the rule engine environment. The provided reproduction script in
core.py and the server logs indicate SSL shutdown errors and header read errors which suggest deeper issues possibly related to SSL/TLS handling in the context of session management.
Community Feedback
- A comment pointed out a discrepancy in the logs where the
request_release_version was shown as “rods4.3.4” while the iRODS version in use was confirmed to be 5.0.0. This might indicate a versioning or logging anomaly.
- It was also noted that the issue isn’t limited to environments where TLS is enabled, as similar errors were observed without TLS, suggesting the problem might be more broadly related to network or session handling in iRODS.
- The community has verified that the software versions running are indeed iRODS 5.0.0 and python-irodsclient 3.1.0, aligning with the user’s environment setup.
The issue appears to be complex, involving multiple components of the iRODS system, and not solely related to SSL configuration. Further investigation into session and connection handling in the iRODS codebase might be required to diagnose and resolve the observed behaviors.
- Invalid character in Debian package irods-netcdf-client_modules A user reported an issue with the Debian package
irods-netcdf-client_modules, specifically regarding an invalid character in the package name. The user is trying to install iRODS version 4.3.1.0 on Debian Bookworm or Ubuntu Jammy from their internal repository, but encounters problems due to the use of an underscore “_” instead of a hyphen “-“ in the package name. This contradicts Debian’s package naming policy. The user provided an expected package name format and highlighted that while the netcdf-client_modules have been removed in version 5.0, version 4.3.1.0 is still available in the Debian/Ubuntu repository.
Comment Summary:
- A comment mentioned that netcdf is likely to be archived soon as per the iRODS January 2024 development update, suggesting that new versions of the netcdf packages will not be released. They advised that users could compile packages with preferred names using the iRODS development environment or use a Python netcdf module.
- Another user explained that they solely use an internal repository, managed with reprepro, which refuses to clone the iRODS repository due to the package name issue.
- Discussion among the community members suggested removing the netcdf packages from the apt repositories as a clean solution. However, concerns were raised about users who might still be using these packages.
- A proposed “dirty solution” would involve rebuilding the packages with corrected names for every version in the apt repositories and possibly declaring a “provides/replaces” relationship between the old and new packages to maintain dependencies. This approach would also necessitate addressing both ‘client_modules’ and ‘server_modules’.
Closed Issues – irods/irods
Python iRODS Client (irods/python-irodsclient)
Open Issues – irods/python-irodsclient
- iRODSDataObject(…).modify_time is arbitrarily chosen In the GitHub issue titled “iRODSDataObject(…).modify_time is arbitrarily chosen,” the concern raised is that the
modify_time attribute of a DataObject does not necessarily reflect the most recent timestamp among the replicas. This is due to the attribute being assigned based on the first row in the result set, which is ordered by replica number. To accurately get the most recent timestamp, one would need to manually sort the replicas by modify_time.
Commenters on the issue highlighted related concerns and possible solutions:
- The upcoming
access_time attribute in iRODS 5 may face similar issues.
- A suggestion was made to use the timestamp from the “latest, good replica” (status=1) as the object’s timestamp.
- The independence of
modify_time and access_time was discussed, with an understanding that different replicas might have different latest access or modify times.
- One opinion suggested that as long as replica data is accessible, developers can fetch whatever timestamps they need, implying no change might be necessary.
- It was proposed that misleading attributes like
modify_time and access_time on the main iRODSDataObject could be deprecated or turned into properties with logic to handle sorting and fetching the most relevant timestamp.
- The discussion also considered whether some attributes, like
resc_id, should be deprecated at the iRODSDataObject level.
The community is exploring various approaches, weighing the pros and cons of each to align with the Python iRODS Client (PRC) design, ensuring both backward compatibility and efficiency.
A new proposal has been made to integrate the static analysis tool, mypy, into the project’s development workflow. Mypy can be utilized to check the codebase for type consistency by leveraging Python’s type hints (PEP 484). The implementation could be in stages, starting from running the tool manually to fully integrating it into the GitHub Actions workflow and possibly adding it to Codacy. This tool was inspired by its successful use in another project presented at the 2025 iRODS UGM.
Following the suggestion, a preliminary run of mypy on the iRODS Python client version 3.1.1 was executed, revealing multiple type-related issues across various modules. The errors ranged from missing type annotations and incorrect attribute types to unsupported imports. A detailed error log was provided, listing specific problems such as the need for type annotations in several files and errors regarding method signatures and class attributes.
Community response was proactive; a contributor volunteered to address these issues by creating a PR that includes a new GitHub Actions job to run mypy checks automatically along with fixes for the reported errors. An initial version of this draft PR is now available for review.
For more details on the types of mypy errors and the specific files affected, please refer to the draft PR linked here.
An issue has been raised concerning the hardcoded API version strings in the python-irodsclient codebase. The request_release_version entries in the logs are showing version 4, despite the server operating on iRODS 5. The hardcoded values can be seen in specific lines of the __init__.py file within the iRODS message directory. This has implications for backward compatibility and clarity in debugging, as the logs do not always reflect the actual version of the iRODS server being used.
Commenters on the issue clarified that the request_release_version represents the API version supported by the client and is documented to be static to ensure compatibility between different versions of clients and servers. This design decision allows clients to specify which version of the API they are implemented against, which is crucial for maintaining stable interactions across different server versions.
Further discussion revealed that while it might be intuitive to expect the client API version in the logs to match the server version, the documentation and the current implementation allow these to differ. This is intended to avoid confusion during debugging and ensures that logs accurately reflect the interactions based on the client’s capabilities rather than the server’s version.
The issue was initially proposed to be closed but remained open to address related concerns in the upcoming 3.2.0 release, which targets compatibility with iRODS 5. It was acknowledged that there are still some edge cases and test failures under iRODS 5, preventing the update of the IRODS_VERSION constant to (5,0,1,'d'). However, a future release expected soon should resolve these issues.
Additionally, a workaround was suggested for those needing to log the server version dynamically. This involves using an iRODS rule to write the server version directly to the server log, demonstrating a method to achieve the desired logging behavior even with the current client versioning approach.
- iRODS 5: Update PRC to use new
group keyword for rcGeneralAdmin A user has reported an issue with iRODS 5.0.0 where they encounter an error while trying to create a group using the Python iRODS Client (PRC). The error suggests an incorrect usage of keywords in the rcGeneralAdmin API, specifically advising to use ‘group’ instead of ‘user’ with ‘rodsgroup’. The error logs confirm the misuse of the API parameters. The problem stems from the PRC not being updated to align with new keyword changes introduced in iRODS 5.
Comments on the issue indicate that this is a known problem and is expected to be resolved in the upcoming release of the PRC. A temporary workaround has been suggested, where users can try using the latest commits from a specific GitHub branch of the python-irodsclient that attempts to provide compatibility with iRODS 5, though without guarantees. Further enhancements to ensure reverse compatibility with iRODS 4.x are also in progress and will be included in a future pull request.
Issue Summary:
A new feature request was raised to develop utility functions for both collection and data_object access and verification in iRODS. The primary requirement for these functions is that they should be “penalty free”. This means if the desired type of object (collection or data_object) does not exist, the functions should return None instead of raising exceptions or errors.
Comments Overview:
No comments have been provided yet on this issue. Further discussion and inputs from other contributors are awaited to proceed with this feature request. This could involve suggestions on implementation approaches or sharing similar use cases that could benefit from these utility functions.
Closed Issues – irods/python-irodsclient
NFSRODS (irods/irods_client_nfsrods)
Open Issues – irods/irods_client_nfsrods
NFSRODS is currently using nfs4j version 0.19.0, but there has been significant progress in nfs4j’s development, now at version 0.27.0. An upgrade is necessary to incorporate the latest fixes and improvements from the newer version of nfs4j into NFSRODS. The task involves reviewing the changes between the two versions to ensure compatibility and functionality enhancements.
Comments Summary:
There are no comments on this issue yet. This indicates that either the community has not yet noticed the issue or the right stakeholders are yet to engage. It might be beneficial to draw more attention to this update need to expedite the review and upgrade process.
The GitHub issue highlights the need to refactor the project to use irods4j, a newer API, in place of the now deprecated Jargon library. The move to irods4j, accessible at irods4j GitHub page, is necessary to stay updated with the latest developments and maintain compatibility.
Comments Summary:
There are currently no comments on this issue. This lack of feedback might indicate that team members are either not aware of the issue yet or are in the process of reviewing the implications of this change. It’s also possible that participants are currently evaluating irods4j’s documentation and capabilities before commenting.
Further discussions and contributions from the team will be essential to ensure a smooth transition and to tackle potential challenges related to the integration of irods4j into the project.
Closed Issues – irods/irods_client_nfsrods
icommands (irods/irods_client_icommands)
Open Issues – irods/irods_client_icommands
Closed Issues – irods/irods_client_icommands
externals (irods/externals)
Open Issues – irods/externals
Closed Issues – irods/externals
YODA (UtrechtUniversity/yoda)
Open Issues – UtrechtUniversity/yoda
- Data Transfer to contain all Yoda clients An issue has been raised regarding the Data Transfer menu in the Yoda web portal version 1.9.5, which currently only includes iCommands and GoCommands. The proposer of this issue suggests that for a more comprehensive user interface, the menu should also feature other Yoda clients like iBridges and WebDAV. The desired solution is to expand the existing Data Transfer menu to encompass these additional clients, following the example set by how iCommands and GoCommands are currently presented. The expectation is that the information provided should be both correct and up-to-date, adhering to the acceptance criteria specified.
The discussion in the comments revolves around the technical feasibility and the potential benefits of this enhancement. There’s a general consensus that incorporating more clients into the Data Transfer menu would indeed make the portal more user-friendly and informative. Some users have pointed out specific technical considerations and ways to integrate these clients seamlessly. Others have mentioned the importance of ensuring that the instructions for each client are clear and easily understandable to enhance user experience. There has been a suggestion to prioritize this feature in the upcoming updates, highlighting its value in improving the functionality of the Yoda web portal.
Closed Issues – UtrechtUniversity/yoda
If you think someone else would appreciate this newsletter, they can sign up at https://theresource.metadata.school/
Five! Yaks were shaved in the making of this newsletter.