is available on ICR, if that's what you're asking.  We didn't list every single container in the announcement because, well, there are a lot of them

Community images are published to DockerHub, as is the longstanding practice. Docker is currently semi-retiring their old "store" portion of DockerHub leaving a confusing interface to find our containers.  We expect that Docker will clear this up in the next few months.

In the meanwhile, you can easily find InterSystems community containers via the InterSystems Organization on DockerHub:

As is our long standing practice, preview releases are taken down once a GA release is available.  We currently have the following versions available on IRC:  2019.1.3.722.0, 2020.1.3.521.0, 2021.1.2.338.0, 2021.2.0.651.0, 2022.

Unfortunately, we do not have a workaround for Docker's breaking change included in 2022.1.  The instructions in my Docker post should still be followed.

The OpenTelemetry collector should be able to collect metrics from the IRIS metrics API as well as the structured logs from the logdmn.  I don't have a working example configuration file to show you yet but I expect to have one by June 20th.  

As for a completely shameless plug here for my session on Observability in IRIS at Global Summit, I'm planning to cover the pillars of modern observability stacks, how IRIS fits into them.  At the moment, I'm still deciding which commercial stack to demo (DataDog, perhaps?).  I'll also be covering SAM, recent & future updates,  and how it fits into the bigger observability picture

In Embedded Python, exceptions flow back-and-forth between ObjectScript and Python as you'd expect. 

If your Python code raises an exception, but does not handle it, then the exception is passed to the ObjectScript side.  And vice-versa.  In your example, I'm not sure why you're handling the exception in python and then returning an exception object to the caller.  Why not just not catch the exception and let it get passed along to the ObjectScript side?

I like to bake the timezone into the container when I build it.  That way it'll have the correct timezone no matter where I run it.  Here's an example Dockerfile based on the latest IRIS container that sets the container's timezone to Pacific (aka America/Los_Angeles).

FROM intersystemsdc/iris-community
USER root
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && \
    apt-get install -yq tzdata && \
    ln -fs /usr/share/zoneinfo/America/Los_Angeles /etc/localtime && \
    dpkg-reconfigure -f noninteractive tzdata
USER irisowner

You can then do a docker build . to create the container, docker image ls, and docker run

Yes, IKO provided support for a simple IRIS topology where all Compute (ECP clients) nodes are the same, as are all data (shards), and all web gateways.

IKO is a tool that simplifies common deployments of IRIS in Kubernetes.  It takes your description of your irisCluster and creates the base kubernetes objects needed to support that deployment (a real lifesaver for sharding/mirroring deployments).  You can always see what IKO created and use that as inspiration for creating your own YAML to deploy IRIS in your kubernetes environment.

The IKO container is distributed as both part of the IKO distribution and via the InterSystems Container Registry.  For most users, the right answer is to just point to the container in ICR.  We mention this in the documentation here:

If you have your own container registry you can push the container there.  The error message provided looks like you're trying to add it to docker hub and getting permission denied.