#Google Cloud Platform (GCP)

Now Under Heavy Rotation, Your IrisCluster Secrets

A few days before Kubecon, the external-secrets-operator went GA with 1.0.0 and is set to ride shotgun for Kubernetes Secrets Management and put Vault in the backseat.  You can glance at the "Providers" list for the solution and immediatley understand that you can leave the "which Secrets Manager" conversation to others while you do your job utilizing external secrets on your IrisCluster workloads, which by my count with the operator and a single IrisCluster is more than a fistful of secrets of different types, even under a single tenant.  So let them sprawl, the secrets managers that is, not the secrets.

Real Time FHIR® to OMOP Transformation

This part of the OMOP Journey,  we reflect before attempting to challenge Scylla on how fortunate we are that InterSystems OMOP transform is built on the Bulk FHIR Export as the source payload.  This opens up hands off interoperability with the InterSystems OMOP transform across several FHIR® vendors, this time with the Google Cloud Healthcare API.

Google Cloud Healthcare API FHIR® Export

Kamino for IrisClusters

If you are in the business of building a robust High Availability, Disaster Recovery or Stamping multiple environments rapidly and in a consistent manner Karmada may just be the engine powering your Cloning Facility.

A step by step implementation path to a cross regional stretched IrisCluster with Mirroring using the Intersystems Kubernetes Operator (IKO), Google Cloud Platform, and Tailscale.

I am giving this distraction the code name "Compliment Sandwich" for a reason yet to be realized, but I'd rather the community go right for the jugular shooting holes in a solution that implements wireguard based connectivity for our workloads in general, as I would like to refine it as a fall project leading up to KubeCon in Atlanta and if I miss the mark, Ill get it done before Amsterdam. 

I’ve been exploring options for connecting Google Cloud Pub/Sub with InterSystems IRIS/HealthShare, but I noticed that IRIS doesn’t seem to ship with any native inbound/outbound adapters for Pub/Sub. Out of the box, IRIS offers adapters for technologies like Kafka, HTTP, FTP, and JDBC, which are great for many use cases, but Pub/Sub appears to be missing from the list.

Has anyone here implemented such an integration successfully?

For example:

Another step in this implementation path, adding cross cloud, cross regional stretched IrisCluster with Mirroring + Disaster Recovery using the Intersystems Kubernetes Operator (IKO) and Tailscale

Though trivial, Id like to go multi-cloud with the stretched IrisCluster for a couple of reasons to socialize the power of Wireguard when it supplies the network for a properly zoned IrisCluster by adding another mirror role to Amazon Web Services in the Western United States based datacenter in Oregon.

Background

For a variety of reasons, users may wish to mount a persistent volume on two or more pods spanning multiple availability zones. One such use case is to make data stored outside of IRIS available to both mirror members in case of failover.

Unfortunately the built-in storage classes in most Kubernetes implementations (whether cloud or on-prem) do not provide this capability:

• Does not support access mode "ReadWriteMany"
• Does not support being mounted on more than one pod at a time
• Does not support access across availability zones

Hi,

I tried to create a client for Google Cloud Storage using a private endpoint.

like this:

S client=##class(%Net.Cloud.Storage.Client).%New()

S sc=client.CreateClient("",2,credentialsFile,"",.out,privateEndpoint)

But privateEndpoint seems not to be used when trying to send blob from a file:

D sc.UploadBlobFromFile(bucketname,blobname,filename)

We can see at the firewall that the client still tries to use the public endpoint for GCS.  

Even if the private endpoint is definitely reachable.

When we allow the public endpoint in the firewall then it is working as expected.

Google Forms is the most popular solution on the market for collecting data, answering questionnaires and quizzes. So, it is the ideal solution for collecting patient data and responses in a practical way, without the need to expand or develop systems. In this article, I will detail how to create an account on Google Cloud, register the application that will consume the Google Forms API, generate the service user necessary to consume the API and finally perform actions to create new forms and collect data filled in them in an automated way in embedded Python and IRIS.