chgl

@johngrimes We ended up implementing: https://github.com/bzkf/fhir-to-lakehouse which is using the Pathling libraries instead of the server to do upserts and deletes - it turned out to be easier for our...

Thanks for sharing! I believe that would only address one Hapi fhir process with multiple threads, so no synchronisation across network boundaries unfortunately.

I deliberately proposed to be able to decouple image builds from releases in the repository back in https://github.com/hapifhir/hapi-fhir-jpaserver-starter/pull/217. That being said, I agree that this can be confusing since usually...

Would allowing to set annotations on the CRDs be another option (https://github.com/prometheus-community/helm-charts/issues/3548#issuecomment-1621222012) ? So something like: ```yaml crds: annotations: argocd.argoproj.io/sync-options: ServerSideApply=true ``` adds the annotation to https://github.com/cloudnative-pg/charts/blob/main/charts/cloudnative-pg/templates/crds/crds.yaml#L5.

I had to scour the source code as well, but here's a dummy that worked for me with a custom s3 endpoint: ```properties connector.name=storage hive.s3.endpoint=https://s3.example.com hive.s3.path-style-access=true hive.s3.region=eu-central-1 ``` (AWS_ACCESS_KEY_ID and...

You'll also need to set ```yaml global: security: allowInsecureImages: true ```

> I know I can achieve it with --readonly flag when running docker, but it's an opt-in, and can easily be forgotten. I think it would be much easier to...

:D sorry, I meant "enforce the use of running containers with a read-only file system using the container runtime's available settings", not doing it at the image level.

@joshuagrisham-karolinska I think ```yaml securityContext: ~ ``` should do the trick to remove the securityContext entirely from the pod spec. A solution that is backwards-compatible and maybe even nicer since...