Containerization is a lightweight alternative to full machine virtualization that involves encapsulating an application in a container with its own operating environment.
I'm trying to deploy a python/flask application to an Iris4Health container (2025.1) but running into some issues with packages and where they should be installed.
Sometimes customers need a small IRIS instance to do something in the cloud and shut it down, or they need hundreds of containers (i.e. one per end user or one per interface) with small workloads. This exercise came about to see how small an IRIS instance could be. For this exercise we focused on what is the smallest amount of memory we can configure for an IRIS instance.Do you know all the parameters that affect the memory allocated by IRIS ?
I am brand new to using AI. I downloaded some medical visit progress notes from my Patient Portal. I extracted text from PDF files. I found a YouTube video that showed how to extract metadata using an OpenAI query / prompt such as this one:
In InterSystems IRIS 2024.3 and subsequent IRIS versions, the AutoML component is now delivered as a separate Python package that is installed after installation. Unfortunately, some recent versions of Python packages that AutoML relies on have introduced incompatibilities, and can cause failures when training models (TRAIN MODEL statement). If you see an error mentioning "TypeError" and the keyword argument "fit_params" or "sklearn_tags", read on for a quick fix.
The Istio Service Mesh is commonly used to monitor communication between services in applications. The "battle-tested" sidecar mode is its most common implementation. It will add a sidecar container to each pod you have in your namespace that has Istio sidecar injection enabled.
When setting up a new web app in iris (iris is in a container) iris complains that a WSGI framework is not installed. I have installed python into the container as well as both flask and django via the python virtual environment (see second screenshot) and the python language server is running
Is this the wrong way to install flask? How do I get the container version to recoginize that flask is installed?
https://www.youtube.com/embed/GUbe6Iwt9T4 [This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]
I recently had a company-enforced OS upgrade, and ever since going from mac OS 14.x to 15.x, I am currently having issues with SSL in IRIS.
An ARM (M3 pro) machine running OS 15.2, with the latest Docker Desktop (at the time of writing, 4.37.0). The Docker container runs IRIS for UNIX (Ubuntu Server LTS for x86-64 Containers) 2022.1.2 (Build 574_0_22161U). This container has not changed.
I'm trying to get the python external language server started up in a container I am starting. The container is up and running but I cannot get the python language server to start.
This is the error that is coming back when trying to start the language server. I have tried creating a custom image with that package installed but it still does not work. Is there something specific that needs to be done to to get this working? (FYI, I have the dotnet version working but creating a custom image and installing the dotnet runtimes via a docker file)
I'm discovering IRIS and I need to POC the solution, with a constraint: containerization. I'm used to deploy my apps in a Swarm cluster, and all my bind volumes are written on a GlusterFS volume.
The problem here, when I start my stack, the first log is:
[WARN] ISC_DATA_DIRECTORY is located on a mount of type 'fuse.glusterfs' which is not supported, consider a named volume for '/iris_conf'
Hi there, I'm wondering if anyone has run into an issue with <FILEFULL> when building an image from the ISC image? Specifically what's happening in our build is we are pre-loading our codebase into the image to make deployments faster and setting up source control, etc. When loading our libraries however we get hit with a <FILEFULL>. The resource limits on docker are pretty beefy and when observing resources on both the machine and container level we don't hit any issues. Oddly, this only happens when using the ARM64 version.
If you plan on using the nginx server to front end you IRIS instance (as opposed to the standard apache web gateway install) you will need to add a few configuration options into the CSP.conf file in order for all urls to work. It took me a little bit to figure this out but this seems to be the configuration that works.
https://www.youtube.com/embed/hALbMzols9o [This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]
It's not clear to me, when using the InterSystems Container Repository, which version is the best / most recent non-preview Community Edition version to use.
I see lots of 2023.2.x versions, a single 2023.3 and 2024.1 version, but also a latest-cd and latest-em (with no explanation as to what cd and em mean).
I assume the trick is to use one of the latest-xx ones? If so, which?
Unfortunately I haven't been able to find any explanatory information anywhere about the nomenclature conventions used.
A few weeks ago I posted an announcement about a JavaScript-based interface for our mg_web WebServer interfacing addon module. mg_web isn't just restricted to use by JavaScript developers though. Many readers will be ObjectScript developers who are more used to using CSP as their web gateway. Some may even have much older legacy WebLink-based applications (and be wondering how to support them given that IRIS does not support WebLink).
Kubernetes is an open-source container orchestration framework developed by Google. In essence, it controls container speed and helps you manage applications consisting of multiple containers. Additionally, it allows you to operate them in different environments, e.g., physical machines, virtual machines, Cloud environments, or even hybrid deployment environments.
In case you're planning on deploying IRIS For Health, or any of our containerized products, via the IKO on OpenShift, I wanted to share some of the hurdles we had to overcome.
As with any IKO based installation, we first need to deploy the IKO itself. However we were getting this error:
I want to address the nasty problems about reading a flat text in ASCII, UTF* explicitly excluding HTML, EBCDIC, and other encoding. According to Wikipedia there are at least 8 variations of control characters.
CR+LF is typical for Windows
LF is typical for the Linux/UNIX world
CR is Mac's favorite
As you can deduct from the names the inspiration comes from mechanical typewriters.
I have been struggling with a docker run command that kept crashing, the error message was too generic to point me to the right direction.
Since the container is shut down after the failure, I was unable to login to it in order to figure out the problem.
I had to run the container in a way that I'll be able to log into it before it crashed, so I found the adding -u false prevents the docker run command to run the iris session IRIS and the container stayed up and running. then I was able to log into it using:
I've been running IRIS in a container for a while with the durable %SYS feature. Previously, I was running IRIS 2022.x version and decided to upgrade to 2023.1. During image build, I create some namespaces and install a FHIR repo into one of them using the following script:
We are using IRIS health 2023.1 to build an application that runs on kubernetes cluster as container images. In the container image, we have our own PRODUCTION "APP" created with its routines database and global database located at:
By date
Open Exchange app.png)
