Constant instability, Service unavailable errors, System cannot find the file specified.

[lynkz-matt-psaltis]

I'm trying to work out if this is specifically related to our machines, our setup using podman desktop or something else I haven't put my finger on.

Essentially how stable is everyone finding the Linux container for the CosmosDb emulator?
We're finding this causing daily impacts at the moment for team members. The windows emulator (non-container) seems to work much more consistently

It doesn't seem to be resources related (cpu/ram) are all in abundance and we're seeing this across a wide range of different hardware vendors.

I realise technical information is light on here and I will gather that, just trying to gauge if other people are pushing through the pain so to speak with this?

[razvangoga]

on what distribution are you? it has a known issue on ubuntu > 18

in general is, sadly, a buggy unmaintained mess... there is this issue rounding up all theproblems #86

[lynkz-matt-psaltis]

Thanks @razvangoga seems like a lot of issues we've experienced recently.

[lynkz-matt-psaltis]

Hosts are Windows 11 with WSL2 or Mac OS running podman desktop. Did you mean host distribution or cosmosdb docker image? I wasn't aware there are published images on top of other distributions for the docker image?

[razvangoga]

I've tried to use it on

• Win11 via Docker Desktop on WSL => usable but it's slow and sometimes unstable),
• MacOS on an M1 Pro via Docker Desktop : container starts ok but seems stuck on an internal starting loop => unusable
• Ubunutu 22 in an Azure Devops pipeline via Docker : container is unreachable => unusable

have not tried Podman, but i wouldn't put money on it working...

:(

[jahmai-ca]

I'm also struggling with the Linux container mostly in Azure devops pipelines on Ubuntu. I've been able to connect to it if I set the environment variable AZURE_COSMOS_EMULATOR_IP_ADDRESS_OVERRIDE=127.0.0.1 on the container definition, but it's still slow and gives random service unavailable and request timeouts making the pipeline job get killed at the 60 minute mark.

[adamzest]

I'm trying to work out if this is specifically related to our machines, our setup using podman desktop or something else I haven't put my finger on.

Essentially how stable is everyone finding the Linux container for the CosmosDb emulator? We're finding this causing daily impacts at the moment for team members. The windows emulator (non-container) seems to work much more consistently

It doesn't seem to be resources related (cpu/ram) are all in abundance and we're seeing this across a wide range of different hardware vendors.

I realise technical information is light on here and I will gather that, just trying to gauge if other people are pushing through the pain so to speak with this?

yes - its massively unreliable (on Ubuntu devops build agent). A bunch of our unit tests randomly fail with things like this.

Microsoft.Azure.Cosmos.CosmosException : Response status code does not indicate success: NotFound (404); Substatus: 1013; ActivityId: 7e4d51b2-94be-4721-9ae1-beb0128dbcba; Reason: (
code : NotFound
message : Collection is not yet available for read. Please retry in some time.
ActivityId: 7e4d51b2-94be-4721-9ae1-beb0128dbcba, Microsoft.Azure.Documents.Common/2.14.0
);

[pvpmartins]

forget it man... basically all issues here are related to this. the azure team simply will not fix it

[raghuAtRA]

There is general apathy and near zero development on the emulator.

Issues languish wtihout any response & updates are rarely provided; We kept getting told that updates are in the offing but no new releases or even an ETA for any fixes. And no amount of nudges/pushes (public or private) seem to have any effect.

I have stopped recommending cosmos because DX is definitely not a priority. This repo is nothing but window dressing

[lynkz-matt-psaltis]

Yeah we've just finished migrating to Postgres because of this. CI/CD testing is possible again. Container startups < 15seconds Everything's better and when YugabyteDb's PG uplift is ready, we'll have a cloud agnostic approach. Good luck out there Tech leads and Architects. This one I'll chalk up to a costly mistake and good lessoned learned.

[diegosasw]

Microsoft/Azure does not want to invest any single dollar in creating/maintaining docker images of their services. That's why there is no image available for Azure Service Bus and that's why the CosmosDB emulator image is absolutely unreliable and abandoned.

Good luck out there Tech leads and Architects. This one I'll chalk up to a costly mistake and good lessoned learned.

As a tech lead, I fully agree. The only reason I am still using CosmosDb is because I'm part of a large company which uses CosmosDb, but if it's up to me, I will never pick any tool which I can run as a docker container or use offline in a reliable manner. I cannot express enough how much I dislike the development experience with CosmosDb and testing CosmosDb integration.